After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 552608 - Files removed from disk not removed from library on rescan
Files removed from disk not removed from library on rescan
Status: RESOLVED FIXED
Product: banshee
Classification: Other
Component: Importing
git master
Other All
: Normal normal
: 1.x
Assigned To: Banshee Maintainers
Banshee Maintainers
: banshee-orphans (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2008-09-17 10:08 UTC by Dominik Possner
Modified: 2009-12-30 00:48 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Dominik Possner 2008-09-17 10:08:24 UTC
Please describe the problem:
While rescanning the library imports new files, it does not remove files from the library, that aren't present on the disk anymore.

Steps to reproduce:
1. delete songs from disk
2. rescan library
3. deleted songs still present in banshee


Actual results:


Expected results:
song disappeared from library

Does this happen every time?
yes

Other information:
Comment 1 Gabriel Burt 2009-02-09 19:11:57 UTC
Can you still reproduce this bug in 1.4.2 or svn trunk?
Comment 2 Dominik Possner 2009-02-09 22:21:18 UTC
yes, i still see this in revision 5021. i compiled banshee with --disable-docs and --disable-ipod. but it's also present in 1.4.2 from launchpad's ppa.
Comment 3 Bertrand Lorentz 2009-03-01 17:08:20 UTC
*** Bug 573642 has been marked as a duplicate of this bug. ***
Comment 4 Bertrand Lorentz 2009-03-01 22:32:26 UTC
Could run the following command (all in one line), where you replace filename.mp3 with the filename of one of the files that were not removed from the banshee library.

sqlite3 ~/.config/banshee-1/banshee.db "select trackid, primarysourceid, uritype, uri from coretracks where uri like '%filename.mp3';"

This query might tell why those files were not removed.
Comment 5 Dominik Possner 2009-03-02 17:03:34 UTC
the output is the following for a deleted file:

dominik@dominik-laptop:~$ sqlite3 ~/.config/banshee-1/banshee.db "select trackid, primarysourceid, uritype, uri from coretracks where uri like '%09 - Appollonia.mp3';"
dominik@dominik-laptop:~$ 

whereas for an existing file:

dominik@dominik-laptop:~$ sqlite3 ~/.config/banshee-1/banshee.db "select trackid, primarysourceid, uritype, uri from coretracks where uri like '%11. The View.mp3';"
9003|1|1|Modest Mouse/Good News For People Who Love Bad News/11. The View.mp3
dominik@dominik-laptop:~$ 


Comment 6 Bertrand Lorentz 2009-03-02 20:25:20 UTC
I'm not sure I understand what you mean : 
The "09 - Appollonia.mp3" file is not present on the disk but still visible in banshee ?
The query seems to indicate that it's not present in the banshee database.

The "11. The View.mp3" file seems fine, its path is relative to the library. If it wasn't, it wouldn't get cleaned up from the database by a rescan.
Comment 7 Dominik Possner 2009-03-02 22:51:18 UTC
Exactly, the file appollonia.mp3 is not present on the disk. According to the query, it's also not present in the database, but it's still in my library in Banshee.

So, I deleted my banshee.db, imported all my music, deleted a file, rescanned and then it was gone from the library.

After that, I reimported my old banshee.db, deleted a file, rescanned, and it was gone. Now everything works as expected and I don't know what the problem was...
Comment 8 Leo 2009-08-01 03:53:40 UTC
try using

select title, uri from coretracks where title like "%_mp3 idv3 tag name_%";

You should get row(s) for files that have been moved/deleted.
Comment 9 Leo 2009-08-01 17:18:28 UTC
$ ./Banshee.exe --version
Banshee 1.6 Beta 2 (1.5.1)

Just re-did a test, single file.  
Running from some version d/l via git.
Seems to be working.

Scanning process takes time.  Status bar hides itself before process is done, tricking me into thinking that it failed/completed.

Comment 10 Gabriel Burt 2009-12-30 00:48:00 UTC
Closing per comment #9.