Bug 18150 - Scanner always sets DISCNUMBER to 1 for FLAC files
: Scanner always sets DISCNUMBER to 1 for FLAC files
Status: RESOLVED PATCHWELCOME
Product: Logitech Media Server
Classification: Unclassified
Component: Scanner
: 7.9.x
: PC Other
: -- normal (vote)
: ---
Assigned To: Unassigned bug - please assign me!
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2016-07-21 16:03 UTC by boombugz
Modified: 2016-08-07 01:01 UTC (History)
1 user (show)

See Also:
Category: ---


Attachments
File tags as shown in MusicBee and other apps (213.48 KB, image/png)
2016-07-26 03:14 UTC, boombugz
Details
SqueezeServer view of the file tags (123.93 KB, image/png)
2016-07-26 03:16 UTC, boombugz
Details
Scanner log from a complete wipe-and-scan (5.98 KB, application/octet-stream)
2016-07-26 03:17 UTC, boombugz
Details
View of the file details in the LMS database (30.53 KB, image/png)
2016-07-26 03:35 UTC, boombugz
Details
File tags after applying workaround (174.20 KB, image/png)
2016-07-27 01:55 UTC, boombugz
Details
LMS database after workaround and rescan (174.20 KB, image/png)
2016-07-27 01:56 UTC, boombugz
Details

Note You need to log in before you can comment on or make changes to this bug.
Description boombugz 2016-07-21 16:03:11 UTC
FLAC files with DISCNUMBER>1 are inserted into the database as having DISCNUMBER=1.

MusicBee says the tags are stored in "Vorbis Comments" format, if that means anything.
Comment 1 boombugz 2016-07-26 03:14:20 UTC
Created attachment 7751 [details]
File tags as shown in MusicBee and other apps
Comment 2 boombugz 2016-07-26 03:16:58 UTC
Created attachment 7752 [details]
SqueezeServer view of the file tags
Comment 3 boombugz 2016-07-26 03:17:57 UTC
Created attachment 7753 [details]
Scanner log from a complete wipe-and-scan
Comment 4 boombugz 2016-07-26 03:35:18 UTC
Created attachment 7754 [details]
View of the file details in the LMS database
Comment 5 Michael Herger 2016-07-26 04:44:47 UTC
There might be a difference in how LMS handles the case where you have a DISCNUMBER value, but no DISCTOTAL (see your first screenshot). We rely on the latter, while other applications might use the highest DISCNUMBER value.

But this can easily be "fixed" by setting the correct value for the total number of discs in your files.
Comment 6 Michael Herger 2016-07-26 04:45:25 UTC
Data issue, not code.
Comment 7 boombugz 2016-07-27 01:55:14 UTC
Thank you for the investigation and for the suggested workaround.

As suggested, I set the number of discs for that album (which comes out of MusicBee as the TOTALDISCS tag, not DISCTOTAL) and tried first a scan-for-changes and then a wipe-and-rescan.

However, the result was the same; the LMS database still lists DISCNUMBER as 1 for the album.

One could, as you mentioned, infer a value for DISCTOTAL from the maximum DISCNUMBER field for all the tracks on a particular album, but I don't understand why the presence or absence of the DISCTOTAL field would determine the value of the DISCNUMBER field.  DISCNUMBER is what it is, and should be parsed correctly regardless of whether or not the DISCTOTAL tag exists.
Comment 8 boombugz 2016-07-27 01:55:59 UTC
Created attachment 7755 [details]
File tags after applying workaround
Comment 9 boombugz 2016-07-27 01:56:35 UTC
Created attachment 7756 [details]
LMS database after workaround and rescan
Comment 10 Jim McAtee 2016-08-05 21:10:15 UTC
Do you have both discs of this album in your library, or only disc 2?

I use the exact same fields - DISCNUMBER and TOTALDISCS - for tagging multi-disc albums and I don't see this behavior in 7.9. One small tagging difference is that I don't include a TOTALTRACKS field.

In the web interface of LMS, you can drill down a couple more levels and see the actual tags LMS sees for an individual track using the 'View Tags' link. You should see something like this:

