Bugzilla – Bug 5158
After --rescan, moved music still in DB with its old location
Last modified: 2009-09-08 09:26:27 UTC
Running trunk, r12368. This has been true for a long time, but recently Dean expressed a desire that the DB could be persistent and not need to be wiped and rebuilt as part of routine operation--so that people could store e.g. ratings and such in it--and this would be one thing that would need to happen for that. I moved /home/chris/music/mp3/Dar_Williams-The_Beauty_of_the_Rain/ to /home/chris/music/mp3/Dar_Williams/Dar_Williams-The_Beauty_of_the_Rain/. Did a rescan, and that album now has two records in the DB: mysql> select a.id, title from albums a,contributors c where a.contributor=c.id and c.name='Dar Williams' and a.title='The Beauty of the Rain'; +-----+------------------------+ | id | title | +-----+------------------------+ | 81 | The Beauty of the Rain | | 456 | The Beauty of the Rain | +-----+------------------------+ Which naturally show up in search results. Oddly, one of the tracks from the original entry has now disappeared from search results, after I did a track search on it. I believe completely deleted music also remains in the DB. Solutions that come to mind involve scanning new music and checking to see if it matches existing DB entries, and maybe running a checksum or seeing if file sizes plus metadata all match. I'm not familiar with the scanning code, so I can't say how feasible that is in the current framework.
see bug 4917, bug 5067, bug 3928. for now, --rescan leaving old data is not a bug, so marking as an enhancement even though this is probably a duplicate of the above, if not all being slightly different aspects of the same issue.
Okay. I think it's a major-ish change in behavior; if it were implemented, would it be accepted?
I'll cc Dean, but I think the developer list should be involved in this decision as well. Have you posted there yet?
Yes, let'd discuss in the developer forum first.
We aren't going to do this for 7.0, but please start a thread in the developer forum so we can come to agreement for a subsequent release.
In lieu of a thread in the developers forum, here's an idea: 1. When starting the rescan note the current time, or alternatively have a unique sequence number. Call this the 'cookie'. 2. Have a new column on the appropriate db tables, called "cookie" or something. 3. As the rescan proceeds, write the cookie value to the rows in the database irrespective of whether they are new rows or whether the row already exists. 4. After the rescan is finished, search for all rows in those tables NOT having the cookie value. Delete those rows. The result is that, I think, we could prune files that have been renamed or deleted. This doesn't solve the problem of just noticing deleted items when browsing, or for intelligently moving things like ratings when the filename changes, but I think it would solve the common use case 'fairly cheaply'. It would also slow down the rescan since it would involve modifying all rows even if they haven't actually changed, so we could consider making this an advanced configuration option. I might consider investigating this as a patch if someone thinks it's a good idea.
New rescan code will handle moved music.
Moving 7.4 bugs to 8.0.