I can confirm the RSP playlist sorting bug is resolved. In addition, the random ordering I saw on .m3u playlists is gone for both RSP and DAAP… it’s all in correct order now. Yay!
So, I did get to test a little more… and my odd filename display vs. playlist issue is most likely a problem with iTunes and the iTunes XML I was testing with. I didn’t get any “track name is filename” issues until I augmented the data with the iTunes .XML. Until then, it’s all fine. So, I rebuilt the iTunes database… and I think it’s better now.
The “Playlist entry bad: Path not found” error that I see in debug log when parsing my .m3u file is probably the blank line entries. There should be some text between “entry” and “bad” if there is something wrong in the file, right? So, I guess that’s a bug… Firefly should not consider blank lines as errors when parsing .m3u files.
Update: Another benchmark for a full scan on a fairly busy box, including iTunes XML… again, it’s the “Playlist loop” part that includes the iTunes XML parsing that is taking a long time:
2006-08-14 10:06:07 (f3f11f6d): Starting mp3 scan
2006-08-14 10:12:05 (f3f11f6d): Ending song scan
2006-08-14 10:12:06 (f3f11f6d): Processing playlists
2006-08-14 11:04:07 (f3f11f6d): Finished playlist loop
2006-08-14 11:04:09 (f3f11f6d): Serving 20642 songs. Startup complete in 3662 seconds