share disappearing in iTunes,but reappears on daemon restart

[deepdream00]

Hi,

after setting up Firefly on my Slug and using it from my WLAN attached Macbook I have this situation:

iTunes started: no share visible
either mt-daapd restarted or beacon in Network Beacon restarted: Share shows up and plays just fine (the beacon is not even needed, it just makes it possible for me to make the share show up without ssh-ing into the slug)

I understand Bonjour needs UDP, multicast and the like and that my wireless router may eat packages which it should forward. But what puzzles me is that I *can* make the share show up in iTunes easily just be restarting either mt-daapd on the slug or Network Beacon on my Mac. So obviously mt-daapd sends packets that get through which make iTunes on the Mac activate the share. Now if it would just always do that on its own!

Any idea how to solve this situation?

[rpedde]

@deepdream00 wrote:

Hi,

after setting up Firefly on my Slug and using it from my WLAN attached Macbook I have this situation:

iTunes started: no share visible
either mt-daapd restarted or beacon in Network Beacon restarted: Share shows up and plays just fine (the beacon is not even needed, it just makes it possible for me to make the share show up without ssh-ing into the slug)

I understand Bonjour needs UDP, multicast and the like and that my wireless router may eat packages which it should forward. But what puzzles me is that I *can* make the share show up in iTunes easily just be restarting either mt-daapd on the slug or Network Beacon on my Mac. So obviously mt-daapd sends packets that get through which make iTunes on the Mac activate the share. Now if it would just always do that on its own!

Any idea how to solve this situation?

It’s definitely a router issue. What’s happening is that when it starts, it sends out announcements to the network that it’s online. That’s what makes it pop up in iTunes. So multicast is working FROM the server TO the roku.

But then after a half hour or so, when the TTL expires on those announcements, the roku sends out a multicast query for the server. But the server obviously isn’t seeing those packets, and never responds, so it disappears off the browse list.

The “shows up on startup, goes away after a half hour” means that the device isn’t getting the multicast query packets. Either because UDP port 5353 from 224.0.0.251 is firewalled, or the router in between is eating the packets.

The only thing I know to do is upgrade firmware on the router, or see if there is an “enable multicast” or “enable igrp” checkbox in the router config, or put the server and client on the same side of the router — both wired or both wireless.

I’m slowly working toward upnp, and hopefully I can talk the roku guys into location the device via upnp as well as bonjour… ONE of those ways *has* to work.

— Ron

[deepdream00]

Thanks very much for your reply, your work is greatly appreciated!
I haven’t yet noticed the share disappearing in itunes after 30 minutes, I should do more tests on that. If the share appears, it tends to stick there until I restart iTunes. But then it won’t show up again until I restart Firefly on the slug or the beacon on the Mac.

Now whatever the restart of mt-daapd/mt-daapd sends, I have two questions:

a) is this specific packet creation/sending expensive resourcewise?
b) if not: could you add a debug flag to Firefly which allows it to be sent, say, every 20 seconds? I wouldn’t mind some bits of UDP traffic if Firefly would work perfectly afterwards. This of course would only be possible if the packet doesn’t break existing streams.

Cheers
deepdream

P.S.: My router sadly does not allow multicast control. But I could try to go hunting for specific packets if it could help you find the cause.

[Author]

Posts