My rio reciever keeps re-booting at the searching for music stage.
Please help.

I just now asked Hugo this very question, when I was having a beer with him night-before-last.

On my home network, I have a Rio Central that serves my receivers, as well as an Alcatel DSL modem that works as my internet router and DHCP server. I had exactly the same behavior you describe: The receiver says FOUND MUSIC SERVER, then it downloads its firmware from the server, shows its playback screen, says SEARCHING FOR MUSIC, then reboots. This continues in an infinite loop.

The only way I was able to get my receivers to talk to the central over this network was to put the central and the receivers on a different subnet than the rest of the network. For example, the Alcatel DSL modem is serving up addresses in the range of 192.168.0.x, and I had to make the rio central be in the range of 192.168.1.x.

Hugo explained it to me thusly:

The rio receiver and the rio central do a thing where the receiver accepts a DHCP address from the Central without confirming it. Then, after it downloads the firmware from the server, it tries to confirm the address. His guess was this: My Alcatel modem was denying the address confirmation that the Central had given out to the receiver.

I'm not sure how to solve this problem. I don't know if there's a checkbox on the Rio Central that allows the Receivers to get their DHCP address from the Alcatel router, yet still serve the Receivers. If so, I think that might be the solution. I'm currently waiting at the airport for my flight and will check this out when I get home.

Yup. Gotcha. So what's the best solution in this situation?

My current solution, putting the Central and the Receivers on a different subnet, doesn't work well because it prevents the Central from getting track details from the internet. Although that's currently the only drawback to this arrangement.

There doesn't appear to be an option in the Central's configuration screens that allows it to act as a Reciever-Server without ALSO being a DHCP server for those receivers. Unless I'm reading the screens wrong. Is there a way to do this?

Putting the Central into full-auto mode (getting its DHCP address from the Alcatel modem) is also not desirable because I want the Central to have a fixed IP address so that I can use my little Central Streamer applet with it (my applet doesn't have the ability to do a broadcast-search for the Central).

The Alcatel modem doesn't have an option to pre-assign DHCP addresses to specific devices, so I can't go that route.

Creating a separate always-on server computer just to be a proper full-featured DHCP server is not in the cards for me at the moment.

Something I haven't tried yet: Making the Alcatel's DHCP server and the Central's DHCP server hand out addresses in the same range. When first trying the setup, I had deliberately arranged it so that the two were in different ranges so they wouldn't clash. Maybe that was the root of my mistake?

Okay, in the end, here's what I did to fix the problem.

Set the Central to be my desired fixed address of 192.168.0.4
with a subnet mask of 255.255.0.0

Set my internet router to have a subnet mask of 255.255.255.0

Set the Central's "receivers" screen to make the receivers be in the address range of 192.168.1.142 through 149, with subnet masks of 255.255.0.0

This allows the receivers to get their DHCP requests ACK'd by the Central, while the internet router ignores them. The larger subnet allows the Central to continue to serve the receivers, even though the internet router doesn't talk to them. And the Central can still talk to the internet router and get to the internet for its gracenote lookups.

Yay!

Thanks for the tips, guys.

To the original poster of this thread: Hope this helps? Dunno whether you were running a Central or if you were running the ARM software. If you're running the ARM software, see if there's a setting that allows the receivers to get their DHCP addresses from your internet router instead of from ARM.