svn-1417 lose connection to soundbridge

[eagledart]

Hi,

(First, I just started using a FireFly this week – it’s great, way better than the second best media server. Thanks for putting so much effort into creating it and providing help via this forum – when I have some experiance I’ll try to repay in kind. However, for now I’m stuck….)

I’m using svn-1417 on a debian server, and connecting with an M1000 Roku, software version 2.5.174.

Most of my music is in ogg format and I’ve got the transcoding working a treat.

The Roku will play music all day if I let it – no problem. If I switch it off and straight back on, no problem reconnecting. If I switch it off and leave it ten minutes, it can’t reconnect to the server.

I’ve tried rebooting the Roku. Only thing that works is to kill all the mt-daapd processes (mt-daapd stop doesn’t work) and restart it.

The last bit of the log file (-d9) is:

Code:

2006-11-09 22:31:24 (00030004): Thread 9: Adding header *accept-encoding=gzip*
2006-11-09 22:31:24 (00030004): Added *accept-encoding=gzip*
2006-11-09 22:31:24 (00030004): Thread 9: Read: accept-codecs: wma,mpeg,wav,mp4a
2006-11-09 22:31:24 (00030004): Thread 9: Adding header *accept-codecs=wma,mpeg,wav,mp4a*
2006-11-09 22:31:24 (00030004): Added *accept-codecs=wma,mpeg,wav,mp4a*
2006-11-09 22:31:24 (00030004): Thread 9: Read: rsp-version: 0.1
2006-11-09 22:31:24 (00030004): Thread 9: Adding header *rsp-version=0.1*
2006-11-09 22:31:24 (00030004): Added *rsp-version=0.1*
2006-11-09 22:31:24 (00030004): Thread 9: Read: transcode-codecs: wav,mp3
2006-11-09 22:31:24 (00030004): Thread 9: Adding header *transcode-codecs=wav,mp3*
2006-11-09 22:31:24 (00030004): Added *transcode-codecs=wav,mp3*
2006-11-09 22:31:24 (00030004): Thread 9: Read:
2006-11-09 22:31:24 (00030004): Thread 9: Headers parsed!
2006-11-09 22:31:24 (00030004): Checking to see if connection matches keep-alive
2006-11-09 22:31:24 (00030004): Nope!
2006-11-09 22:31:24 (00030004): Thread 9: Connection type HTTP/1.0
: Connection: non-persist
2006-11-09 22:31:24 (00030004): Thread 9: Original URI: /rsp/info
2006-11-09 22:31:24 (00030004): Thread 9: Translated URI: /rsp/info
2006-11-09 22:31:24 (00030004): Thread 9: Preparing to find handler
2006-11-09 22:31:24 (00030004): Thread 9: URI Match!
2006-11-09 22:31:24 (00030004): Thread 9: Time is 1163111484 seconds after epoch
2006-11-09 22:31:24 (00030004): Thread 9: Setting time header
2006-11-09 22:31:24 (00030004): Added *Date=Thu, 9 Nov 2006 22:31:24 GMT*
2006-11-09 22:31:24 (00030004): Added *Connection=close*
2006-11-09 22:31:24 (00030004): Added *Server=mt-daapd/svn-1417*
2006-11-09 22:31:24 (00030004): Added *Content-Type=text/html*
2006-11-09 22:31:24 (00030004): Added *Content-Language=en_us*
2006-11-09 22:31:24 (00030004): Thread 9: Using non-default handler
2006-11-09 22:31:24 (00030004): in main_auth
2006-11-09 22:31:24 (00030004): Checking url /rsp/info
2006-11-09 22:31:24 (00030004): Dispatching auth for /rsp/info to plugin
2006-11-09 22:31:24 (00030004): Checking url /rsp/info
2006-11-09 22:31:24 (00030004): Dispatching /rsp/info to rsp/svn-1417
2006-11-09 22:31:24 (00030004): in main_handler
2006-11-09 22:31:24 (00030004): Checking url /rsp/info
2006-11-09 22:31:24 (00030004): Dispatching /rsp/info to plugin
2006-11-09 22:31:24 (00030004): Checking url /rsp/info
2006-11-09 22:31:24 (00030004): Dispatching /rsp/info to rsp/svn-1417
2006-11-09 22:31:24 (00030004): Getting uri…
2006-11-09 22:31:24 (00030004): Mallocing privinfo…
2006-11-09 22:31:24 (00030004): Tokenizing url
2006-11-09 22:31:24 (00030004): Found 5 elements
2006-11-09 22:31:24 (00030004): Checking reponse 0
2006-11-09 22:31:24 (00030004): Found it! Index: 0
2006-11-09 22:31:24 (00030004): Starting rsp_info
2006-11-09 22:31:24 (00030004): Gzipping output
2006-11-09 22:31:24 (00030004): Added *Content-Encoding=gzip*
2006-11-09 22:31:24 (00030004): Added *Vary=Accept-Encoding*
2006-11-09 22:31:24 (00030004): Updating Connection from close to Close
2006-11-09 22:31:24 (00030004): Added *Cache-Control=no-cache*
2006-11-09 22:31:24 (00030004): Added *Expires=-1*
2006-11-09 22:31:24 (00030004): Updating Content-Type from text/html to text/xml; charset=utf-8
2006-11-09 22:31:24 (00030004): Emitting reponse header Expires: -1
2006-11-09 22:31:24 (00030004): Emitting reponse header Cache-Control: no-cache
2006-11-09 22:31:24 (00030004): Emitting reponse header Vary: Accept-Encoding
2006-11-09 22:31:24 (00030004): Emitting reponse header Content-Encoding: gzip
2006-11-09 22:31:24 (00030004): Emitting reponse header Content-Language: en_us
2006-11-09 22:31:24 (00030004): Emitting reponse header Content-Type: text/xml; charset=utf-8
2006-11-09 22:31:24 (00030004): Emitting reponse header Server: mt-daapd/svn-1417
2006-11-09 22:31:24 (00030004): Emitting reponse header Connection: Close
2006-11-09 22:31:24 (00030004): Emitting reponse header Date: Thu, 9 Nov 2006 22:31:24 GMT
2006-11-09 22:31:24 (00030004): Executing: select count(*) FROM songs
2006-11-09 22:31:24 (00030004): Done sending xml stream
2006-11-09 22:31:24 (00030004): Thread 9: Terminating
2006-11-09 22:31:24 (00030004): Thread 9: Freeing request headers
2006-11-09 22:31:24 (00030004): Thread 9: Freeing response headers
2006-11-09 22:31:24 (00030004): Thread 9: Freeing request vars
2006-11-09 22:31:24 (00030004): Thread 9: Closing fd
2006-11-09 22:31:24 (00030004): With thread 9 exiting, 0 are still running
2006-11-09 22:34:58 (00004000): mDNS_Execute
2006-11-09 22:34:58 (00004000): Announcing _services._dns-sd._udp.local. (PTR) 0
2006-11-09 22:34:58 (00004000): Announcing _http._tcp.local. (PTR) 0
2006-11-09 22:34:58 (00004000): Announcing _services._dns-sd._udp.local. (PTR) 0
2006-11-09 22:34:58 (00004000): Announcing _rsp._tcp.local. (PTR) 0
2006-11-09 22:34:58 (00004000): Announcing _services._dns-sd._udp.local. (PTR) 0
2006-11-09 22:34:58 (00004000): Announcing _daap._tcp.local. (PTR) 0
2006-11-09 22:34:58 (00004000): SendResponses: Sending 0 Deregistrations, 6 Announcements, 0 Answers, 0 Additionals on 080985E8
2006-11-09 22:34:58 (00004000): SendResponses: Sending 0 Deregistrations, 6 Announcements, 0 Answers, 0 Additionals on 08099F38
2006-11-09 22:34:58 (00004000): SendResponses: Next in 2013265920 ticks
2006-11-09 22:34:58 (00004000): select(8, 0.098632)
2006-11-09 22:34:58 (00004000): SocketDataReady got a packet from 192.168.0.1 to 224.0.0.251 on interface 192.168.0.1/eth0/2
2006-11-09 22:34:58 (00004000): Received Response from 192.168.0.1 addressed to 224.0.0.251 on 080985E8 TTL 255 with 0 Questions, 6 Ans
wers, 0 Authorities, 0 Additionals
2006-11-09 22:34:58 (00004000): SocketDataReady ignored a packet from 192.168.0.1 to 224.0.0.251 on interface /2 expecting 192.168.2.25/wlan0/3
2006-11-09 22:34:58 (00004000): select(8, 0.098632)
2006-11-09 22:34:58 (00004000): SocketDataReady ignored a packet from 192.168.2.25 to 224.0.0.251 on interface /3 expecting 192.168.0.1/eth0/2
2006-11-09 22:34:58 (00004000): SocketDataReady got a packet from 192.168.2.25 to 224.0.0.251 on interface 192.168.2.25/wlan0/3
2006-11-09 22:34:58 (00004000): Received Response from 192.168.2.25 addressed to 224.0.0.251 on 08099F38 TTL 255 with 0 Questions, 6 Ans
wers, 0 Authorities, 0 Additionals
2006-11-09 22:34:58 (00004000): select(8, 0.098632)
2006-11-09 22:34:58 (00004000): mDNS_Execute
2006-11-09 22:34:58 (00004000): select(8, 1965578.768554)

