Bugzilla – Bug 8034
Album level metadata isn't updated when track data changes
Last modified: 2010-04-08 17:26:15 UTC
I've verified this for the albums table 'year' column. It's also been reported in the forums for the 'replay_gain' (and I'd assume replay_peak) columns when all tracks have the album gain value changed. Not sure if there would be any other columns affected. Running a new/changed scan will (usually) pick up the changes at the track level, but they don't get properly updated in the album's record. To duplicate just change all the year value in all the tracks for an album and run a new/changed scan. Then browse Years and the album will still appear under the old year, while the track info will correctly show the new data.
To reproduce the problem with the tag replaygain_album_gain: give a value to the tag replaygain_album_gain, lets say from -8.52 dB, and do a rescan. Change the value of the tag, lets say from -8.52 dB to -6.52 dB, and do a "scan for new and change music". Slimserver (Version: 6.5.4 - 12568 running on ReadyNAS NV+ in my case) don't refresh the value of the tag. It always displays Album Volume Adjustment: -8.52 dB. The problem is only with the tag replaygain_album_gain, not with replaygain_track_gain.
Now that I look at it again, year and replay_gain in the albums table are slightly different, although the problem is the same - neither is updated when tracks are rescanned in a new/changed scan. The column year can be derived directly from the tracks table, which means that you could easily run a single post-scan query to update the albums table from the data in tracks. The columns replay_gain and replay_peak in the albums table can't be updated in the same say way, since replay_gain and replay_peak stored in tracks are only the track level replay gain. The value in the albums record would have to be updated at the time each track is rescanned.
Matt - I've removed MySQLHelper.pm from our rules file to no longer overwrite it during the build process.
We are now planning to make a 7.3.3 release. Please review your bugs (all marked open against 7.3.3) to see if they can be fixed in the next few weeks, or if they should be retargeted for 7.4 or future. Thanks!
Since there's now a planned 7.3.3 release, bugs which won't make the cut-off are being moved to the next target out. If you feel that this bug needs to be addressed more (or less) urgently than the 7.4 release, please cc chris@slimdevices.com and leave a comment in the bug to that effect so we can review it. Thanks.
For some reason Bugzilla did not change the target when I did this yesterday. Or maybe it was me. In either case, I'm trying it again.
New rescan code will fix this.
I'm working on this one today. What would you guys say the behavior should be if you change, say, the album gain value for only 1 track on an album? Should we check the rest of the tracks on an album after every track change to see if they all match, and only then update the album gain value? That could get to be pretty expensive unfortunately. Or, update album gain to any new value found in a track without regard to the values of the other tracks?
Good question. You're right, it's very expensive if you need to rescan those other tracks from the original files. If the 'album pertinent' data were stored in the tracks table, it would be a much less expensive operation. Album gain fields would be one, as would the compilation field. The one thing to be careful of: When running a New/Changed scan you really should end up with exactly the same database as if you ran a Clear Library scan. So how are album-level metadata conflicts resolved? First in, last in, newest, or something else? If that 'album' data were stored in the tracks table, then when a track is changed, or a new track found, you could recalculate the album fields based on a few queries and a little program logic. Take 'Year', for example - this is stored at the track level as well as the album level. You can run a simple query returning the unique years for all tracks within an album. If just one is returned, then that's the album year. If there's more than one, then you decide which to use by some appropriate logic - min, max, lowest track number, highest track number, newest file datestamp, or what have you. (You'll probably even find a few open bugs regarding how album year conflicts should be handled.) Album replay gain could be similar, with it's own conflict logic. Album compilation status may be more complex, but I believe an explicit compilation tag trumps all other VA logic, so would be nice to have this info stored in the tracks table.
Moving 7.4 bugs to 8.0.
== Auto-comment from SVN commit #28986 to the slim repo by andy == == https://svn.slimdevices.com/slim?view=revision&revision=28986 == Bug 8034, always update album gain/peak values during rescan
This bug is fixed in the 7.5 embedded branch.
(In reply to comment #12) > This bug is fixed in the 7.5 embedded branch. Will the fixes being made in that branch be merged into 7.5 and 7.4 trunk?
7.4, no. 7.5, maybe. The plan right now is similar to what we tried back in 7.4 with the noweb-sqlite branch. The major scanner rewrite necessary for TinySC will remain in the branch (and end up fixing lots of bugs like this one). Depending on stability and how it works on Mac/Windows it may or may not be merged back to 7.5 trunk for release. Eventually it will find it's way into a regular release. I would like to setup alternate builds for those who want to try it anyway. I'll do this after I'm more satisfied with the state of the scanner. I'm trying to also write a good automated test suite that will hopefully eventually cover all the many corner cases in the scanner.
Then how can this be called fixed until it's made in the main server?
Because it's fixed, doesn't matter if it won't make it into the trunk for a while.
This bug has been marked fixed in a released version of Squeezebox Server or the accompanying firmware or mysqueezebox.com release. If you are still seeing this issue, please let us know!