I'm having the "waiting for retry" problem, too. I'm using:
Win2000 domain with Win2000 DHCP server, server machine ip 192.168.16.2 (it's also the gateway to the net).
WinXP for music server (DHCP assigned IP 192.168.16.17)
Java SDK 1.4.1_01. (has anyone gotten this to work with this version of Java?)
Original RIO server software.
RIO and Music server box both plugged in to Netgear 8 port switch (not a hub, a switch).
New server software installed at "c:\program files\trio-0.1.1"
Tweaked trio.xml to replace "f:\code" with "C:\program files"
Changed server ip in trio.xml to 192.168.16.17, didn't change the ports.
Changed broadcast-address to 192.168.16.255
multicast address still 230.0.0.1
replace receiver.arf.

Rio boots with the new .arf, it displays a trio splash screen.

TRIO server starts with the following output
Start of TRioServer
Start of ClockApp thread
Loading TRioPlayerLayout: scrolling
player app - Starting TRioUnit App thread
ImageTranslation: byte-binary
Creating sockets
creating udp socket. local port: 19680, timeout: 15000


ipconfig on the music server shows:
Ethernet adapter Local Area Connection:

Connection-specific DNS Suffix . :
IP Address. . . . . . . . . . . . : 192.168.16.17
Subnet Mask . . . . . . . . . . . : 255.255.255.0
Default Gateway . . . . . . . . . : 192.168.16.2

finally, netstat -r on the music server shows:
Route Table
===========================================================================
Interface List
0x1 ........................... MS TCP Loopback interface
0x2 ...00 08 a1 12 c0 50 ...... CNet PRO200WL PCI Fast Ethernet Adapter - Packet Scheduler Miniport
===========================================================================
===========================================================================
Active Routes:
Network Destination Netmask Gateway Interface Metric
0.0.0.0 0.0.0.0 192.168.16.2 192.168.16.17 20
127.0.0.0 255.0.0.0 127.0.0.1 127.0.0.1 1
192.168.16.0 255.255.255.0 192.168.16.17 192.168.16.17 20
192.168.16.17 255.255.255.255 127.0.0.1 127.0.0.1 20
192.168.16.255 255.255.255.255 192.168.16.17 192.168.16.17 20
224.0.0.0 240.0.0.0 192.168.16.17 192.168.16.17 20
255.255.255.255 255.255.255.255 192.168.16.17 192.168.16.17 1
Default Gateway: 192.168.16.2
===========================================================================
Persistent Routes:
None

Any suggestions?

I've replaced Java runtime with 1.4.0_03, but that didn't do the trick (at least not by itself).

I then shut down my Win2K DHCP (and physically unplugged it from the network to make real sure I wasn't getting an address from it) and turned on the DHCP from the default RIO server. It now works. What I need to know now is how to find out what the difference between the Win2K and the RIO DHCP server is. A way to see what DHCP settings the RIO got would be very useful. Keeping my Win2K DHCP server shut down is not a viable long term solution.

The synchronous playing is awfully cool. A little delicate (the units easily get confused, or locked, or stop making sound although the screen still shows the song playing and the time ticking away, or I've also managed to steal the lead away from the "master" rio to one of the "slaves" several times).

One issue I have is that I usually use a home built music server that I can run as a Win2K service on my domain controller. That way, my music works without anyone needing to be logged in, and autorestarts after a power interruption. Anyone know of a way to run a java application like this as a service on win2k? Failing that, is the interface between the trio client and server documented? As a last resort, I could (yech) reimplement the server as a C++ app that I could fold into my home brew server.

One final note is that this is working also for 2 receivers that are NOT on the same switch as the server, but are daisychained one switch away from the server.

Anyway, great job!

Hi,

Yes, shutting down the local DHCP server seems to solve the "waiting before retry" problem 9 times out of 10. The problem is to do with the code on the Receivers getting a "host unreachable" error (or something similar sounding) and I think it's because your DHCP config is not supplying the correct routing table entries for the receiver. The answer may be to set the "default router" to your server box.

Yes, the syncing is a bit tempramental and needs to be made more robust. I tracked down one bug with it today, but I'm sure there are many others. Hopefully by v0.1.3 it'll be more stable.

I have had tRio running as a Windows Service before (have a look in the /bin directory - but it's very out of date). It uses a product called JavaService (see http://www.alexandriasc.com/software/JavaService/index.html ) which is free.

Let me know how you get on with the DHCP stuff

Cheers
Paul

Well your running Win2k..

Use SRVANY.EXE from the W2k Server Resource kit.. I use it to make my JRec and othe java apps run as services. Just do NOT logon as the account you use to run those services. If you do, then logout.. The services stop..

Now that was the FREE way..

The Small cost, but more reliable and configurable is to use FireDaemon. Its like $25.00 and much much more configurable.

Go http://www.firedaemon.com/ for firedaemon

Paul, I've gotten past "waiting for retry" on my linux machine by messing sound with the dhcpd.conf as you suggested. On linux I now getting the menus to come up correctly but can't play anything. I get "tune mismatch" errors.

Anyway I switched over to using trio/jreceiver on XP and am getting a similar errors. Rio just hangs on "buffering" and I get this message on my PC:

WindowManager (/192.168.1.103): windowDeactivated
WindowManager (/192.168.1.103): windowDeactivated
WindowManager (/192.168.1.103): windowDeactivated
### startPlayback. streamStatus: 0, pbStatus: 0
PlayerStream (/192.168.1.103) - streamStart()
Bad music server http response opening tune connection: 404: Not Found
PlayerStream (/192.168.1.103) - sent Purge(). dataLen: 0
PlayerStream (/192.168.1.103) - discarding DataRequest - tuneSeqNo mismatch. tuneSeqNo: 0, startTuneSeqNo: 2, streamTuneSeqNo: 2
PlayerStream (/192.168.1.103) - discarding DataRequest - tuneSeqNo mismatch. tuneSeqNo: 0, startTuneSeqNo: 2, streamTuneSeqNo: 2
PlayerStream (/192.168.1.103) - discarding DataRequest - tuneSeqNo mismatch. tuneSeqNo: 0, startTuneSeqNo: 2, streamTuneSeqNo: 2
WindowManager (/192.168.1.103): windowDeactivated

Any idea what is going wrong?

Your real problem here is the "Bad music server http response opening tune connection: 404: Not Found". My initial guess is that your menu-server/content-server setting aren't quite right - need to be the same setting for both.

PM me a copy of your trio.xml and I'll have a look.

In the mean time, I'll beef up the error handling in this area to produce something more obvious looking.

Cheers
Paul

OK, I went back to the jreceiver logs and found the problem. I think jreceiver and the Audio Manager both were fighting over port 8080. I moved jreceiver to port 8081, updated trio.xml, and I got it working. Browse by artist then by album is what I've been looking for a long time. Only problem I see now is Album/Artist Name area on the display is just one solid block of pixels.

Now back to getting this working on Linux.
Thanks

The DHCP request the DAR makes does not include a Parameter Request List. Therefore, the DHCP RFC makes clear that the DHCP server is pretty much able to return whatever parameters it feels like. The Win2K DHCP server doesn't choose to return the table of routers. I can't find a way to force the Win2K DHCP server to return unrequested data in the options field of the DHCP message. The recommended fix for this situation is for the client to add a Parameter Request list.

I don't know much about the code in the client; I'm a Win32 coder, I don't know much Linux. However, I believe that the DHCP request is in the boot code in ROM, and so can't be touched. Can anyone suggest a work around to this? Not running the Win2K DHCP server isn't an option; I have to maintain the Win2K domain. Is there a way to get the trio client to make a different kind of broadcast? Perhaps do another DHCP request, this time including the Options Request List? Anyone have any suggestions. I'm willing to do a lot to get this working, but as I said, I'm not a Linux coder.

Oh, by the way, I find the scrolling display to be probably even cooler than the syncronized music. I use a homebrew music server because I have a lot of classical music in my collection and so make a lot of use of the ID3v2 fields "composer" and "conductor". Another effect of having lots of classical music is that my track names tend to be VERY long, like "Concerto for Flute, Harp, and Orchestra 'Pastorale': Movement 2: Andantino", and stuff is constantly too long to read on the DAR.

I *think* the setting that makes it work in my Linux dhcp config is: option routers 192.168.1.1 . The equivalent might be "default router" or "gateway" in NT-speak. But I could well be wrong.

On the scrolling banner side, have you noticed that it looks better if you turn the brightness up on the display. A setting of 54 looks good on mine. BUT BE WARNED: one of my LCDs has started to look a bit faded and I'm not sure if it's because I turned the brightness up too high. SO DO THIS AT YOUR OWN RISK.

Cheers
Paul

I PMd you to continue this. It's getting pretty long here.

>I PMd you to continue this. It's getting pretty long here.

Please keep us updated on the progress as I have the same issues ie. need to keep the 2K DHCP server.