Bugzilla – Bug 1958
Library Scanning Problem with duplicate roles in SlimServer 6.2b1
Last modified: 2008-09-15 14:36:01 UTC
If an MP3 file has ID3v2 tags and if both the ARTIST and the V2_TCOM (composer) tags are equal, SlimServer only records the composer role and ignores the artist role. Example: This file (without a V2_TCOM tag) is Genre->Artist->Album browse-able in SlimServer: [CODE]C:\Recordings\Music\a_Medieval\Anonymous\La Vi�le M�di�vale\01 - Rotundellus (Galicia, Cantiga 105).mp3 Format: MPEG 1 Layer 3, Stereo Details: 44100 Hz Stereo, 179 kbps, playtime 04:29 Tags: ID3v1, ID3v2 Title: Rotundellus (Galicia, Cantiga 105) Artist: Anonymous Album: La Vi�le M�di�vale Year: Track: 01 Genre: a_Medieval Comment: La Lira D'Esp�ria: La Mi�le M�di�val Jordi Savall, Lira, Rebab, Vi�les Pedro Estevan, Percussion[\CODE] If one adds a V2_TCOM tag to the file� [CODE]C:\Recordings\Music\a_Medieval\Anonymous\La Vi�le M�di�vale\01 - Rotundellus (Galicia, Cantiga 105).mp3 Format: MPEG 1 Layer 3, Stereo Details: 44100 Hz Stereo, 179 kbps, playtime 04:29 Tags: ID3v1, ID3v2 Title: Rotundellus (Galicia, Cantiga 105) Artist: Anonymous Album: La Vi�le M�di�vale Year: Track: 01 Genre: a_Medieval Comment: La Lira D'Esp�ria: La Mi�le M�di�val Jordi Savall, Lira, Rebab, Vi�les Pedro Estevan, Percussion Composer=Anonymous[\CODE] ..and rescans the library, the album can no longer be browsed to via Albums, Artists, Genres or Years. If one browses the music folder, one can select one of the tracks in the (otherwise non-browse-able) album and see that COMPOSER=anonymous is listed, but no ARTIST is listed. If one performs the following SQL query to select the track in question: [CODE] SELECT genres.name AS GenreName, UTF8ToAnsi([albums].[title]) AS AlbumTitle, tracks.tracknum, tracks.title AS TrackTitle, contributor_track.role AS ContribRole FROM ((((genres INNER JOIN genre_track ON genres.id = genre_track.genre) INNER JOIN tracks ON genre_track.track = tracks.id) INNER JOIN albums ON tracks.album = albums.id) INNER JOIN contributor_track ON tracks.id = contributor_track.track) INNER JOIN contributors ON contributor_track.contributor = contributors.id WHERE (((albums.title) Like "La V*") AND ((tracks.tracknum)=1)); [\CODE] �only one row is returned with this data: [CODE]GenreName: A_Medieval AlbumTitle: La Vi�le M�di�vale tracknum: 1 TrackTitle: Rotundellus (Galicia, Cantiga 105) ContribRole: 2[\CODE] Shouldn't Slimserver record TWO contributor_track records for this track, one for ARTIST and one for COMPOSER???
Please also see https://bugs-archive.lyrion.org/show_bug.cgi?id=1913 where I describe a related problem which looks like a different symptom of the same cause, where Slimserver is assigning the contributor role only based upon Composer rather than Artist. I have also seen the problem described in this bug and have provided additional info in bugid 1913.
Yes - SlimServer should, and this is very similar to a bug that I fixed yesterday. There appears to be a problem with the regex that I'll fix shortly, but this may already work for you. :)
Fix checked in as subversion change 3956. Please let me know if it's fixed for you. A wipe & rescan will be needed.
Sorry, version 3958 is still exhibiting this problem (though with one exception.) Could I email you my (very small) test mp3s and my slimserversql.db files so you can see for yourself?
Yes - please do.
Ok - this should be fixed as of subversion change 3968, and will be in the 2005-08-15 nightly. Thanks for the files!
Yes, version 3868 seems to have solved the problem as far as MP3s go. Now, how about FLACs? I'm still seeing the problem when scanning my flac library. When ARTIST==COMPOSER, it appears that only the very 1st scanned flac track within each genre gets both roles. All the rest get contributor COMPOSER only. I'll put together some FLAC test files like the MP3s I sent you so you can test them. It will take me about an hour to get them together. Thanks.
OK, it looks like the problem is only with FLACs with embedded metadata cuesheets. I'm still working on some test files for you.
Created attachment 725 [details] Observations on svn 3973: Using the Music_Beta library that I sent to Dan: For track-per-file tracks, both mp3s and flacs: Where ARTIST_tag==COMPOSER_tag: Each track is getting 3 records in contributor_track: roles 2, 5, 6 -- mapping to Composer, AlbumArtist, TrackArtist: the AlbumAritst pointing to: Various Artists in the Contributors table. This is incorrect behavior, yes? For Album-per-file flacs, both external and embedded cuesheets: where ARTIST_tag==COMPOSER_tag for all tracks: Track 1 gets 4 records in contributor_track: one Artist record and THREE Composer records Every subsiquent track in the album gets 3 contributor_track records: one Artist and TWO Composer(s) For these Albums, only the 1st track can be browsed to via: Genre->Artist->Album The query I used to perform this analysis is: SELECT genres.name AS GenreName, utf8toansi([albums].[title]) AS AlbumTitle, tracks.id AS TrackID, utf8toansi([tracks].[title]) AS TrackTitle, tracks.tracknum, contributor_track.role, contributor_role.rolename, utf8toansi([contributors].[name]) AS ContribName, tracks.url, tracks.ct FROM (((((tracks LEFT JOIN contributor_track ON tracks.id = contributor_track.track) LEFT JOIN contributor_role ON contributor_track.role = contributor_role.id) LEFT JOIN contributors ON contributor_track.contributor = contributors.id) LEFT JOIN albums ON tracks.album = albums.id) LEFT JOIN genre_track ON tracks.id = genre_track.track) LEFT JOIN genres ON genre_track.genre = genres.id ORDER BY genres.namesort, albums.titlesort, tracks.tracknum, contributor_track.role, contributors.namesort; It uses one table not included in the current schema: contributor_role: CREATE TABLE contributor_role ( id integer UNIQUE PRIMARY KEY NOT NULL, rolename varchar UNIQUE NOT NULL ); There are six records: id rolename 1 Artist 2 Composer 3 Conductor 4 Band 5 AlbumArtist 6 TrackArtist This table is used to clarify roles in the query. The query also uses a function: UTF8toAnsi() to display the results in a windows compatible char set.
SVN 3975: The track-per-file entries now seem to be getting the correct records in contributor_track: 1 artist role and 1 composer role. Album-per-file flacs with embedded and external cuesheets still exhibiting the problem where: only the 1st track of each album where ARTIST_tag==COMPOSER_tag can be browsed to.
svn 3980: No problem browsing to MP3s. No problem browsing to track-per-file flacs. No problem browsing to album-per-file flacs with external cuesheets. Problem remains with album-per-file flacs with embedded metadata cuesheets: Only the 1st track of any album is visible or browse-able. slimserversql.db Query output for test flacs with embedded cuesheets attached
Created attachment 732 [details] Query results for svn 3980
Well, I think that this bug, as originally described, is fixed. I'm still having problems (as of svn 3981) with browsing to whole-album flacs with embedded metadata cuesheets, but I think that that should be a new bug.