MinimServer 0.8.3 is now available

[simoncn]

(15-12-2014 17:32)magister Wrote:  I ran into the same issue as InfernoST after upgrading to 8.3. The log now shows many entries such as

Warning: illegal characer in INVOLVED_PEOPLE_LIST tag value in file [filename]

It's always the INVOLVED_PEOPLE_LIST tag, which I believe is an ID3 tag. I use FLAC tags exclusively, so these were put in by the company that prepared the file for download. I looked at the tags in mp3tag, and it appears that these illegal characters are a separator between items. For instance, I see "composerLSibelius, Jean" where the L that I typed here appears as a raised character that looks vaguely like an L but with a shorter bottom bar. When I copy this character in mp3tag and paste it into Notepad, it comes out looking like # . I have tried to identify this Unicode character without success.

I can change the tagging, but since I know nothing about MP3 tags I want to use the correct separator between function and name. Does anyone know what character I should use here that is both legal in the UPnP spec and functional in the ID3 scheme of things?

Thanks - David

There is an IPLS (involved people) frame in ID3v2.3 which contains multiple strings separated by NUL (0x00) characters. In ID3v2.4, this frame is renamed to TIPL. MinimServer is currently ignoring both the IPLS and TIPL frames when it reads files containing ID3v2 tags.

Ny guess is that the INVOLVED_PEOPLE_LIST tag in your FLAC files uses the same format as IPLS and TIPL with multiple strings separated by NUL characters (or perhaps some other control character). If they are separated by NUL characters, MinimServer 0.8.2 would remove the NUL characters when it reads the tag value and it would display a warning message. MinimServer 0.8.3 displays a warning message for all control characters (not just NUL) and ignores the entire INVOLVED_PEOPLE_LIST tag. Did you get any warnings from these files with MinimServer 0.8.2?

I think a change to MinimServer 0.8.3 is needed to move this check for illegal characters so it is performed only for tags that are used by MinimServer in some way. This means you would get the warning message only if you have put INVOLVED_PEOPLE_LIST in your indexTags, itemTags or aliasTags property. I will release an update soon (probably tomorrow) with this change.

[simoncn]

(15-12-2014 18:11)DavidHB Wrote:  (Incidentally, there is a confusion of terminology here. Sometimes, as in MP3Tag for example, the term 'tag' is used to refer to the whole set of data in a file (corresponding to a record in a database), while more usually the term refers to a single data item (analogous to an individual field within the record).)

ID3v2 uses "tag" for the whole record and "frame" for the individual fields. FLAC/Vorbis uses "tag" for the individual fields. This is unfortunately somewhat confusing.

[bbrip]

I have those popping up as well for the first time ever in 0.8.3. The respective albums indeed contained a tag INVOLVED_PEOPLE_LIST resp. MUSICICANS_INVOLVED that caused the error messages in the log. As it only was a handful albums over here, I just cleared those tags out of the resp. files and the log is clean again :-)

bbrip

[DavidHB]

(15-12-2014 18:59)simoncn Wrote:  ID3v2 uses "tag" for the whole record and "frame" for the individual fields. FLAC/Vorbis uses "tag" for the individual fields. This is unfortunately somewhat confusing.

... and all the more confusing because MP3Tag (no doubt in the interest of consistency) uses the first variant throughout its documentation, irrespective of the tag format in use. I dare say that other programs take a similar approach. This is understandable, as a good tagging program mostly shields the user from the complexities of the various tagging schemes, so the majority of users will neither know nor care which scheme their files use, at least until they encounter a problem.

David

[simoncn]

(15-12-2014 19:31)DavidHB Wrote:  ... and all the more confusing because MP3Tag (no doubt in the interest of consistency) uses the first variant throughout its documentation, irrespective of the tag format in use. I dare say that other programs take a similar approach. This is understandable, as a good tagging program mostly shields the user from the complexities of the various tagging schemes, so the majority of users will neither know nor care which scheme their files use, at least until they encounter a problem.

David

I just looked again at the Vorbis specification. It uses "comment", "field" and "tag" to refer to the individual fields. For some reason, "tag" seems to have been generally adopted.

[magister]

(15-12-2014 18:53)simoncn Wrote:  Did you get any warnings from these files with MinimServer 0.8.2?

I have never seen this message before--but I upgraded from 8.1 to 8.3.

Quote:I think a change to MinimServer 0.8.3 is needed to move this check for illegal characters so it is performed only for tags that are used by MinimServer in some way. This means you would get the warning message only if you have put INVOLVED_PEOPLE_LIST in your indexTags, itemTags or aliasTags property.

This makes sense, and thanks as always for your prompt attention to such issues. When I add new music to my library, I always look at the log after rescanning. I've found this a good way to make sure I didn't make tagging errors and have occasionally found a file with other problems. Seeing that very long list of errors suddenly appear was unnerving.

[simoncn]

(15-12-2014 18:53)simoncn Wrote:  I think a change to MinimServer 0.8.3 is needed to move this check for illegal characters so it is performed only for tags that are used by MinimServer in some way. This means you would get the warning message only if you have put INVOLVED_PEOPLE_LIST in your indexTags, itemTags or aliasTags property. I will release an update soon (probably tomorrow) with this change.

This fix is now available in update 51.

[InfernoSTi]

(16-12-2014 22:17)simoncn Wrote:  This fix is now available in update 51.

Updated to 51 and I no longer have any error messages.

Thanks,
John

P.S. I did upload the one file since it threw a code previously...perhaps that will help you see what was triggering it?

[simoncn]

(17-12-2014 05:55)InfernoSTi Wrote:  Updated to 51 and I no longer have any error messages.

Thanks,
John

P.S. I did upload the one file since it threw a code previously...perhaps that will help you see what was triggering it?

Thanks for uploading this file. I checked it and the file is fine. The messages were caused by a bug in the original 0.8.3 code that incorrectly interpreted image data as being text data. This problem was fixed by the changes in update 51.

[simoncn]

(17-12-2014 05:55)InfernoSTi Wrote:  P.S. I did upload the one file since it threw a code previously...perhaps that will help you see what was triggering it?

I have looked at this file again and it does contain something unusual. There are two APIC frames. The first of these frames is valid and the second is corrupt (it has an incorrect picture type).

The original version of MinimServer 0.8.3 was reporting an error for an illegal character in the picture type string in the second APIC frame. The latest update is ignoring the second APIC frame because the picture type isn't recognized.