Bug 2372 - compilations in same directory get split into multiple albums incorrectly.
: compilations in same directory get split into multiple albums incorrectly.
Status: RESOLVED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Tagging
: 6.2.0
: PC All
: P2 major (vote)
: ---
Assigned To: Dan Sully
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2005-10-25 19:34 UTC by Rob Fair
Modified: 2008-09-15 14:37 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments
Log, playlist, id3tags (6.31 KB, application/x-gzip)
2005-10-26 15:10 UTC, Rob Fair
Details
logfile, ID3 tags, playlist (6.98 KB, application/x-tar)
2005-10-26 15:17 UTC, Rob Fair
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Rob Fair 2005-10-25 19:34:37 UTC
Slimserver 6.2 has started randomly splitting compilations into multiple albums,
up to 4, even in the case when all the album files sit in the same directory
(.../Various Artists/<album>/<song>) and have consistenct ID3 tags in all files,
which should be a no-brainer to recognize as related files.

The albums seems to be split at random, although always together (e.g. tracks
1-7 in album 1, 8-11 in album 2, 12-15 in album 3)

Doing full rescans doesn't change anything. Physically removing the files from
the library, rescanning, putting the files back and rescanning again may create
a *different* grouping of multiple albums, usually track 1 being categorized as
a regular album and the rest of the tracks as a different compilation.

[BTW, the "use compilation" workaround mentioned in the forums is not a
go, this is not a standard tag, and is not readily editable on my platorm
(Linux). And even if it was, having to retag a large number of files so 
slimserver can do the obvious seems very wrong.]
Comment 1 KDF 2005-10-26 00:15:26 UTC
Can you capture any logs using d_info and d_scan while the server scans this
directory?

This doesn't explain the random splits, but do these files appear in any of your
playlists with conflicting metadata?  do you have any playlists or CUE sheets in
that same directory?
Comment 2 Rob Fair 2005-10-26 15:10:09 UTC
Created attachment 945 [details]
Log, playlist, id3tags
Comment 3 Rob Fair 2005-10-26 15:11:53 UTC
>Can you capture any logs using d_info and d_scan while the server scans this
>directory?

>This doesn't explain the random splits, but do these files appear in any of your
>playlists with conflicting metadata?  do you have any playlists or CUE sheets in
>that same directory?

The logs for a specific CD are attached. Looking, most (all?) of the CDs with
problems do appear in playlists - and the split usually seems to be at a track
thats in a playlist. For the one attached the CD splits at track 2, and track
2 is in a playlist.

The info for the attached CD shows up in slimserver as two albums, one with just
a single track (01, Trik Turner), and another for all the rest, plus a large
number of other tracks (74 total) from assorted albums. Very weird - although
I did notice in the log these were the tracks interleaved with the main
CD. Does slimserver do parallel parsing perhaps ?

The attachment also include the playlist and the mp3 ID3 tags.
Comment 4 Rob Fair 2005-10-26 15:17:16 UTC
Created attachment 946 [details]
logfile, ID3 tags, playlist
Comment 5 Dan Sully 2005-10-27 20:38:06 UTC
I've checked in a fix as subversion change 4893 - which will be in the 10-28-2005 nightlies.

Please give that a try.

Thanks.
Comment 6 Rob Fair 2005-10-30 13:50:24 UTC
The change helps a lot, thanks for the quick resolution.
Comment 7 Chris Owens 2006-06-16 14:40:00 UTC
There are 536 bugs in the database with targets of '---' that were fixed prior to new year 2006.  I am setting them to targets of 6.2.1 to keep them from showing up in my queries.