OK, I am at my wit's end (might not have been a long journey).
After upgrading the server machine to XP, at first everything worked fine then stopped working. I had the RIO and the server hooked up through a Network Switch and it seemed fine (using ARM 1.03). Then I hooked the switch up to a Router and still everything was fine for a few days. Then RIO stopped working - it just wouldn't boot up all the way, usually after a long time ending up in the usual "server not found" screen.
I took the RIO down to the server, hooked both of them up to a 10MBit hub (nothing else) and still the same. I uninstalled ARM and re-installed it, version 1.04 this time.
What I noticed with both versions is that it will not allow you to set it to Autoconfigure IP - there is a message about UPnP, but I do NOT have UPnP installed. On the unused HPNA card it would theoretically allow me to set autoconfigure.
Here's what seems to happen:
The server is address 169.254.28.108, the RIO comes up as 169.254.181.153:
2 0.488631 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x62580fcd
3 0.493277 169.254.181.153 Broadcast ARP Who has 169.254.181.153? Tell 0.0.0.0
4 2.127506 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x62580fcd
5 2.127532 169.254.181.153 Broadcast ARP Who has 169.254.181.153? Tell 0.0.0.0
6 4.177942 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x62580fcd
7 4.178287 169.254.181.153 Broadcast ARP Who has 169.254.181.153? Tell 0.0.0.0
8 5.007473 169.254.28.108 169.254.63.44 UDP Source port: 18678 Destination port: 18678
9 6.738556 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x62580fcd
10 6.738899 169.254.181.153 Broadcast ARP Who has 169.254.181.153? Tell 0.0.0.0
11 9.939344 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x62580fcd
12 9.939690 169.254.181.153 Broadcast ARP Who has 169.254.181.153? Tell 0.0.0.0
13 10.014718 169.254.28.108 169.254.63.44 UDP Source port: 18678 Destination port: 18678
14 13.946232 169.254.181.153 Broadcast ARP 169.254.181.153 is at 00:90:00:11:54:2d
15 13.952917 169.254.181.153 169.254.255.255 UDP Source port: 21075 Destination port: 21075
16 13.954392 169.254.28.108 Broadcast ARP Who has 169.254.181.153? Tell 169.254.28.108
17 13.960365 169.254.181.153 169.254.28.108 ARP 169.254.181.153 is at 00:90:00:11:54:2d
18 13.960372 169.254.28.108 169.254.181.153 UDP Source port: 21075 Destination port: 21075
19 13.987356 169.254.181.153 Broadcast ARP Who has 169.254.28.108? Tell 169.254.181.153
20 13.987367 169.254.28.108 169.254.181.153 ARP 169.254.28.108 is at 00:04:5a:45:19:27
21 13.987756 169.254.181.153 169.254.28.108 Portmap V2 GETPORT Call (Reply In 22)
22 13.987762 169.254.28.108 169.254.181.153 Portmap V2 GETPORT Reply (Call In 21)
23 13.994105 169.254.181.153 169.254.28.108 Portmap V2 GETPORT Call (Reply In 24)
24 13.994111 169.254.28.108 169.254.181.153 Portmap V2 GETPORT Reply (Call In 23)
25 13.995591 169.254.181.153 169.254.28.108 MOUNT V1 MNT Call (Reply In 26)
26 14.000099 169.254.28.108 169.254.181.153 MOUNT V1 MNT Reply (Call In 25)

