Hello, Ron.
Thanks for your prompt reply, and your idea regarding the alphabetic case of the path to the MP3 files. If I understand you correctly, your guess is that some or all of the file names in mt-daapd’s internal database (which are read in directly from the file “iTunes Music Library.xml”, right?) do not match exactly the paths on the mt-daapd server’s filesystem, because of case differences. This would not matter on OS X/HFS+, but *does* matter on Linux/ext3.
To test this, I tried the following experiment in order to test whether the “file://” URLs in the XML file are valid, both on the Mac and on the Linux Firefly server. I opened a (bash) shell window onto both systems and ran the following series of commands:
# Change directory to the directory with the iTunes XML file
cd /data/music/iTunes/
# Pull all the URLs from the XML file into a file in our home directory
grep -i 'file://' iTunes Music Library.xml | sed 's/.*file/file/' | sed 's/.*//' > ~/urls.txt
# Try to get each URL in turn, writing the results to ~/results.txt
URLS=`cat ~/urls.txt`
for URL in $URLS; do
echo getting $URL; curl $URL >/dev/null 2>&1;
if [ $? -gt 0 ] ; then echo ERROR Retrieving URL $URL ; fi;
done >~/results.txt
This bit of shell script works fine on both systems, and ‘grep ERROR ~/results.txt’ is enough to show that 229 of my 5175 URLs were not valid on the Linux system. This is about 4.4%, which I hope would not be enough to account for no tracks at all being shown by mt-daapd. This indicates to me that the case is correct for 95% of the tracks, and the case mismatch is not the source of the post-scan missing tracks.
Also, 208 URLs were not valid on the Mac either. On closer examination of these URLs, mostly the same ones as on the Linux system, they were caused by special characters (like a semicolon or ampersand) in an Album, Artist, or Track Name fields, which all get used in the storage path by iTunes. Apparently iTunes can generate and resolve these, while curl (used in the above test script) cannot. This again indicates to me that case mismatch is not the main source of my problem.
Finally, recall that right after Firefly is started, but before a scan is run, I can see all the tracks in iTunes, and stream them. As it turns out, this is true even for the tracks whose URLs are not valid in the above test. If there is a case problem, wouldn’t it manifest before the scan as well?
As per your generous invitation, I will email you the contents of my iTunes XML file, and the mt-daapd database file, both before and after the scan is run — as soon as I can find your correct email.
Thanks again for your assistance,
– Ann