Pulling hair out-Tivo no longer availble on network

[philhu]

I have 2 TivoHD units, plugged into my network. Both work fine to get guide data, etc.

Sometimes, when I try to look at shows from unit 1 on 2 or 2 on 1, it pauses about 4 seconds and gives me a message saying the 'connection could not be established'. I try again, I get it and transfer my show.

My network is fast enough to xfer HD content ahead of watching. I have HP ProCurve 1G switches. I've even run long wires to put both devices on the same switch. Still happens. I've changed switches, no change. I talk to a NAS device at 60mB/s to my PC without errors.

Now, I also have Tivo Desktop. When transferring shows, sometimes, halfway through-less or more, I get an error that the 'transfer has stopped'.

I added TivoPC, Tivo on the pc, and it sometimes gets the same 'connection could not be established' message, and when I transfer to TivoPC, SD shows always transfer fine, if that message doesn't come up, but HD shows stop between 9-25 minutes. It the older TivoPC, it left them around truncated. In the newer version, it deletes the error files.

Anyone else see this problem, or some way I can check my network to see if something is wrong?

Tivos are NOT HACKED at all (Well PROMs updated, but this happenned before the PROMs changed)

About my setup:
=============
The Tivos are static at 192.168.1.10 and 11 respectively.

The Pc is 192.168.1.180 static.

Router is 192.168.1.1 and it does give out DHCP in the 192.168.1.100-.125 range

But it sure does seem like a routing problem. I think I've ruled out the switches by changing them out and actually connecting the tivo and tivoPc to the same switch.

I am a network engineer, and it is really bothering me because I do not even know where to begin.

I guess I can try putting the Tivo and tivo pc on their own switch, no other traffic to see if it is a traffic 'spurt' issue, but on an HP procurve gig switch, it seems unlikely

[kadiir]

I don't know if this will help....

It sounds like the same symptoms from the bridge loop problem I had. My Tivos are on the "other side" of separate wireless bridges - I didn't realize when I set it up that not using WDS created loops through all bridges (I have 3 bridged APs). I was seeing 2-3 duplicates for every packet between the TIvos (but not to/from my PC which hangs off the main AP).

I saw this easily when pinging between tivos, but you'll probably need to stick a hub in front of each Tivo (one at a time or both simulateneously if you have the equipment) so you can see what they see on the wire.

