Bug 13921 - Scanner fails on UTF16 names.
: Scanner fails on UTF16 names.
Status: CLOSED FIXED
Product: Logitech Media Server
Classification: Unclassified
Component: Scanner
: 7.4.0
: PC Debian Linux
: P1 normal (vote)
: 7.4.0
Assigned To: Andy Grundman
: Audio::Scan
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-09-08 22:46 UTC by snarlydwarf
Modified: 2009-10-05 14:26 UTC (History)
2 users (show)

See Also:
Category: ---


Attachments
Demonstrates UTF16 not being recognized in Artist fields on MP3 (11.31 MB, application/octet-stream)
2009-09-09 09:59 UTC, snarlydwarf
Details

Note You need to log in before you can comment on or make changes to this bug.
Description snarlydwarf 2009-09-08 22:46:59 UTC
The attached file breaks the scanner:

+----------+----------------------+------------+
| name     | namesort             | namesearch |
+----------+----------------------+------------+
| Obo Addy | ��A D D Y     O B O | OBO ADDY   | 
+----------+----------------------+------------+

The namesort is left as UTF16.
Comment 1 Andy Grundman 2009-09-09 04:56:16 UTC
Did you forget to attach the file?
Comment 2 snarlydwarf 2009-09-09 09:59:30 UTC
Created attachment 5809 [details]
Demonstrates UTF16 not being recognized in Artist fields on MP3
Comment 3 Andy Grundman 2009-09-09 10:10:04 UTC
Aha, looks like I'm not parsing XSOP correctly.  All the other UTF-16 tags are fine but not that one, hmm.  Will investigate a bit more and see where the bug is.

  tags => {
            ALBUMARTISTSORT => "Kronos Quartet",
            ASIN => "B000005J15",
            CATALOGNUMBER => "79275-2",
            "MUSICBRAINZ ALBUM ARTIST ID" => "f5586dfa-7031-4af0-8042-19b6a1170389",
            "MUSICBRAINZ ALBUM ID" => "680c65e1-f3a1-48ee-997a-4b2a92f59650",
            "MUSICBRAINZ ALBUM RELEASE COUNTRY" => "US",
            "MUSICBRAINZ ALBUM STATUS" => "official",
            "MUSICBRAINZ ALBUM TYPE" => "album",
            "MUSICBRAINZ ARTIST ID" => "bd297b96-57d1-434a-80d6-f07f1c6df0c4",
            "MUSICIP PUID" => "56376896-f6c3-344d-f9da-b1fc397521e2",
            PRIV => [["PeakValue", "\24]\0\0"], ["AverageLevel", "&\n\0\0"]],
            TALB => "Pieces of Africa",
            TCMP => 1,
            TCON => "Other",
            TDRC => "1992-02-14",
            TIPL => ["orchestra", "Kronos Quartet"],
            TIT2 => "Wawshishijay (Our Beginning)",
            TPE1 => "Obo Addy",
            TPE2 => "Kronos Quartet",
            TPUB => "Nonesuch",
            TRCK => "6/12",
            UFID => [
                  "http://musicbrainz.org",
                  "aed13cc6-89af-4b86-a62f-b3b193e930f6",
                ],
            XSOP => "\1\xFF\xFEA\0d\0d\0y\0,\0 \0O\0b\0o",
          },
Comment 4 Andy Grundman 2009-09-09 10:20:28 UTC
Yeah the reason is XSOP is not a real ID3v2.3 tag, so it just comes back as binary data instead of text. I will add a special case for it.
Comment 5 SVN Bot 2009-09-09 10:50:31 UTC
 == Auto-comment from SVN commit #418 to the opensource repo by andy ==
 == https://svn.slimdevices.com/opensource?view=revision&revision=418 ==

Fixed bug 13921, added support for ID3v2.3 experimental XSOP frame
Comment 6 SVN Bot 2009-09-09 11:33:28 UTC
 == Auto-comment from SVN commit #28483 to the slim repo by andy ==
 == https://svn.slimdevices.com/slim?view=revision&revision=28483 ==

Audio::Scan 0.32:
Bug 13921, added support for ID3v2.3 experimental XSOP frame.
Comment 7 Jim McAtee 2009-09-09 11:48:44 UTC
What is an XSOP frame doing in an ID3v2.4 tag?

From the musicbrainz.com web site:

"The artist sortname should really be stored in a ID3v2.4 frame called TSOP, but that is not supported under ID3v2.3. For writing ID3v2.3 tags, a XSOP frame that is formatted like a regular text frame should be used. You should never write a XSOP frame in ID3v2.4 tag."

I suppose it can't hurt to deal with it in any ID3v2 tag, no matter the version, but I would hope TSOP takes precedence if both happen to be present.
Comment 8 Andy Grundman 2009-09-09 11:54:47 UTC
This is an ID3v2.3 file.
Comment 9 James Richardson 2009-10-05 14:26:48 UTC
This bug has been marked as fixed in the 7.4.0 release version of SqueezeBox Server!
    * SqueezeCenter: 28672
    * Squeezebox 2 and 3: 130
    * Transporter: 80
    * Receiver: 65
    * Boom: 50
    * Controller: 7790
    * Radio: 7790  

Please see the Release Notes for all the details: http://wiki.slimdevices.com/index.php/Release_Notes

If you haven't already, please download and install the new version from http://www.logitechsqueezebox.com/support/download-squeezebox-server.html

If you are still experiencing this problem, feel free to reopen the bug with your new comments and we'll have another look.