Bugzilla – Bug 4616
Wrong Artist in Database
Last modified: 2008-12-18 11:12:53 UTC
SlimServer Version: 6.5.1 - 11039 - Windows XP - EN - cp1252 The database shows a wrong Artist, the entry in the file are correct. The database shows as Artist: "The Twins", but it should only "Twins" Note: The files are multiplanguage (Chinese Title, but the rest is English, incl. the artist) FLAC files File information: METADATA block #2 type: 4 (VORBIS_COMMENT) is last: false length: 165 vendor string: reference libFLAC 1.1.2 20050205 comments: 8 comment[0]: ARTIST=Twins comment[1]: ALBUM=Ho Hoo Tan comment[2]: GENRE=Pop comment[3]: title=???? comment[4]: DATE=2006 comment[5]: TRACKNUMBER=01 comment[6]: DISCC=01 comment[7]: DISC=01 The database shows the following: Title: ���˼��� Artist: The Twins Album: Ho Hoo Tan Genre: Pop Disc: 1 Track: 1 File Format: FLAC Duration: 3:12 Year: 2006 File Length: 25,090,693 Bytes Bitrate: 1042kbps CBR Sample Rate: 44.1 kHz
slimserver is unable to simply create meta data unless it is found somewhere or found in prior scans (without the use of a clear and rescan). If it is getting "The Twins" then the data is coming from somewhere. Cue sheets, playlist files are the likely suspects. it is also possible that it comes from the filename if there is some problem reading the tags.
Nop. Foobar2000 and Windows Media Player shows the correct artist title. I cleared and rescanned the complete database - same result. I deleted the complete database (I do this every time I install an newer slimserver version) � same result. I copied the file(s) to different slimserver installation (another pc) � same result. I de-installed slimserver, cleared the install directory, installed latest version again � same result. Slimserver version 6.3.x does not show the wron artist! So it must be a problem in version 6.5.1!
slimserver cannot create data. 6.3.1 may not have picked it up before, but it is in there somewhere now. Either in the filename or playlists or a tag header that you might not be expecting. that needs to be found. please attach the problem track to the report.
Created attachment 1750 [details] 1st title from twins album for testing
So I played a bit over the holidays with several slimserver versions to found a hint for the problem. slimserver version 6.3.1 and 7.0a1 - 11067 (!!!!) does not have the reported problem (but v7 is more an alpha then a beta version yet). slimserver version 6.5.1 - 11039 + 11067 (I have not played with more version yet) shows the reported problem. So I played with this version, several playlist and file directions and found the following: If I have only the reported album and the playlist to scan (different directories and drives tested) the problem does NOT occure. But: If I use my complete collection (more then 12.000 flac files and 1.800 playlists) the problem occured So the problem looks more a resource/performance problem, maybe in scanner.exe. I uploaded the first track from the album, so if you have time and enough flac files you can play with it. If you have a good hint for a log file, pls tell it to me, maybe this will help faster to find the problem :) regards, jens
If the problem only occurs with your entire collection included, then likely there is a stray tag somewhere in that collection. To help locate it, stop the server and open a command prompt (Start->Programs->Accessories->Command Prompt). Type the following: cd \Program Files\Slimserver\server <enter> slim.exe --d_import --d_scan --d_info --logfile c:\bug4616.log <enter> Then once the server is started up, initiate a scan. Once complete, you'll have a record of every tag the server found in the file c:\bug4616.log
Ok, here the findings: 2007-01-02 12:33:44.3296 newTrack(): New Track: [file:///M:/Music/DEC739100003.flac] 2007-01-02 12:33:44.3297 newTrack(): readTags is 1 2007-01-02 12:33:44.3301 flc file type for M:\Music\DEC739100003.flac 2007-01-02 12:33:44.3410 newTrack(): Created track 'Ballet Dancer' (id: [6022]) 2007-01-02 12:33:44.3413 -- Track is a local track 2007-01-02 12:33:44.3437 -- Track has genre 'Pop' 2007-01-02 12:33:44.3482 -- Track has contributor 'The Twins' of role 'ARTIST' 2007-01-02 12:33:44.3483 -- Track has 1 contributor(s) 2007-01-02 12:33:44.3485 -- Track primary contributor is 'The Twins' (id: [914]) 2007-01-02 12:33:44.3487 -- Checking for discs 2007-01-02 12:33:44.3526 -- Searching for an album with: 2007-01-02 12:33:44.3529 --- me.title : "The Hits Of The 80's (Pop & Wave Limited Edition Vol. 1)" 2007-01-02 12:33:44.3531 --- me.discc : "02" 2007-01-02 12:33:44.3542 -- Created album 'The Hits Of The 80's (Pop & Wave Limited Edition Vol. 1)' (id: [580]) 2007-01-02 12:33:44.3555 -- Updating album 'The Hits Of The 80's (Pop & Wave Limited Edition Vol. 1)' (id: [580]) with columns: 2007-01-02 12:33:44.3555 --- discc : 02 2007-01-02 12:33:44.3556 --- titlesort : HITS OF THE 80 S POP WAVE LIMITED EDITION VOL 1 2007-01-02 12:33:44.3557 --- titlesearch : HITS OF THE 80 S POP WAVE LIMITED EDITION VOL 1 2007-01-02 12:33:44.3558 --- disc : 01 2007-01-02 12:33:44.3559 --- year : 1991 2007-01-02 12:33:44.3562 -- Track has album 'The Hits Of The 80's (Pop & Wave Limited Edition Vol. 1)' (id: [580]) 2007-01-02 12:33:44.3589 -- Contributor 'The Twins' (id: [914]) linked to album 'The Hits Of The 80's (Pop & Wave Limited Edition Vol. 1)' (id: [580]) with role: 'ARTIST' 2007-01-02 12:33:44.3622 flc file type for file:///M:/Music/DEC760200089.flac 2007-01-02 12:34:56.9063 newTrack(): New Track: [file:///M:/Music/HKD250616801.flac] 2007-01-02 12:34:56.9064 newTrack(): readTags is 1 2007-01-02 12:34:56.9068 flc file type for M:\Music\HKD250616801.flac 2007-01-02 12:34:56.9355 newTrack(): Created track '热浪假期' (id: [8008]) 2007-01-02 12:34:56.9358 -- Track is a local track 2007-01-02 12:34:56.9397 -- Track has genre 'Pop' 2007-01-02 12:34:56.9434 -- Track has contributor 'Twins' of role 'ARTIST' 2007-01-02 12:34:56.9435 -- Track has 1 contributor(s) 2007-01-02 12:34:56.9437 -- Track primary contributor is 'The Twins' (id: [914]) 2007-01-02 12:34:56.9438 -- Checking for discs 2007-01-02 12:34:56.9475 -- Searching for an album with: 2007-01-02 12:34:56.9478 --- me.title : "Ho Hoo Tan" 2007-01-02 12:34:56.9489 -- Created album 'Ho Hoo Tan' (id: [738]) 2007-01-02 12:34:56.9501 -- Updating album 'Ho Hoo Tan' (id: [738]) with columns: 2007-01-02 12:34:56.9502 --- discc : 01 2007-01-02 12:34:56.9503 --- titlesort : HO HOO TAN 2007-01-02 12:34:56.9504 --- titlesearch : HO HOO TAN 2007-01-02 12:34:56.9504 --- disc : 01 2007-01-02 12:34:56.9505 --- year : 2006 2007-01-02 12:34:56.9509 -- Track has album 'Ho Hoo Tan' (id: [738]) 2007-01-02 12:34:56.9535 -- Contributor 'The Twins' (id: [914]) linked to album 'Ho Hoo Tan' (id: [738]) with role: 'ARTIST' 2007-01-02 12:34:56.9569 flc file type for file:///M:/Music/HKD250616802.flac The import linked the "Twins" to the "The Twins" - that's the problem.
so, it would appear that DEC739100003.flac is the source of "The Twins". Have you tried moving those files into different subfolders? cc'ing Dan for some idea as to why the artists might be getting merged despite two different album titles.
Yep. If I move all "The Twins" files to another folder and rescan, "Twins" will be shows correct. Remember: version 6.3.1 and 7.01 works without any problems! So it looks the SQL procedure in v6.5.x for qualifying the "Artist" works wrong (you can see the "Artist" was scanned correct, but the tracking of the primary "Artist" give the wrong ID (914) back.
Jens, have you tried this with the latest builds of 6.5.2? Given that the behaviour is already noted as fixed in 7.0, it might already work with 6.5.2. If not, it might not be something Chris wants to have fixed for 6.5.2 given the possible risk in changing album handling this close to a release (I suspect the problem in 6.5.1 is a use of ignoreCaseArticles and might run the risk of introducing a change for users who are used to having artists like "Offspring" and "The Offspring" considered as the same artist).
No, I have not tested this with the latest build, because I'm not at home until 05/10/07. But at next weekend I will test it and give feedback.
No change with version from 05/16/07.
This is exactly the kind of bug I would really like users to have a chance to test in nightlies with their varied music collections, rather than depend on my small QA team. And there's not much time left for nightlies of 6.5.2. I think 7.0 is the best we can do without risking unforeseen problems in 6.5.2. :(
This bug is being closed since it was resolved for a version which is now released! Please download the new version of SqueezeCenter (formerly SlimServer) at http://www.slimdevices.com/su_downloads.html If you are still seeing this bug, please re-open it and we will consider it for a future release.