I Need More Heavy Fuel

I thought I didn't have much to report tonight, but upon reflection it seems that I might have been wrong. I found (and fixed) the problem with ogg playback that caused it to play the same song over and over. Then I thought I had a problem when the first file in an album was an ogg file, but it turned out that mt-daapd was having database problems and could no longer find that particular file. Forcing it to update its database entry for that song ("Dire Straits - Calling Elvis") allowed the song to play again. The tip-off was when I logged into the wmaa11b and ran wmamp myself: whenever I tried to play this song it received a 404 from mt-daapd, but the file was clearly present in the directory on the server.

My other small accomplishment for the evening was fixing the basic playback functions. My earlier builds would not pause, stop, back up a track or skip ahead a track. That's working now, which is pretty sweet. I let them wma11b run for a while, playing The Cars Greatest Hits album. I wasn't really paying attention to the music, and then I noticed that it seemed to be playing the last song over and over. And it does. Once the list is complete it just keeps playing the last song. I figured this was probably another bug I'd introduced, but the wmamp 0.6 image that I have does the same thing. I would have expected the playlist to loop, or for play to simply end when the list was exhausted, but neither happens. I wonder what the right behaviour is...

I think I have learned why libopendaap isn't being used by wmamp (a question I was pondering in yesterday's entry): it's more than a little tricky to use, and the memory profile may not fit very well with the wma11b. When you make a song request with libopendaap it writes the data to a file descriptor. The fd could be a file, but the recommendation is to use a pipe. This is a cool idea - threads in libopendaap are pulling all the data over the network and all the playback thread has to do is take as much data as it needs from the pipe. The problem is that libopendaap will almost certainly pull megabytes of data in long before (in processor time) it is needed. The wma11b has only 16MB, and a lot of that is already being used by the kernel, the root filesystem and the application file system. This does not leave a lot for applications to run in. I seem to recall reading somewhere that after everything is loaded there's only 5-6MB available for application use. An entire mp3 buffered in memory suddenly means there's nothing available for the application to use any more. wmamp uses more of a just-in-time principle - the data is pulled over the network just before its needed, and it seems to work pretty well. What I do think is worthwhile is to replace Apple's mDNSResponder software with the mdnsd the libopendaap is using. I believe that will be my project for tomorrow night.