ALBUM: Moonflower
ALBUMARTIST: Santana
ALBUMARTISTSORT: Santana
ALBUMSORT: Moonflower
ARTIST: Santana
ARTISTSORT: Santana
DATE: 1977
DISCNUMBER: 2
GENRE: Rock
REPLAYGAIN_ALBUM_GAIN: -5.40 dB
REPLAYGAIN_ALBUM_PEAK: 0.99908447
REPLAYGAIN_TRACK_GAIN: -6.93 dB
REPLAYGAIN_TRACK_PEAK: 0.98614502
TITLE: She's Not There
TOTALDISCS: 2
TRACKNUMBER: 1
VENDOR: reference libFLAC 1.2.1 20070917
Comment 11 boombugz 2016-08-06 14:04:14 UTC
I have both discs of this release in the library, and the problem happens on other multi-disc FLAC sets.

'View Tags' in the LMS webUI gives the following:

ALBUM: The K&D Sessions 
ALBUMARTIST: Kruder & Dorfmeister 
ALLPICTURES: [ HASH(0xaa2261c) ] 
APIC: [ image/jpeg, 3, CD Front Cover, 31284, 375 ] 
ARTIST: David Holmes 
DATE: 1998 
DISCNUMBER: 2 
ENCODER: reference libFLAC 1.2.1 20070917 
GENRE: Trip-Hop 
LANGUAGE: Eng 
MCDI: b •täè?ݯOéøQ˜·Ù ÊÚ e ]|ªáÔÿÿ 
TALB: The K&D Sessions (CD 2) 
TCON: Trip-Hop 
TDEN: 2011-07-30T10:15 
TDRC: 1998 
TENC: Exact Audio Copy (Secure mode) 
TIT2: Gone (K&D Session) remixed by Kruder & Dorfmeister 
TITLE: Gone (K&D Session) remixed by Kruder & Dorfmeister 
TLEN: 510133 
TOTALDISCS: 2 
TOTALTRACKS: 11 
TPE1: David Holmes 
TPOS: 1/1 
TRACKNUMBER: 01 
TRCK: 01/11 
TSSE: (353 Bytes) 
VENDOR: reference libFLAC 1.2.1 20070917 

...which makes it all the more puzzling why the TRACKS table of the LMS database shows the disc number as 1, when the tags view shows that it did parse and store the tag saying DISCNUMBER=2.  I also don't understand why the TALB tag says "(CD 2)" since the album title doesn't contain that string in the raw tags view of MusicBee.
Comment 12 Jim McAtee 2016-08-06 19:20:24 UTC
These are FLAC files, but it Looks like you also have field names used in ID3v2 tagging typically used in Mp3 files. I'm talking about the four-letter fields, most of them with names beginning with 'T' such as TALB (album name), TIT2 (track title), etc.

If LMS's scanner is reading these rather than ignoring them, it's going to cause a lot of conflicts. In particular, these two:

TALB: The K&D Sessions (CD 2) 
TPOS: 1/1

The album name in this tag looks like it's unique to each disc in the set, so the scanner would think each is a one disc set. But the main culprit may be TPOS, which is interpreted as "part of set" and is used in ID3v2 tagging for disc number and total discs. So this field is saying "disc 1 of 1".

If you remove all of the Id3v2 fields, it should clear up the problem. From what I see, that would be:

MCDI, TALB, TCON, TDEN, TDRC, TENC, TIT2, TLEN, TPE1, TPOS, TRCK, TSSE and APIC, which is an embedded cover.

It looks like EAC was used to rip/encode this album. A common mistake in EAC is to add ID3 tags to FLAC files. Go to Compression Options (F11) > External Compression and uncheck 'Add ID3 tag'.
Comment 13 boombugz 2016-08-07 01:01:31 UTC
Thanks, Jim, that's done the trick!

I didn't know that FLAC files could contain anything except Vorbis tags, and none of my existing library management tools showed the ID3 tags but I did a bit of googling and then used MP3Tag to delete the ID3 tags and then undo (which rewrote only the Vorbis tags).

Given that ID3 tags within FLAC files are (apparently) a known problem, wouldn't it save everyone some fuss if the LMS scanner ignored ID3 tags in FLACs and only read the Vorbis tags?  That seems to be the approach many other applications use.