Rendezvous going silent after 2 hours?

[michaelm]

I’ve recently gotten mt-daapd 0.2.4 running on SUSE 10.1 which is running on a Celeron based laptop with the music stored on a USB drive.

Mt-daapd runs fine for about two hours and then can no longer be seen by my Roku.
a ps shows two mt-daapd processes running. The web interface shows both mt-daapd and Rendezvous running.

If I have auto rescan turned on, the logs show the scan going on at regular intervals.

If I’m not playing any music and no rescan, the logs show nothing over the period where it goes silent (debug set to 9).

If I am playing music, I show the following interaction about 2 hours after startup (once it was 2:02, the other time I logged it was 1:56):

2006-07-13 18:35:46: Session 1: Streaming file '04 Dicen Que Soy.m4a' to 192.168.1.100 (offset 54898)

2006-07-13 18:35:46: Seeking to offset 54898

2006-07-13 18:37:26: Thread 66: Entering ws_dispatcher (Connection from 192.168.1.100)

2006-07-13 18:37:26: Thread 66: got request

2006-07-13 18:37:26: Request: GET /logout?session-id=1 HTTP/1.0



2006-07-13 18:37:26: Thread 66: Read: User-Agent: Roku SoundBridge/2.5



2006-07-13 18:37:26: Thread 66: Adding header *User-Agent=Roku SoundBridge/2.5*

2006-07-13 18:37:26: Added *User-Agent=Roku SoundBridge/2.5*

2006-07-13 18:37:26: Thread 66: Read: Host: 192.168.1.78:3689



2006-07-13 18:37:26: Thread 66: Adding header *Host=192.168.1.78:3689*

2006-07-13 18:37:26: Added *Host=192.168.1.78:3689*

2006-07-13 18:37:26: Thread 66: Read: Accept: */*



2006-07-13 18:37:26: Thread 66: Adding header *Accept=*/**

2006-07-13 18:37:26: Added *Accept=*/**

2006-07-13 18:37:26: Thread 66: Read: Pragma: no-cache



2006-07-13 18:37:26: Thread 66: Adding header *Pragma=no-cache*

2006-07-13 18:37:26: Added *Pragma=no-cache*

2006-07-13 18:37:26: Thread 66: Read: Client-DAAP-Version: 1.0



2006-07-13 18:37:26: Thread 66: Adding header *Client-DAAP-Version=1.0*

2006-07-13 18:37:26: Added *Client-DAAP-Version=1.0*

2006-07-13 18:37:26: Thread 66: Read: Client-DMAP-Version: 1.0



2006-07-13 18:37:26: Thread 66: Adding header *Client-DMAP-Version=1.0*

2006-07-13 18:37:26: Added *Client-DMAP-Version=1.0*

2006-07-13 18:37:26: Thread 66: Read:



2006-07-13 18:37:26: Thread 66: Headers parsed!

2006-07-13 18:37:26: Checking to see if connection matches keep-alive

2006-07-13 18:37:26: Thread 66: Connection type HTTP/1.0



: Connection: non-persist

2006-07-13 18:37:26: Thread 66: parsing GET args

2006-07-13 18:37:26: Thread 66: Entering ws_getgetvars (session-id=1)

2006-07-13 18:37:26: Thread 66: Adding arg session-id = 1

2006-07-13 18:37:26: Added *session-id=1*

2006-07-13 18:37:26: Thread 66: Done parsing GET/POST args!

2006-07-13 18:37:26: Thread 66: Original URI: /logout

2006-07-13 18:37:26: Thread 66: Translated URI: /logout

2006-07-13 18:37:26: Thread 66: Preparing to find handler

2006-07-13 18:37:26: Thread 66: URI Match!

2006-07-13 18:37:26: Thread 66: Time is 1152841046 seconds after epoch

2006-07-13 18:37:26: Thread 66: Setting time header

2006-07-13 18:37:26: Added *Date=Fri, 14 Jul 2006 01:37:26 GMT*

2006-07-13 18:37:26: Thread 66: Using non-default handler

2006-07-13 18:37:26: Added *Accept-Ranges=bytes*

2006-07-13 18:37:26: Added *DAAP-Server=mt-daapd/0.2.4*

2006-07-13 18:37:26: Added *Content-Type=application/x-dmap-tagged*

2006-07-13 18:37:26: Entering config_set_status

2006-07-13 18:37:26: Exiting config_set_status

2006-07-13 18:37:26: Thread 66: Entering ws_returnerror (204: Logout Successful)

2006-07-13 18:37:26: Added *Connection=close*

2006-07-13 18:37:26: Emitting reponse header Connection: close

2006-07-13 18:37:26: Emitting reponse header Content-Type: application/x-dmap-tagged

2006-07-13 18:37:26: Emitting reponse header DAAP-Server: mt-daapd/0.2.4

2006-07-13 18:37:26: Emitting reponse header Accept-Ranges: bytes

2006-07-13 18:37:26: Emitting reponse header Date: Fri, 14 Jul 2006 01:37:26 GMT

2006-07-13 18:37:26: Entering config_set_status

2006-07-13 18:37:26: Exiting config_set_status

2006-07-13 18:37:26: Thread 66: Terminating

2006-07-13 18:37:26: Thread 66: Freeing request headers

2006-07-13 18:37:26: Thread 66: Freeing response headers

2006-07-13 18:37:26: Thread 66: Freeing request vars

2006-07-13 18:37:26: Thread 66: Closing fd

2006-07-13 18:37:26: With thread 66 exiting, 1 are still running

2006-07-13 18:37:26: Finished streaming file to remote: 2326528 bytes

2006-07-13 18:37:26: Entering config_set_status

2006-07-13 18:37:26: Exiting config_set_status

2006-07-13 18:37:26: Finished serving DAAP response

2006-07-13 18:37:26: Entering config_set_status

2006-07-13 18:37:26: Exiting config_set_status

2006-07-13 18:37:26: Thread 65: Terminating

2006-07-13 18:37:26: Thread 65: Freeing request headers

2006-07-13 18:37:26: Thread 65: Freeing response headers

2006-07-13 18:37:26: Thread 65: Freeing request vars

2006-07-13 18:37:26: Thread 65: Closing fd

2006-07-13 18:37:26: With thread 65 exiting, 0 are still running

Any idea of what could be going on and how to cure it?

Thanks

Michael

[rpedde]

@michaelm wrote:

Mt-daapd runs fine for about two hours and then can no longer be seen by my Roku.
a ps shows two mt-daapd processes running. The web interface shows both mt-daapd and Rendezvous running.

problems like this, where the server is visible on startup but then disappears, are almost always due to firewalling on the mt-daapd server.

Make sure you aren’t firewalling multicast DNS (port 5353 from/to ip address 224.0.0.251).

That’s likely it.

— Ron

[michaelm]

Thanks Ron,

That was the solution.

Michael

[Author]

Posts