so now there is tons of data exchanged between RIO and ARM, until the RIO assumes a new IP address and the whole thing starts anew:
3925 40.058396 169.254.28.108 169.254.181.153 UDP Source port: 18678 Destination port: 18678
3926 40.058787 169.254.181.153 169.254.28.108 ICMP Destination unreachable
3927 44.318888 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x7d36e594
3928 44.323794 169.254.181.153 Broadcast ARP Who has 169.254.199.152? Tell 0.0.0.0
3929 45.065442 169.254.28.108 169.254.181.153 UDP Source port: 18678 Destination port: 18678
3930 45.967777 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x7d36e594
3931 45.967866 169.254.181.153 Broadcast ARP Who has 169.254.199.152? Tell 0.0.0.0
3932 48.028280 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x7d36e594
3933 48.028629 169.254.181.153 Broadcast ARP Who has 169.254.199.152? Tell 0.0.0.0
3934 50.072946 169.254.28.108 169.254.181.153 UDP Source port: 18678 Destination port: 18678
3935 50.600064 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x7d36e594
3936 50.600413 169.254.181.153 Broadcast ARP Who has 169.254.199.152? Tell 0.0.0.0
3937 53.057180 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x437e340e
3938 53.809704 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x7d36e594
3939 53.810049 169.254.181.153 Broadcast ARP Who has 169.254.199.152? Tell 0.0.0.0
3940 55.084998 169.254.28.108 169.254.181.153 UDP Source port: 18678 Destination port: 18678
3941 57.826607 169.254.181.153 Broadcast ARP 169.254.199.152 is at 00:90:00:11:54:2d
3942 57.833302 169.254.199.152 169.254.255.255 UDP Source port: 21075 Destination port: 21075
3943 57.834515 169.254.28.108 Broadcast ARP Who has 169.254.199.152? Tell 169.254.28.108
3944 57.840257 169.254.181.153 169.254.28.108 ARP 169.254.199.152 is at 00:90:00:11:54:2d
3945 57.840385 169.254.28.108 169.254.199.152 UDP Source port: 21075 Destination port: 21075
3946 57.866276 169.254.181.153 Broadcast ARP Who has 169.254.28.108? Tell 169.254.199.152
3947 57.866293 169.254.28.108 169.254.181.153 ARP 169.254.28.108 is at 00:04:5a:45:19:27
3948 57.866661 169.254.199.152 169.254.28.108 Portmap V2 GETPORT Call (Reply In 3949)

On the RIO screen, this looks like
looking for music server...
found music server...
searching for music...
<blank screen for 2 seconds>
looking for music server...
etc.

Any help??? I'll be glkad to email the whole dump in TXT or Ethereal format... I am almost sure it has to do with DHCP settings and the fact that I cant set Autoconfigure anymore, though I have to say, originally when this all started, I still could at that point!

Marc

What I noticed with both versions is that it will not allow you to set it to Autoconfigure IP - there is a message about UPnP

It will not allow you to set it to Autoconfigure IP (i.e. use ARMGR's built-in DHCP server) because you're using an automatically assigned IP address on the PC (one in the 169.254 range). This is what it refers to when it says "UPnP".

The network trace is exactly what I'd expect to see: it's looking for an IP address, but since the DHCP server isn't running, it doesn't get one and opts for a 169.254 address instead.

This happens twice, because of the two-kernel boot mechanism in the Rio Receiver.

Now, by the looks of it, everything except the HTTP communication is working correctly: it managed to boot the second kernel, after all -- which implies that the service location, portmapper, mount and NFS services are working correctly.

What is odd is that the portmapper service doesn't respond to the second request, or did you leave out that part of the network trace?

Do you see any HTTP traffic at all? Do you have XP's firewall turned on?

Basically, the boot process looks like this:

1. Power on.
2. Load the kernel from flash
3. Decide which of the HPNA or Ethernet interfaces to use (based on link at the Ethernet port).
4. Try to acquire an IP address using DHCP. Failing that, use a 169.254 address.
5. Issue a service location request (subnet local broadcast on port 21075). The response tells it where to find the NFS server (strictly speaking, the portmapper).
6. Issue portmap requests to find out where the mount and NFS daemons are.
7. Ask the mount daemon to mount the root filesystem.
8. Download the new kernel from NFS, double-boot into it. At this point, if we acquired a DHCP address, this is passed to the second kernel.
9. In your case, we didn't use DHCP, so the second kernel will (IIRC) try again.
10. We go through the finding portmap/mount/nfs server rigmarole.
11. This time, we grab the player binary and run that.
12. It issues a service location request looking for the HTTP server.
13. ....and so on....

Thanks for the incredibly fast answer, Roger! I'll try to attach the whole trace, its so hard to read in the post anyway. In each line you see, the first number is the number of network package, so I left out a lot.
I don't have the XP firewall running.

OK, I looked at the trace.

The HTTP conversation starts normally, but then the player reboots. This is usually caused by the initial playlist being too large.

Have you added more music recently?

Roger - you're a lifesaver! Everything works now, with the original network config. It turns out Windows somehow goofed up the Recycle Bin folder and there were tons of playlists in there that ARM added.
Now its running with 10500 songs and 750 playlists.
Thanks, man! Let me know if I can ever do something for you.
Marc