xml not parsing unusual characters

[falling_in2_infinity]

Hi there all,

I wonder if anyone else has a problem with getting the firefly server to parse iTunes xml data that includes non-english characters, such as the accent above the ‘o’ in ‘Sigur Rós’. It appears to be a problem that applies to the song name, directory location and artist name. This leaves me with several albums that have no tags when viewing the server on either itunes, or the soundbridge.

I wonder if there’s a quick fix that I’m overlooking, or do I have to manually edit the tags for each track?

Incidentally, I’m using mt-daapd on the nslu2 and serving only .Wav files.

Thanks in advance!

…Joe.

[fizze]

That would depend on the encoding of the iTunes.xml file. Maybe iTunes even strips that info, of firefly doesnt correctly interpret the codepage.
To verify what iTunes uses, open the iTunes.xml in a text-editor and see the codepage or encoding attribute in the xml header.
Then search your Sigor Ròs Album and actually look at the tags. If the tag is just like “Sigur Ros”, your iTunes is acting up.

[rpedde]

@fizze wrote:

That would depend on the encoding of the iTunes.xml file. Maybe iTunes even strips that info, of firefly doesnt correctly interpret the codepage.
To verify what iTunes uses, open the iTunes.xml in a text-editor and see the codepage or encoding attribute in the xml header.
Then search your Sigor Ròs Album and actually look at the tags. If the tag is just like “Sigur Ros”, your iTunes is acting up.

I think (?) that iTunes keeps it in utf-8 on both windows and mac platforms. So metadata from iTunes is read in as utf-8, and special characters are honored.

Metadata in the files themselves might be hosed if the id3v2 data is marked as latin1, when it’s really native codepage other than latin1, but that’s a tagging error.

The only real outstanding problem is mapping utf-8 paths (like are stored in iTunes) to a file that sits on a non-utf-8 file system, like files copied via old samba servers.

That’s likely the problem. The only real fix I know is to fix the file system up to really be utf-8 and upgrade to samba 3 or better.

[falling_in2_infinity]

Ahh, that makes sense Ron… thanks!

I’ll look into that… I’m using an ms-dos partitioned external disk, but I’ve not copied anything via samba. I’ll see about setting the disk to utf-8 and see what happens.

Thanks again.

[fizze]

well dos-based would be FAT16, or VFAT then, at best.
So that would explain why the special characters are fubar 😉

[rpedde]

@fizze wrote:

well dos-based would be FAT16, or VFAT then, at best.
So that would explain why the special characters are fubar 😉

Yup yup. There is special-case hackishness for NTFS though, so NTFS would work okay, too.

Also fat also causes problems with determining file time. Seems like it always returns localtime rather than utc, or something. Something that messed up scanning, anyway.

[falling_in2_infinity]

I’ve not experienced those problems with my FAT drive mounted on my suse box, nor under osx.

I thought the nature of the character set was controlled partly on mounting. I’ve not got round to it yet, but I think I’ll try mounting the shared drive as utf-8 before re-formatting as something different (this would be a pain in the neck, as there’s about 350GB of music on the drive).

[rpedde]

@falling_in2_infinity wrote:

I thought the nature of the character set was controlled partly on mounting. I’ve not got round to it yet, but I think I’ll try mounting the shared drive as utf-8 before re-formatting as something different (this would be a pain in the neck, as there’s about 350GB of music on the drive).

That might work, if the file system does codepage->utf conversions on the fly. Good call. I’d be interested in hearing if this worked.

— Ron

[Author]

Posts