Hmm... Suddenly my Receivers (running stock software) stopped working with standard RMM. Only change that has happened is that I have applied the latest Windows Update on XP. The failure seems related to not being able to load the image - the first receiver stopped working after being powered down, just showing the address it got from DHCP, while the other continued working until I powered it down, and now it's in the same state. Anyone else encountered this?

Do you mean you installed the newest release candidate of Service Pack 2? Or just some random update?

The service pack turns on XP's firewall, which will almost certainly break the Rio Receiver protocol.

In reply to:

---

Do you mean you installed the newest release candidate of Service Pack 2? Or just some random update?

---

Just a random update.

In reply to:

---

The service pack turns on XP's firewall, which will almost certainly break the Rio Receiver protocol.

---

That was the first thing I checked - the firewall is still turned off in the TCP/IP settings.

OK. In that case, we should check that ARMGR has managed to bind to the correct ports.

If you run 'netstat -a', you should see it listening on the following ports:

12078/tcp (the HTTP daemon)
18678/udp (the state daemon)
21075/udp (the service discovery daemon)
21076/udp (the port mapper daemon)
21077/udp (the mount daemon?)
21078/udp (the nfs daemon?)

On top of that, could you run the attached program, which is a diagnostic tool that just uses the service discovery protocol to find the HTTP and portmapper daemons?

netstat looks OK, with all the ports there, but the program doesn't find an NFS server. Hmm...

Can you use netcat in UDP mode to poke at the 21075 socket, to see if anything's happening at all? Actually, given that it's UDP, it might not work at all.

Oooh, ooh, are you running with admin privileges? I don't think that ARMGR should need them, but you never know.

If you want to poke around some more, I've attached the source code for the udp_test program. It used to compile under g++, but I've not tried for a while, so some Win32-isms might have crept in. It's only 160-odd lines, and you should be able to convert it to Perl or something.

Oh, and do the sockets stop being in use when you stop ARMGR? It's possible that something else has snaffled them -- ARMGR is quite lax about reporting errors when it can't get the sockets.

Er, other things: do you have more than one network adapter in the PC? Can you check the HKEY_LOCAL_MACHINE\SOFTWARE\Diamond Multimedia\Audio Receiver Manager\1.0\Adapters registry key?

You ought to have a subkey for each adapter in your PC. Under this key is a "Bindings" variable. Check that it contains at least "http;nfs".

Also check that the HKEY_LOCAL_MACHINE\SOFTWARE\Diamond Multimedia\Audio Receiver Manager\1.0\NFS key has an IMAGE FILE value in it, and that it points to the correct file. You should probably verify that the file's kosher by using "tar tf".

Next you could check the MD5 sum. On my copy (v1.03), it's:

97e2dd6ff3771cce96afa11f71ba27b1 *receiver.arf

In reply to:

---

Oh, and do the sockets stop being in use when you stop ARMGR?

---

yes, nice and clean. And only one network adapter. Might try reinstalling the ARM.

In reply to:

---

Might try reinstalling the ARM

---

That did it - everything working again. Strange...

Anyway, thanks for the help!!!

Glad you got yours working again. Now, if you two gentlemen, who obviously know a good deal more about the Rios that I do, could take a look at the problem I'm having, I'd really appreciate it.

Thanks

Well, that's tRio, which we know nothing about. You'd need to talk to someone else.

Oh, my apologies. I figured nearly everybody was using tRio. Have you heard from Paul lately? I PM'd him but never heard back.

Sorry if I'm sounding pushy.

Popping up this thread again, because ift happened again - this time after a reboot following a power outage, and this time reinstalling ARM didn't help

OK, update - got it to work by uninstalling .net. Brutal but effective.