[rbienstock]

I thought I had a handle on all the networking ideosyncracies of ReplayTV, and, like everyone else, I have been plagued by issues that require reboots, renaming, etc. But this latest one has stumped me completely:


I have three 5160 RTV units (we'll call them A, B and C for simplicity). When you spin through the names of the networked Replay units on each machine's Replay Guide, all the other machines show up. If you do a 243-Zones and Find Other Units, all units are found by each machine. But here's the glitch: Unit C can display the guide contents of machines A and B and can view shows recorded on units A and B, but units A and B display an empty guide for unit C when one navigates to that machine from either machine. I've tried everything I know, but I still get an empty guide for unit C in both units A and B. FWIW, I can see the guide of unit C in DVArchive. Does anyone have any suggestions as to how I can get the guide to display? This is a big issue because units A and B are in the same room, so I don't really need to stream from them, but unit C is in a different room, and I really do need to be able to stream from C to either A or B or both.

 

[l8er]

Are they all on the same software version? (Menu / Setup / System Information / Unit Info / Software Version)

 

[sfhub]

If it's not the software versions, an esoteric thing you might have done

is enter the IP address in octal notation, ie 192.168.1.026 instead of

192.168.1.26. This will also potentially cause the behavior you are

seeing because there is a bug in replay where the local unit treats .026

as octal, but remote units drop the leading zero and treat it as decimal.

 

[rbienstock]

Quote:

Originally posted by sfhub If it's not the software versions, an esoteric thing you might have done is enter the IP address in octal notation, ie 192.168.1.026 instead of 192.168.1.26. This will also potentially cause the behavior you are seeing because there is a bug in replay where the local unit treats .026 as octal, but remote units drop the leading zero and treat it as decimal.

All units are on the same software version. The IPs of the units are 192.168.1.120, 121 and 122. All units get their IPs via DHCP, but my router always assigns the same IP to the unit's MAC address.

 

[plyons10]

With MAC address assignments you should be avoiding the DHCP bug, but, nonetheless, if you think you've tried everything else, then I would suggest going with static IP addressess on all your units and turning any DHCP servers OFF on your network.


It is possible that somewhere somehow someone is pulling an IP from the DHCP server for machine C (though not likely... at least it's something to try).

 

[MethodMachine]

I used to have similar issued back when I was using DHCP (of course, my router does not do MAC address binding). Anyway, since changing to static IPs, by Replay network has been much more stable.


Occassionally, it seems that one of the units will partially hang with respect to its remote scheduling and guide serving functions and will require a reboot.

 

[sfhub]

So what happens with these URLs

http://192.168.1.120/Device_Descr.xml
http://192.168.1.121/Device_Descr.xml
http://192.168.1.122/Device_Descr.xml

 

[Lark888]

sfhub - That was fun. Of course, I substitued my Replay static IPs.

 

[rbienstock]

OK, the first thing that I have to report is that, as if by magic, everything seems to be working fine today, after not working for over a week. Nothing changed in my system to cause it to fail, and nothing changed to cause it to come back. Weird.


A few more comments: (1) sfhub -- I was able to pull up the three xml pages even when the units had trouble with each other. (2) Pylons10 and Method Machine -- I have been using static IPs for years (you need 'em for IVS), and I agree that it is, in many ways, the correct way to go. It does create problems of its own, however: RTV has theis weird setup where it pulls an IP twice from the DHCP server, once at the beginning of the boot, and again when the Replay software loads. If you have a static IP and DHCP turned on on your network, you can get really bad results because, on occasion, the two IPs don't match. If you turn DHCP off, then, obviously, you can't use it, and, therefore if you add devices to your network that can't be configured for a static IP, you can't use them. Also, because the hardware is looking to pull a dynamic IP on bootup, if you have DHCP turned off, it takes a while for it to time out before the unit boots to the Replay software and uses the static IP. If you use DHCP, this is eliminated and the units boot much faster. That's why I had previously changed my router to one that could do MAC addressing. Now I can keep DHCP turned on and still be sure that my Replay units always have the same IP for IVS purposes. After the switch, my units boot up time went from around 10 minutes to about 3.

 

[plyons10]

Point taken about boot cycles, but why are you ever rebooting your Replays? I never do and they are very very stable.


As far as devices that can't be configured for static IP... I've never seen one. Anything in particular that you've encountered this with?

 

[sfhub]

Quote:

Originally posted by rbienstock A few more comments: (1) sfhub -- I was able to pull up the three xml pages even when the units had trouble with each other.

If that's the case, then IP address change is not the problem, nor is

web server dying. To diagnose further, I think we'd need the packet

dumps from when you access the remote guide and nothing shows up.

 

[rbienstock]

Peter,


The units do maintenance reboots weekly, and they spontaneously reboot on occasion too. I periodically get reboots in the middle of a recording (obviously a crash, not a maintenance reboot) and it was an attempt to shorten the gap in the show that I changed my router.

 

[plyons10]

Of course, my maintenance reboots are all in the middle of the night... so I don't care how long they take to come back up.


The spontaneous reboots aren't a great sign -- I'd be tempted to reimage if I got them that often.