Bugzilla – Bug 6720
Year not removed from database when last song with that year is changed
Last modified: 2009-09-08 09:30:59 UTC
I found I had one song on an album where I had accidentally entered a typo in the year tag. I had a year of 1086 in my Browse Years list. I corrected the tag within the mp3 file that was wrong. I then played the song from within Browse Years, such that it read the new tag value for the song. This has corrected the song so that it appears with the correct year value. However, I still have the year 1086 appearing in the Browse Years list, with no artist, album, tracks. ie. It is a redundant year that should have been removed when it was orphaned by correcting the track tag. I tried to rescan for new and changed files, but this hasn't removed the redundant year either. A full rescan would fix the problem, but it really shouldn't be necessary.
This probably is the answer to the "why does a simple scan take so long?" question. I guess there's no cleanup after a simple update, whereas the scans do a clean up on related tables.
A simple solution would be to remove the redundant 'years' table from the databse. All the years necessary for browsing can easily be found with a 'SELECT DISTINCT years' query on the albums table.
this assumes that only albums have years. We've got other reports there that suggest a need for handling of albums containing tracks of multiple years.
This should do it: DELETE years y FROM years y LEFT JOIN (SELECT DISTINCT year FROM albums a UNION SELECT DISTINCT year FROM tracks t) z ON y.id = z.year WHERE z.year is NULL I noticed a possible inconsistency in the year data in the tracks table. In my database, I have albums with year = 0 and tracks with year = 0, but also in the tracks table there are years = NULL. These appear to be from tracks with content type cue, cpl and ssp - playlists?
I don't think performing garbage collection any time you browse music folder is what we want, since it would really slow things down. There's an optional cleanup process during scan that's not enabled by default (probably because people complained it took too long). This doesn't cleanup years though, I think because years are referenced from both albums and tracks. We could add your SQL to the cleanup phase, but it would never run for anyone unless they manually ran with the --cleanup flag. So maybe this isn't such a big deal, and can be worked around just as easily with a wipe and rescan?
I thought there was a design goal to do away with full rescan. I don't think it's slow. When I run it, it takes 0.0023secs! Library stats: Total Tracks: 20,149 Total Albums: 1,725 Total Artists: 600 Total Years: 48 AMD Athlon 64 X2 3800+ 2GB RAM. If there's a performance problem for people with larger libraries or slower machines than me, is it possible to run the cleanup when "rescan for new and changed tracks" is run, but not when browsing music library?
Are you saying --cleanup takes that long?
No, just the SQL to delete redundant years.
OK, so it probably wouldn't hurt to add that bit of SQL after a rescan.
Added in change 18632.
Verified fixed in 7.0.1 - 19325
This bug has recently been fixed in the latest release of SqueezeCenter 7.0.1 Please try that version, if you still see the error, then reopen this bug. To download this version, please navigate to: http://www.slimdevices.com/su_downloads.html
Reduce number of active targets for SC