Any ideas? I saw a post somewhere that mention something vaguely similar, something about TCP getting interupted? If so, how could I check for and stop this?

Thanks,
Greg

[rpedde]

@eagledart wrote:

The Roku will play music all day if I let it – no problem. If I switch it off and straight back on, no problem reconnecting. If I switch it off and leave it ten minutes, it can’t reconnect to the server.

that’s almost always and issue of the machine not seeing the dns-sd queries.

Usually, that’s because of a firewall, but it doesn’t look like it in your case:

2006-11-09 22:34:58 (00004000): SocketDataReady ignored a packet from 192.168.2.25 to 224.0.0.251 on interface /3 expecting 192.168.0.1/eth0/2

2006-11-09 22:34:58 (00004000): SocketDataReady got a packet from 192.168.2.25 to 224.0.0.251 on interface 192.168.2.25/wlan0/3

2006-11-09 22:34:58 (00004000): Received Response from 192.168.2.25 addressed to 224.0.0.251 on 08099F38 TTL 255 with 0 Questions, 6 Ans

That’s the problem. It sees the dns-sd queries, then throws them away. Is your network really multi-netted? Are you running a 192.168.0.0/24 and 192.168.2.0/24 network on one interface?

That seems to be the problem. It’s getting queries on an interface it doesn’t expect to. What does your network setup look like?

