Thanks, Nonreality and moley6knipe.

All tags are of the same "kind" (ID3v2.4, APE etc).

The issue does not appear to be related to the length of the
filename/tag.

All files are MP3.

I wasn't sure what to make of the reference that "iTunes is a lot less
tolerant of filename and path length than SqueezeCenter, I think". 
iTunes itself is able to read all the files in is XML library.  If you
mean that the iTunes import routine within SC7 is less tolerant than
the general routine that scans directories looking for music files,
then: This is possible.  I've not tried letting SC7 loose on the
directories in that way.

However, I do have a theory.  I'm not sure this explains 100% of the
issues, but it might.  It seems that the tracks that are rejected have
a different capitalization of the track name than either the XML
Location tag (in the iTunes XML library) or the MP3 tag.  (In the
examples that I've found, the XML Location tag and the MP3 tag have the
same capitalization, so I haven't been able to find out if it's one or
the other.)

So a file might be called "Popmusikerens Vise.mp3" while the XML tag
might contain the title "Popmusikerens vise" and the Location tag might
be "...Popmusikerens%20vise.mp3" (note the lower-case "v"; I've left out
the path).  

Presumably iTunes is case-insensitive in this regard, while SC7 isn't. 
Perhaps this is a result of running both on PCs and Macs...  The longer
the title, the more likely I am to have fiddled with at least one
letter, and also I'm more likely to have done it for international
titles (which I generally put in the capitalization of the actual
language).

How did this happen?  I'm quite particular about my track titles as
they appear in iTunes, and often I correct the capitalization after
ripping the CD.  Perhaps this leads to the observed behavior which you
might call a bug in iTunes.  iTunes shouldn't change the Location tag
just because the Name tag changes (or it should change the filename,
too).  By the way, I do the same with album names, but here iTunes
doesn't seem to fix the Location tag (at least I haven't noticed so
far).

Does anybody know the SC7 code well enough to say whether I'm right?

If yes, one solution might be for SC7 to check a lower-case version of
the Location tag against lower-case versions of the directory content
(at least optionally).  I realize this could be slow if people don't
keep the music sorted by artist and album, but keep everything in one
great big directory.  If people can point me to the right place in the
right script, I might just do this for myself.  (I don't know how to
make it properly available as an option in the web interface.)

Alternatively, I suppose I might write a script to fix the
capitalization of the Location tags vs the Name tags in the XML file,
once and for all.  I'm not quite sure whether iTunes will let this
stand, though.  I know there's both an XML file an an itl file with
some database representation.  Perhaps it would be better to fix the
actual filenames.

Or maybe there's a better way yet?  I've not tried mp3tag yet, as I'm
doing this from a Mac and mp3tag doesn't seem to exist in a Mac
version.  But I could do it from a Windows PC as well.

Soren


-- 
shein
------------------------------------------------------------------------
shein's Profile: http://forums.slimdevices.com/member.php?userid=14021
View this thread: http://forums.slimdevices.com/showthread.php?t=50032

_______________________________________________
discuss mailing list
[email protected]
http://lists.slimdevices.com/lists/listinfo/discuss

Reply via email to