Oh, something else to check is utilization on the Tivos. I had similar behavior when I had a few shows with invalid expiration dates - it caused a process (sorry, can't remember which one) to 'go crazy' so to speak (had to run fix_expdate.tcl to fix them).

[philhu]

I don't know if this will help....

It sounds like the same symptoms from the bridge loop problem I had. My Tivos are on the "other side" of separate wireless bridges - I didn't realize when I set it up that not using WDS created loops through all bridges (I have 3 bridged APs). I was seeing 2-3 duplicates for every packet between the TIvos (but not to/from my PC which hangs off the main AP).

I saw this easily when pinging between tivos, but you'll probably need to stick a hub in front of each Tivo (one at a time or both simulateneously if you have the equipment) so you can see what they see on the wire.

Oh, something else to check is utilization on the Tivos. I had similar behavior when I had a few shows with invalid expiration dates - it caused a process (sorry, can't remember which one) to 'go crazy' so to speak (had to run fix_expdate.tcl to fix them).

Well, these are wired tivos. Nothing is wireless in the mix and I've actually connected the Tivos and pc to the same switch, it still happens.

About exp date, etc. These are unhacked Tivos, so nothing hokey inside to mess up...

[kadiir]

I was highlighting problems I've had with the same symptoms.

Regardless, I still think you need to look at the network packets to make sure nothing odd is going on in the network.

[lrhorer]

The Tivos are static at 192.168.1.10 and 11 respectively.

The Pc is 192.168.1.180 static.

Router is 192.168.1.1 and it does give out DHCP in the 192.168.1.100-.125 range

But it sure does seem like a routing problem.
It doesn't sound like one, to me. If it were a routing problem, I wouldn't expect the units ever to talk, plus, the packets aren't routed, so how can it be a routing problem?

First of all, I presume the netmasks are all FF.FF.FF.00, yes?

The first thing I would try is to set up continuous pings to both TiVos before transferring a program. If one or both of the pings fail when the transfer fails, then you have a starting point for troubleshooting the network. If not, then layers 1, 2, and 3 would seem to be working, and the problem would seem to be at layer 4 or above, which would tend to point to an application issue.

At that point, Wireshark is probably going to be required, although one easy thing to try is to delete TiVo Desktop entirely from your PC. If you have one available, you might shut down your PC and use a different one. I would use Galleon, instead of TDT. You might consider doing so permanently, but certainly for the testing I would eliminate it.

Another thing to try is unplug all the devices except the PC, the switch, and one TiVo. See if the problem occurs. If not, add one device at a time, leaving the firewall router until the very last, and try to re-create the issue. When you start getting the problem again, you've found the likely culprit.

Also, you never mention your OS or the partition type. What OS and what partition type? Double-check all the devices on the network to make sure you don't have a duplicate IP. Wireshark will tell you if you have a rogue ARP situation. Check your ARP table immediately before and after a transfer failure. (You might want to write a small script which constantly dumps the ARP table for the test device during a transfer. If the MAC address changes, you have your answer.)

[philhu]

Ok problem changed a bit. I changed out my main switch, an HP 1800 for a HP 2800 (from ebay). The 2 tivos talk very well together now, I get 1.5x HD transfer speeds while watching a transferring show. I used to barely get 0.8x and saw alot of pause messages. I can transfer an SD show hour in 18 minutes, Tivos say transfer is at 29.03mbps now in net stats.

First of all, I presume the netmasks are all FF.FF.FF.00, yes?

Yes all are correct.


The first thing I would try is to set up continuous pings to both TiVos before transferring a program. If one or both of the pings fail when the transfer fails, then you have a starting point for troubleshooting the network. If not, then layers 1, 2, and 3 would seem to be working, and the problem would seem to be at layer 4 or above, which would tend to point to an application issue.

The tivo to tivo problem has gone away. I did do continuous pings to a tivo during xfer to my pc using tivo desktop plus. Pings kept going, show xfer aborted like usual.



At that point, Wireshark is probably going to be required, although one easy thing to try is to delete TiVo Desktop entirely from your PC. If you have one available, you might shut down your PC and use a different one. I would use Galleon, instead of TDT. You might consider doing so permanently, but certainly for the testing I would eliminate it.

Another thing to try is unplug all the devices except the PC, the switch, and one TiVo. See if the problem occurs. If not, add one device at a time, leaving the firewall router until the very last, and try to re-create the issue. When you start getting the problem again, you've found the likely culprit.

I tried this, same problem. PC and tivo on a 1800 switch alone. Same problem. I have also tried TivoPC/LiquidPC from Nero. Same problem occurs.



Also, you never mention your OS or the partition type. What OS and what partition type? Double-check all the devices on the network to make sure you don't have a duplicate IP. Wireshark will tell you if you have a rogue ARP situation. Check your ARP table immediately before and after a transfer failure. (You might want to write a small script which constantly dumps the ARP table for the test device during a transfer. If the MAC address changes, you have your answer.)
I have cleared the arp table before a transfer, no change.

I am leaning towards the nic card in the pc. It is on the motherboard and I caught it switching to 100mbps and back to 1gig a few times, and initializing it after a reboot sometimes takes 1-2 minutes, so I think the card is faulty. I plan to add a pci 1g intel 1g/pro card this week.

I have Vista 32-bit, ntfs partitions. FYI

[lrhorer]

Yes, having two simultaneous problems can drive one nuts, as the symptoms engendered by one may be mutually incompatible with inferences drawn to the other. If you have alleviated the TiVo - TiVo issue, then indeed the PC stands out as the likely culprit. A flaky NIC card would do it, but how pings could proceed during a layer 1 failure is puzzling. If you have another NIC to hand, then replacing it is easy, so it's not a bad idea to try. If not, or if the problem persists, I would try using another PC.

[kadiir]

Auto-negotiation problems aren't always due to faulty hardware. Some devices just don't play well together.

You could try hard-coding your NIC to gig to avoid the auto-negotiation flaps (assuming the NIC driver will let you) but if you have another NIC that would be a sure way to eliminate the NIC as the source of the problem.

It can also be caused by cable problems (loose connectors, shorts in the cable, etc.).

[gourpcup]

I didn't meet this problem. But I think that you can change the route setting. Perhpas it can help you. hair accessories (http://www.hairaccessoriesusa.com/)