Bugzilla – Bug 9938
Scan for new/changed music doesn't work when changing compilation tag content
Last modified: 2010-04-08 17:26:34 UTC
I ripped an album with some guest artists. I set ITUNESCOMPILATION=0, and ALBUMARTIST=AAAAAA for each track. I scanned the album into SC. The result in the database was: album.compilation = 0 album.contributor = (the album artist) contributor_album for the album.id had several rows: role 1 rows (one for the main artist and one for each guest artist) role 5 (album artist) I removed the ITUNESCOMPILATION=0 tag from the songs and performed a rescan for new/changed files. (Setting a compilation tag = 0 causes artists to be exploded out into the Browse Artists list, so I wanted to remove the compilation tag to cause track artists to be stored instead of artist roles). This resulted in incorrect database content: album.compilation = 1 [should now be NULL] album.contributor = (the Various Artists contributor) contributor_album for the album.id had: artist (role 1) rows [Shouldn't exist] album artist (role 5) track artist (role 6) rows (one for each artist) i.e. I think the old contributor_album roles are not cleared. The second scan just adds to the contributor roles. The outcome is that even though there is an album artist tag for each song, the album is considered as a compilation because there are contributor artist roles still associated with the album. It could be argued that the artist roles should never have been there from the first scan (as an album artist tag is present, there should be an album artist and track artist(s)). There is a conflict between scanning a non-compilation (causing artist roles) and album artist tags (causing track artist roles), when both a compilation=0 tag AND album artist tag exist. Performing a complete rescan fixes the content.
i wonder what other data fields aren't properly updated in the DB when only looking for new and changed files? its amazing how many related issues there currently are around comps.
There may not be all that many problems with compilation tags: several can probably be associated with this rescan bug. People who update tags and rescan for new/changed files, then report problems that wouldn't be an issue if a full rescan had been done instead.
Steven, can you take a look at this one?
maybe a duplicate of bug 9866
Moving to 7.3.3
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.
just want to reiterate that based on what i see in the forums, this bug is not just about comp tags, (although thats a very obvious case) but rather an unknown range of tags/data. essentially the "new and changed scan" not only doesn't always pickup new things or changes to existing things, but it also doesn't delete from the DB things (files, tags, etc) that no longer are there. now the new scanner might have fixed this, but since the new scanner went in, i've seen at least one thread where someone was saying info persisted beyond a new and change scan that shouldn't have, and it took a full clear and rescan to get rid of it. there is also a bug very similar to this one about how art isn't updated from a new and changed scan.
https://bugs-archive.lyrion.org/show_bug.cgi?id=4565 probably others similar to that one...
moving current p2 bugs to p3 to make room for moving p1.5 bugs to p2
just curious... this bug and some other now have the "tinysc" keyword, yet they are/were SS/SC/SBS bugs too. is the eventual fix for both?
I did that because the fix relies on the rewritten scanner, and will therefore be fixed first in TinySC.
== Auto-comment from SVN commit #29089 to the slim repo by andy == == https://svn.slimdevices.com/slim?view=revision&revision=29089 == Bug 9938, handle VA <-> non-VA status changes better. More tests are needed
andy, its been a while since these were filed, however if you are working on this bug its probably a good idea to see what overlap or whats related and valid in these: bug 9870 bug 9872
It would actually be really helpful for my test suite to get a detailed description of an album that you'd like to see added to the test suite. That would probably be the best way to get your favorite scanner bug fixed. If you take a look here: http://svn.slimdevices.com/repos/slim/7.5/branches/embedded/tests/data/scanner/ I am building a test library of tracks with the audio ripped out. The eventual goal is to be able to test everything the scanner does with an automated test suite: http://svn.slimdevices.com/repos/slim/7.5/branches/embedded/tests/t/06scanner.t
Andy, i'm anxious to help you do whatever, but i am confused. what exactly do you want? what are you looking for? i have no idea. also, whats my fave bug? bug 8380 ? let me know what i can do, i'm happy to help. (ps. i am all for a "test library" that has all kinds of possible scenarios in it, glad to see it implemented!)
There are numerous scanner bugs, some probably easier to fix than others. It's pretty overwhelming and right now I'm only working on a handful of them, mostly those that involve rescans. One of my goals for TinySC is that I want rescans of new/deleted/changed files to be rock solid. The scanner has always sucked at this and it's time to fix it. Once this is done, adding auto-rescan support becomes quite easy. So if you want to help a bug have a better chance of being fixed, find an album or create one that causes one of these bugs. Then do 1 of 3 things: 1. Send me the album. 2. Use the riptags script or another way to just send me the album with all the audio removed. 3. Just document the album structure, tags, etc. so I can replicate it. Also, try to think of good test cases, such as "after a new & changed scan, the compilation field should be 0" or "the album should have 4 contributors", stuff like that. I'm not going to promise that I'll fix it right now but with a good test case it becomes much easier to fix.
== Auto-comment from SVN commit #29100 to the slim repo by andy == == https://svn.slimdevices.com/slim?view=revision&revision=29100 == Bug 9938, fixes and test for VA <-> non-VA via tag changes
This bug appears to be fixed now.
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!