From here, it looks like you have one interface with multiple ip addresses (on different subnets) set up on it. Is that right?

[eagledart]

Wow. I’m impressed. You can tell all that?

My media server was connected to the network via a wireless card, I’m still learning about networking, so it is entirely possible that I also had eth0 configured on a different subnet. But there was no cable plugged in, so would that matter?

The media server (running firefly) is (was) in the cupboard under the stairs running Debian headless (no monitor, etc). Last night I read on the forums that this issue might be due to firewall issues, so I messed around (via ssh) with iptables and firestarter, untill I locked myself out. Doh!

So I dragged it out of the cupboard to connect it up to a monitor, keyboard, etc and dropped it. Bigger Doh! So now that’s completely knackered. Doh doh doh. Luckily the drive with all my media on is OK. But basically I need to rebuild my media server machine today.

When I’ve done that, I’ll ensure I configure only one network interface and not install any firewall stuff – untill I’ve got it working properly.

Thanks for your help, I’ll let you know how I get on. Now where’s that screwdriver….

[rpedde]

@eagledart wrote:

My media server was connected to the network via a wireless card, I’m still learning about networking, so it is entirely possible that I also had eth0 configured on a different subnet. But there was no cable plugged in, so would that matter?

Wouldn’t have thought so either, but apparently so.

The media server (running firefly) is (was) in the cupboard under the stairs running Debian headless (no monitor, etc). Last night I read on the forums that this issue might be due to firewall issues, so I messed around (via ssh) with iptables and firestarter, untill I locked myself out. Doh!

D’oh!

Word to the wise — I’ve not heard any reports of anyone getting multicast to work with firestarter. Not to say that it’s not possible, just that I’ve not heard any success reports, just failure reports.

So I dragged it out of the cupboard to connect it up to a monitor, keyboard, etc and dropped it. Bigger Doh! So now that’s completely knackered. Doh doh doh. Luckily the drive with all my media on is OK. But basically I need to rebuild my media server machine today.

Ooh. Sounds like a bad day. 🙁 Sorry to be the impetus for it. Hope the repair goes well.

— Ron

[Author]

Posts