You are here: Home » Topic » Rendezvous going silent after 2 hours?

Rendezvous going silent after 2 hours?

This topic contains 2 replies, has 1 voice, and was last updated by  michaelm 11 years, 1 month ago.

Viewing 3 posts - 1 through 3 (of 3 total)
  • Author
    Posts
  • #440

    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

    #5546

    rpedde
    Participant

    @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

    #5547

    michaelm

    Thanks Ron,

    That was the solution.

    Michael

Viewing 3 posts - 1 through 3 (of 3 total)

You must be logged in to reply to this topic.