Currently mediaservers offering DAAP or the generic RSP service will only work within the local subnet. This is because the multicast packets for the discovery are not routable.

The current way to circumvent this is to use VPN or ssh-tunnels, which works when one wants to connect via a computer to a remote DAAP or RSP mediaserver. This does not work from a SoundBridge as one cannot start a VPN or tunnel from it.
The only other way is running RendezvousProxy. But it requires a running computer in the same subnet as the Roku.

However it appears that the fireflymediaserver has no remote limitation like iTunes v>4.0, so all that should be required in the roku is a software update to allow discovery of DAAP and/or RSP mediaservers not only via the broadcast rendevous method from Apple but also from a manually entered IP/DNS:port location.

Please note that the problems which lead to Apples decision to turn this off in their software are nonexistant for the roku SoundBridges. It would be suficient if this was limited to a single manual discovery location.

Benefit:
----------

This would be nice for all people running Rokus is more than one houshold as well as anyone using a router which doesnt bridge the multicast packets or who uses generally a more complicated network topology.
We have someone coming with these problems to this forum at least once a week and currently we send em home to change their network or buy a new router.

-------------------

+1 on manual specification of the server address.

Sadly though, this feature probably violates the apple license?

It should not have anything to do with the Apple license or violate it (even not knowing what it reads). The IP discovery will NOT ALLOW you to connect to a iTunes server, as these wont stream files to a remote IP anyway IMHO. You need to use tunnels and such to trick iTunes into believing its a local connection. iTunes is uninteresting anyway for many.
The IP autodiscovery feature could also be limited to the RSP protocol if Roku feels there many be any probs with Apple. Then it wont even use their protocol and hence be no problem by definition.

The dynamic IP discovery will help you to connect to a firefly sevrer though, which is whats intended.

Knowing that the current beta is slowly reaching is promotion to stable and knowing that Rokus guys should likely weed through this forum soon, pls let me promote the feature a bit.

If implementing such a feature properly seems too much work due to having to document the new option, translating it to several languages and such, then please consider putting it in as an undocumented feature.

Lets see, I can already now set

Preset A1: RSP:xx.xx.xx.xx:yyyy

The problem is just that the Roku will neither check this at boot-up nor be able to understand it right now when I play preset A1. And technically it would be very simple to just put a few lines in that do this.

Please consider these points:

1. It may seem like a not proper way to do it to put it undocumented in. But actually those who have problems to connect to their RSP/DAAP servers will usually come to this forum or your support and then you tell em to buy a new router - thats not gonna make em happy. If you could tell em: "Its not documented yet but this is an easy and functional workaround..." then they would for sure be more happy!

2. This is by far not as spectacular a feature as a new codec or such. Its not likely to get noticed so easily. But it is also a very easy and memory-wise very concise feature to implement. And the benefit behind the scene is quite nice, as these multicast issues are really the achilles' heel of the otherwise simple discovery mechanism of DAAP/RSP. And this would allow it to work in all the problem cases.

Convinced? Or do we have to resort to bribery?

I agree with the feature request.

I was able to get around my issue by pluggin my NAS into my wireless AP, to get them on the same subnet. Many people I know with a NAS end up putting them in another room due to noise; I may end up doing the same. If I do move my NAS, the SoundBridge will no longer be on the same subnet.

Now in my case, the Infrant ReadyNas is supposed to include an embedded Firefly Media Server in its next release, so I could then use that. But Roku can't rely on NAS vendors to solve these issues.

A good friend of mine wrote the book on Bonjour "Zero Configuration Networking" and there is also a remote version of the API's for Bonjour that work across not only subnets, but the Internet itself. Perhaps a little more research by Roku will come up with the answer. Until then, a means is needed to specify the server.

As I already posted on the Firefly forums, multicasting may actually be possible. The problem is probably the TTL value that the Bonjour server uses. The default TTL value for multicasting is 1, which does not spread beyond the current subnet.

Each routers decreases the TTL value of packages it passes on, and when a packet reaches a TTL of 0, it "dies" and doesn't get forwarded any more. That's actually quite useful since it allows to control how far such general packets as especially multicasting packets are allowed to travel. If you do a "route print" at the command line, you'll see the metrics of each route.

So by changing the Bonjour server to at least advertise this one service (daap or rsp) with a TTL of 32 (whole site) this maybe could be solved. I'm just not sure if Howl or Avahi support a change of TTLs...

edit: ok, I'll have to correct myself... while TTL=1 is the default value, I could just verify through Wireshark that iTunes does MDNS queries with TTL=255, and Firefly answers with a TTL of 255 as well.
Has anyone captured the TTL level from a Roku yet?

edit 2: just tested, the Roku does use TTL=255 as well, so the multicasting packets should pass any router supporting multicasting and would not be stopped by a small TTL.

so the multicasting packets should pass any router supporting multicasting and would not be stopped by a small TTL.

There are however too many routers out there that dont really support multcasting bug-free and as soon as you wanna bridge anything over the internet or over any network part that you dont have 100% control of, then your anyway out of luck.

Sometimes a manual "discovery" option is simply the easiest work around for a certain set of possible problems.

One reason why Roku may shy back from implementing such a feature, despite the fact that its very simple and short to code, may also be the fact that any change in the interface would in principle require an adaptation of the handbook in several languages. I personally would rather have an undocumented feature than none at all.
After all also other stuff is not properly documented. E.g. how you set your SOundbridge to have its own manual, static IP without DHCP. Not in the handbook but you can find about it on this webpages.

Sometimes I wished the firmware was open source. But of course Apples DAAP license model will not allow this.