server shows in iTunes but not browseable

[Anonymous]

I’ve searched all 12 pages of posts, but found no exact match. I’m running stable 0.2.3-1 mt-daapd on unslung 5.5 on NSLU. It appears to be using gdbm 1.8.3-2. I get it to run with varying results. It shows up in iTunes, but is not browsable if all 1700+ songs are included. I’ve created a new dir and added 1 folder of songs by artist at a time, restarting mt-daapd with -d9 -r flags after each add. I got to around 188 songs, and it was still browsable. I added my Cake folder (6 songs), and it was no longer browsable. Ok, found the problem, right? Something in the Cake folder. I put Cake in it’s own dir, repoint mt-daapd to that folder and restart. Works fine, browsable. I’m at a loss. This is all the log shows when the client connects (it rescans, then this):

2006-01-28 18:23:51: Got entry for 02 Enid.mp3
2006-01-28 18:23:51: Successfully enumerated database – 188 items
2006-01-28 18:23:51: Exiting daap_response_songlist
2006-01-28 18:23:51: Entering config_set_status
2006-01-28 18:23:51: Exiting config_set_status
2006-01-28 18:23:51: Satisfying request
2006-01-28 18:23:51: Serializing
2006-01-28 18:23:51: Added *Content-Length=61669*
2006-01-28 18:23:51: Emitting headers
2006-01-28 18:23:51: Emitting reponse header Content-Length: 61669
2006-01-28 18:23:51: Emitting reponse header Content-Type: application/x-dmap-tagged
2006-01-28 18:23:51: Emitting reponse header DAAP-Server: mt-daapd/0.2.3
2006-01-28 18:23:51: Emitting reponse header Accept-Ranges: bytes
2006-01-28 18:23:51: Emitting reponse header Date: Sat, 28 Jan 2006 23:23:51 GMT
2006-01-28 18:23:52: Sent 61669 bytes in 1 seconds
2006-01-28 18:23:52: Done, freeing
2006-01-28 18:23:52: Finished serving DAAP response
2006-01-28 18:23:52: Entering config_set_status
2006-01-28 18:23:52: Exiting config_set_status
2006-01-28 18:23:52: Thread 1: Terminating
2006-01-28 18:23:52: Thread 1: Freeing request headers
2006-01-28 18:23:52: Thread 1: Freeing response headers
2006-01-28 18:23:52: Thread 1: Freeing request vars
2006-01-28 18:23:52: Thread 1: could not read: Broken pipe
2006-01-28 18:23:52: Entering config_set_status
2006-01-28 18:23:52: Exiting config_set_status
2006-01-28 18:23:52: Thread 1: Terminating
2006-01-28 18:23:52: Thread 1: Freeing request headers
2006-01-28 18:23:52: Thread 1: Freeing response headers
2006-01-28 18:23:52: Thread 1: Freeing request vars
2006-01-28 18:23:52: Thread 1: Closing fd
2006-01-28 18:23:52: With thread 1 exiting, 0 are still running

Post edited by: Jack, at: 2006/01/29 14:33

[rpedde]

Make a database that *doesn’t* work, run a -d9 with a logfile specified in the config file, then zip and email me the log at ron at pedde.com.

Another thing to try, just for grins, would be to turn off m3u processing. See what that does.

— Ron

[Jack]

#process_m3u 0 is still commented out in the mt-daapd.conf file, so I assume this means it isn’t processing m3u’s (as documented). On this last run, I also commented out the “playlist” option.

I’ll be sending the log files soon. I’m hoping this is something simple, as it seems to work for most other people, I just can’t find it. It’s killing me.

[rpedde]

Is this iTunes or a libopendaap client?

The “could not read” is almost always iTunes closing the connection. But you could always run -d9 and email me the log file at ron at pedde.com.

— Ron

[rpedde]

By way of update, this was a “mt-daapd 0.2.3 versus iTunes 6.0.4” problem. mt-daapd loses. 🙂

The 0.2.4 version (available to the left!) should fix that.

— Ron

[Author]

Posts