Empty iTunes playlists

[Anonymous]

Hello, all.

I am having trouble getting the contents of my playlists from “iTunes Music Library.xml” to appear. The playlists themselves show up in remote iTunes clients, but with no tracks visible. Strangely, the playlists *do* appear correct in mt-daapd’s administrative web interface — at least, they show the correct number of tracks listed under “Count”.

I am running mt-daapd on an i686-based Fedora 6 system. My mt-daapd was built from the latest (as of this writing) SVN trunk, which is revision 1709. Here is my usage case in a nutshell:

I maintain my music library on a Mac desktop, using the latest iTunes software (currently 7.5.19). I use rsync to push my library to to the Fedora system that runs mt-daapd. When I start mt-daapd, and connect to it with iTunes (from the Mac), no playlists initially appear, but all of the tracks *do* appear (in fact, each appears twice, for some reason). At this stage, I can stream any track just fine, but I have no playlists.

If I force a scan using the mt-daapd administrative web interface, I see messages in the log file like “Adding item 270 to playlist 22”, and “New playlist size: 313”, which is encouraging. Indeed, when the scan is done, the admin interface then shows all my “Smart Playlists”, with the correct number of tracks listed under “Count”.

I then need to force a disconnect, and reconnect from the iTunes client in order to make the playlists appear. But when I do so, all the tracks themselves are gone, and I see nothing but empty playlists! When reconnecting, I see log messages like “Ending playlist enumeration”, but again, no tracks in iTunes.

So the odd thing is that it looks like individual tracks are being found before the scan, and playlists after the scan, but at no point are both available! 🙁

Now, the path to the library on the Mac is not the same as the path on the Fedora server, so I tried the following.
The command:
grep ‘file://’ “iTunes Music Library.xml”
shows that the XML library contains references to “file://localhost/data/music/iTunes/iTunes%20Music/…”, so I made a symlink on the Fedora system which points from “/data/music/iTunes/iTunes Music” to the correct location on the server, so that the URI resolves correctly on the Fedora server’s command-line. Sadly, this bit of chicanery seemed to make no difference whatever. 😕

What could cause the iTunes playlists look correct in the mt-daapd web interface, but show up with no tracks in iTunes?

Any ideas are appreciated.

Thanks in advance,
– Ann

[rpedde]

@ann_onemouse2 wrote:

Hello, all.

I am having trouble getting the contents of my playlists from “iTunes Music Library.xml” to appear. The playlists themselves show up in remote iTunes clients, but with no tracks visible. Strangely, the playlists *do* appear correct in mt-daapd’s administrative web interface — at least, they show the correct number of tracks listed under “Count”.

I am running mt-daapd on an i686-based Fedora 6 system. My mt-daapd was built from the latest (as of this writing) SVN trunk, which is revision 1709. Here is my usage case in a nutshell:

I maintain my music library on a Mac desktop, using the latest iTunes software (currently 7.5.19). I use rsync to push my library to to the Fedora system that runs mt-daapd. When I start mt-daapd, and connect to it with iTunes (from the Mac), no playlists initially appear, but all of the tracks *do* appear (in fact, each appears twice, for some reason). At this stage, I can stream any track just fine, but I have no playlists.

If I force a scan using the mt-daapd administrative web interface, I see messages in the log file like “Adding item 270 to playlist 22”, and “New playlist size: 313”, which is encouraging. Indeed, when the scan is done, the admin interface then shows all my “Smart Playlists”, with the correct number of tracks listed under “Count”.

I then need to force a disconnect, and reconnect from the iTunes client in order to make the playlists appear. But when I do so, all the tracks themselves are gone, and I see nothing but empty playlists! When reconnecting, I see log messages like “Ending playlist enumeration”, but again, no tracks in iTunes.

So the odd thing is that it looks like individual tracks are being found before the scan, and playlists after the scan, but at no point are both available! 🙁

Now, the path to the library on the Mac is not the same as the path on the Fedora server, so I tried the following.
The command:
grep ‘file://’ “iTunes Music Library.xml”
shows that the XML library contains references to “file://localhost/data/music/iTunes/iTunes%20Music/…”, so I made a symlink on the Fedora system which points from “/data/music/iTunes/iTunes Music” to the correct location on the server, so that the URI resolves correctly on the Fedora server’s command-line. Sadly, this bit of chicanery seemed to make no difference whatever. 😕

What could cause the iTunes playlists look correct in the mt-daapd web interface, but show up with no tracks in iTunes?

Any ideas are appreciated.

Thanks in advance,
– Ann

I think I’d have to see your db and the xml file to figure it out. My best guess is that the case of the filenames in the iTunes xml is different than the case on the file system. On osx, it doens’t matter, as the file systme is case insensitive, but on ubuntu, of course, it does.

You could email me your db and xml file, and I could see if that’s indeed the case.

— Ron

[Anonymous]

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

[rpedde]

@ann_onemouse2 wrote:

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?

One would think so. Truly I can’t imagine how this would happen.

Oh, and another thing that might help is a -d9 debug logfile during the scan.

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

Ah, sorry… that would be [email protected]

— Ron

[Author]

Posts