1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Series 1 not downloading data

Discussion in 'TiVo Help Center' started by shototsu, Nov 11, 2008.

  1. technomutt

    technomutt New Member

    103
    0
    Jun 14, 2004
    Haven't logged in here in a while, and found this thread. A friend and I have between us 5 Tivos... 3 of which are Series 1 Sony SVR-2000s. Of these, two are lifetimes. Of these, one is on dialup, the other has a turbonet. All have 120GB hard drives or larger.

    None of our units has ever gone for more than 48 hours without a successful call, and those few error times occurred over the Christmas holiday. One time I thought the guide data might be corrupted on the turbonet unit, so I did a "Clear Program Data & To Do List" which seemed to clear the problem. But I suspect I could have just waited a day and it would have cleared itself.

    Just for fun last evening I re-ran the guided setup on the lifetime Sony with the turbonet card and while it was slow, it completed successfully.

    So I guess this is one of those annoying "mine works fine" posts.

    However, I have 2 questions:

    1. Is the modem in the Series 1 box a V32 (33.6Kbps max) modem, a K56flex or the other non-standard 56Kbps modem (I forget the name), or is it a true V90 standard 56Kbps modem? This is for those who are dropping the connection and have ruled out the quality of the POTS line and have properly filtered their DSL (if applicable) away from the Tivo's phone line. I am reminded of times back in 1999 or so where folks with dialup internet access on their computers couldn't connect or dropped the connection. Their modems would be 56K capable, and they would dial into 56K ready ISP's but the phone line itself could not support those speeds. Those early modems would not downshift properly to 33.6 or slower, so the connection was dropped. The solution was to modify the modem's initialization string for force connections at only V32 or slower.

    I also recall once connecting a dialup computer to a verizon FIOS "simulated POTS" line (not VOIP) and it would connect at 33.6 max. I know... "why would anyone do that if you have FIOS". Well, just because I could.

    2. For those having issues with turbonet, do you use anything other than a standard residential-grade router and your ISP's DNS servers? No Sonic Walls or other firewall? No proxies or other DNS redirects? No Comsifters or other internet "filters"? The environments where all of my turbonet equipped Tivos have been have standard issue routers... nothing fancy. I've experienced FIOS, DSL and even fixed wireless. Never Comcrap. You can't pay me enough to use Comcrap. I don't care how fast it bursts to, I will never use cable internet. Aside from their weird DNS practices and their tendencies to throttle "heavy" users, I feel their service is way overpriced for it's value.

    That's my 2 cents... hopefully there was something useful to someone.
     
  2. tzone

    tzone New Member

    16
    0
    Feb 28, 2002

    Here is the service unavailable pcap that I grabbed this AM.

    Code:
    No.     Time        Source                Destination           Protocol Info
          1 0.000000    192.168.1.125         204.176.49.2          TCP      ardus-mtrns > http [SYN] Seq=0 Win=512 Len=0 MSS=1460
    
    Frame 1 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 0, Len: 0
    
    No.     Time        Source                Destination           Protocol Info
          2 0.013255    204.176.49.2          192.168.1.125         TCP      http > ardus-mtrns [SYN, ACK] Seq=0 Ack=1 Win=0 Len=0
    
    Frame 2 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
    Internet Protocol, Src: 204.176.49.2 (204.176.49.2), Dst: 192.168.1.125 (192.168.1.125)
    Transmission Control Protocol, Src Port: http (80), Dst Port: ardus-mtrns (1117), Seq: 0, Ack: 1, Len: 0
    
    No.     Time        Source                Destination           Protocol Info
          3 0.013625    192.168.1.125         204.176.49.2          TCP      ardus-mtrns > http [ACK] Seq=1 Ack=1 Win=1460 Len=0
    
    Frame 3 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0
    
    No.     Time        Source                Destination           Protocol Info
          4 0.026489    204.176.49.2          192.168.1.125         TCP      [TCP Window Update] http > ardus-mtrns [ACK] Seq=1 Ack=1 Win=4356 Len=0
    
    Frame 4 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
    Internet Protocol, Src: 204.176.49.2 (204.176.49.2), Dst: 192.168.1.125 (192.168.1.125)
    Transmission Control Protocol, Src Port: http (80), Dst Port: ardus-mtrns (1117), Seq: 1, Ack: 1, Len: 0
    
    No.     Time        Source                Destination           Protocol Info
          5 0.026871    192.168.1.125         204.176.49.2          TCP      [TCP segment of a reassembled PDU]
    
    Frame 5 (116 bytes on wire, 116 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 1, Ack: 1, Len: 62
    
    No.     Time        Source                Destination           Protocol Info
          6 0.031136    192.168.1.125         204.176.49.2          TCP      [TCP segment of a reassembled PDU]
    
    Frame 6 (1514 bytes on wire, 1514 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460
    
    No.     Time        Source                Destination           Protocol Info
          7 0.140865    204.176.49.2          192.168.1.125         TCP      http > ardus-mtrns [ACK] Seq=1 Ack=63 Win=4418 Len=0
    
    Frame 7 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
    Internet Protocol, Src: 204.176.49.2 (204.176.49.2), Dst: 192.168.1.125 (192.168.1.125)
    Transmission Control Protocol, Src Port: http (80), Dst Port: ardus-mtrns (1117), Seq: 1, Ack: 63, Len: 0
    
    No.     Time        Source                Destination           Protocol Info
          8 0.142636    192.168.1.125         204.176.49.2          TCP      [TCP segment of a reassembled PDU]
    
    Frame 8 (1514 bytes on wire, 1514 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 1523, Ack: 1, Len: 1460
    
    No.     Time        Source                Destination           Protocol Info
          9 0.143619    192.168.1.125         204.176.49.2          HTTP     POST /tivo-service/mlog.cgi HTTP/1.0 
    
    Frame 9 (1179 bytes on wire, 1179 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 2983, Ack: 1, Len: 1125
    [Reassembled TCP Segments (4107 bytes): #5(62), #6(1460), #11(1460), #12(1460), #13(1460), #14(1460), #15(1460), #18(1460), #19(1460), #20(1460), #21(1460), #28(1460), #30(1460), #8(1460), #9(1125)]
    Hypertext Transfer Protocol
    
    No.     Time        Source                Destination           Protocol Info
         10 0.205644    204.176.49.2          192.168.1.125         TCP      [TCP Dup ACK 7#1] http > ardus-mtrns [ACK] Seq=1 Ack=63 Win=4418 Len=0
    
    Frame 10 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
    Internet Protocol, Src: 204.176.49.2 (204.176.49.2), Dst: 192.168.1.125 (192.168.1.125)
    Transmission Control Protocol, Src Port: http (80), Dst Port: ardus-mtrns (1117), Seq: 1, Ack: 63, Len: 0
    
    No.     Time        Source                Destination           Protocol Info
         11 0.342584    192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]
    
    Frame 11 (1514 bytes on wire, 1514 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460
    
    No.     Time        Source                Destination           Protocol Info
         12 0.742875    192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]
    
    Frame 12 (1514 bytes on wire, 1514 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460
    
    No.     Time        Source                Destination           Protocol Info
         13 1.542766    192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]
    
    Frame 13 (1514 bytes on wire, 1514 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460
    
    No.     Time        Source                Destination           Protocol Info
         14 3.142979    192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]
    
    Frame 14 (1514 bytes on wire, 1514 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460
    
    No.     Time        Source                Destination           Protocol Info
         15 6.343634    192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]
    
    Frame 15 (1514 bytes on wire, 1514 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460
    
    No.     Time        Source                Destination           Protocol Info
         16 10.010958   Buffalo_2e:3c:c0      Pc-Pos_32:02:27       ARP      Who has 192.168.1.125?  Tell 192.168.1.254
    
    Frame 16 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
    Address Resolution Protocol (request)
    
    No.     Time        Source                Destination           Protocol Info
         17 10.011213   Pc-Pos_32:02:27       Buffalo_2e:3c:c0      ARP      192.168.1.125 is at 00:0b:ad:32:02:27
    
    Frame 17 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Address Resolution Protocol (reply)
    
    No.     Time        Source                Destination           Protocol Info
         18 12.744360   192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]
    
    Frame 18 (1514 bytes on wire, 1514 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460
    
    No.     Time        Source                Destination           Protocol Info
         19 25.546190   192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]
    
    Frame 19 (1514 bytes on wire, 1514 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460
    
    No.     Time        Source                Destination           Protocol Info
         20 51.149872   192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]
    
    Frame 20 (1514 bytes on wire, 1514 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460
    
    No.     Time        Source                Destination           Protocol Info
         21 102.357150  192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]
    
    Frame 21 (1514 bytes on wire, 1514 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460
    
    No.     Time        Source                Destination           Protocol Info
         22 144.361886  Pc-Pos_32:02:27       AbitComp_bb:f7:40     ARP      Who has 192.168.1.200?  Tell 192.168.1.125
    
    Frame 22 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: AbitComp_bb:f7:40 (00:50:8d:bb:f7:40)
    Address Resolution Protocol (request)
    
    No.     Time        Source                Destination           Protocol Info
         23 144.361905  AbitComp_bb:f7:40     Pc-Pos_32:02:27       ARP      192.168.1.200 is at 00:50:8d:bb:f7:40
    
    Frame 23 (42 bytes on wire, 42 bytes captured)
    Ethernet II, Src: AbitComp_bb:f7:40 (00:50:8d:bb:f7:40), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
    Address Resolution Protocol (reply)
    
    No.     Time        Source                Destination           Protocol Info
         24 176.868701  192.168.1.125         204.176.49.2          TCP      ardus-mtrns > http [FIN, ACK] Seq=4108 Ack=1 Win=4380 Len=0
    
    Frame 24 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 4108, Ack: 1, Len: 0
    
    No.     Time        Source                Destination           Protocol Info
         25 176.882276  204.176.49.2          192.168.1.125         TCP      [TCP Dup ACK 7#2] http > ardus-mtrns [ACK] Seq=1 Ack=63 Win=4418 Len=0
    
    Frame 25 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
    Internet Protocol, Src: 204.176.49.2 (204.176.49.2), Dst: 192.168.1.125 (192.168.1.125)
    Transmission Control Protocol, Src Port: http (80), Dst Port: ardus-mtrns (1117), Seq: 1, Ack: 63, Len: 0
    
    No.     Time        Source                Destination           Protocol Info
         26 186.882844  Buffalo_2e:3c:c0      Pc-Pos_32:02:27       ARP      Who has 192.168.1.125?  Tell 192.168.1.254
    
    Frame 26 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
    Address Resolution Protocol (request)
    
    No.     Time        Source                Destination           Protocol Info
         27 186.883222  Pc-Pos_32:02:27       Buffalo_2e:3c:c0      ARP      192.168.1.125 is at 00:0b:ad:32:02:27
    
    Frame 27 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Address Resolution Protocol (reply)
    
    No.     Time        Source                Destination           Protocol Info
         28 279.282428  192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]
    
    Frame 28 (1514 bytes on wire, 1514 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460
    
    No.     Time        Source                Destination           Protocol Info
         29 299.997627  204.176.49.2          192.168.1.125         TCP      [TCP Previous segment lost] http > ardus-mtrns [FIN, ACK] Seq=714 Ack=63 Win=4418 Len=0
    
    Frame 29 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
    Internet Protocol, Src: 204.176.49.2 (204.176.49.2), Dst: 192.168.1.125 (192.168.1.125)
    Transmission Control Protocol, Src Port: http (80), Dst Port: ardus-mtrns (1117), Seq: 714, Ack: 63, Len: 0
    
    No.     Time        Source                Destination           Protocol Info
         30 299.999440  192.168.1.125         204.176.49.2          TCP      [TCP Retransmission] [TCP segment of a reassembled PDU]
    
    Frame 30 (1514 bytes on wire, 1514 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 63, Ack: 1, Len: 1460
    
    No.     Time        Source                Destination           Protocol Info
         31 299.999455  192.168.1.125         204.176.49.2          TCP      [TCP Dup ACK 30#1] ardus-mtrns > http [ACK] Seq=4109 Ack=1 Win=4380 Len=0
    
    Frame 31 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 4109, Ack: 1, Len: 0
    
    No.     Time        Source                Destination           Protocol Info
         32 300.001673  204.176.49.2          192.168.1.125         HTTP     [TCP Retransmission] HTTP/1.1 500 Internal Server Error  (text/html)
    
    Frame 32 (767 bytes on wire, 767 bytes captured)
    Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
    Internet Protocol, Src: 204.176.49.2 (204.176.49.2), Dst: 192.168.1.125 (192.168.1.125)
    Transmission Control Protocol, Src Port: http (80), Dst Port: ardus-mtrns (1117), Seq: 1, Ack: 63, Len: 713
    Hypertext Transfer Protocol
    Line-based text data: text/html
    
    No.     Time        Source                Destination           Protocol Info
         33 300.003943  192.168.1.125         204.176.49.2          TCP      ardus-mtrns > http [ACK] Seq=4109 Ack=715 Win=4380 Len=0
    
    Frame 33 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Internet Protocol, Src: 192.168.1.125 (192.168.1.125), Dst: 204.176.49.2 (204.176.49.2)
    Transmission Control Protocol, Src Port: ardus-mtrns (1117), Dst Port: http (80), Seq: 4109, Ack: 715, Len: 0
    
    No.     Time        Source                Destination           Protocol Info
         34 308.268104  204.176.49.2          192.168.1.125         TCP      http > ardus-mtrns [RST, ACK] Seq=715 Ack=63 Win=4418 Len=0
    
    Frame 34 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
    Internet Protocol, Src: 204.176.49.2 (204.176.49.2), Dst: 192.168.1.125 (192.168.1.125)
    Transmission Control Protocol, Src Port: http (80), Dst Port: ardus-mtrns (1117), Seq: 715, Ack: 63, Len: 0
    
    No.     Time        Source                Destination           Protocol Info
         35 309.996818  Buffalo_2e:3c:c0      Pc-Pos_32:02:27       ARP      Who has 192.168.1.125?  Tell 192.168.1.254
    
    Frame 35 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0), Dst: Pc-Pos_32:02:27 (00:0b:ad:32:02:27)
    Address Resolution Protocol (request)
    
    No.     Time        Source                Destination           Protocol Info
         36 309.997054  Pc-Pos_32:02:27       Buffalo_2e:3c:c0      ARP      192.168.1.125 is at 00:0b:ad:32:02:27
    
    Frame 36 (60 bytes on wire, 60 bytes captured)
    Ethernet II, Src: Pc-Pos_32:02:27 (00:0b:ad:32:02:27), Dst: Buffalo_2e:3c:c0 (00:16:01:2e:3c:c0)
    Address Resolution Protocol (reply)
    
    /troy
     
  3. dlee0708

    dlee0708 New Member

    115
    0
    Sep 20, 2002
    Lewisville, TX

    That is pretty much the same as my mothers except for 3 things.

    1. On yours, the Tivo sends out 4 packets (#5, #6, #8 and #9) before it goes back and starts retransmitting the #6 packet (Seq 63) because it never gets a response from the TivoServer for packet #6.

    My mothers only gets out 3 packets before retransmitting the 2nd packet.

    2. On yours the first packet is 62 bytes whereas my mothers is 63. I imagine its because your log file is smaller and therefore the content-length field a 4 digit number whereas my mothers is a 5 digit. I would be curious as to what this packet has in the data. Here is my mothers

    Code:
    0000  00 1e 2a 08 cd 98 00 0b  ad 32 12 1f 08 00 45 00   ..*..... .2....E.
    0010  00 67 09 7c 00 00 40 06  b1 b6 c0 a8 01 04 cc b0   .g.|..@. ........
    0020  31 02 04 85 00 50 6e 0a  21 55 33 d4 24 ea 50 18   1....Pn. !U3.$.P.
    0030  11 1c 57 c5 00 00 50 4f  53 54 20 2f 74 69 76 6f   ..W...PO ST /tivo
    0040  2d 73 65 72 76 69 63 65  2f 6d 6c 6f 67 2e 63 67   -service /mlog.cg
    0050  69 20 48 54 54 50 2f 31  2e 30 0d 0a 43 6f 6e 74   i HTTP/1 .0..Cont
    0060  65 6e 74 2d 4c 65 6e 67  74 68 3a 20 36 34 38 34   ent-Leng th: 6484
    0070  31 0d 0a 0d 0a                                     1....            
    
    My mothers has Content-Length: 64841, I am guessing yours is probably like Content-Length: 4170 therefore making the packet 1 byte less than my moms. Could you post what is in packet #5.

    3. On yours at packet #10 the TivoServer does resend an ack that it sent at #7. On my mom's, the ack is never resent by the server.



    But what I would really like to see is what is TivoInc seeing on their end for these Service Unavailable issues, that is what I would just love to know. Man, would that ever be informative.
     
  4. pianoman

    pianoman :-|

    3,751
    0
    Jun 26, 2002
    Metairie, LA
    Checking back in to the thread because my Series 1 started having failed calls again (Turbonet). Both test calls and forced daily calls would end with a "Failed. Service Unavailable" error.

    I repeated my fix from last time (removing all files in the /var/log directory) and my very next call completed successfully on the first try.

    There is definitely something going on which is related to the amount of data being transferred. When my log files were very small, calls completed with no trouble.

    I unfortunately still do not have access to a hub, so I can't provide a capture as another data point.
     
  5. cgf

    cgf New Member

    24
    0
    Mar 30, 2002
    Boston, MA
    I've been wondering about this myself.

    I haven't been having the problem since the hack that I mentioned but 1) I'd like to not have to use the hack and 2) I keep wondering why people with bash access to their S1's aren't at least trying the hack.
     
  6. bittmann

    bittmann Member

    68
    0
    Apr 19, 2005
    South...
    I have tried the hack.

    It improves my percentage *greatly*, but apparently it doesn't completely do away with the need to contact the Mothership -- in the logs, there appears to be a contact with that server (I can't remember -- is it during/right after the "FourOneOne Request" or some such?) even if there are no logs to send. SO, the chances of it hanging during a log POST are mitigated, but there is still the problem of the communication going poorly.

    So I've removed the hack in order to (hopefully) be able to give TivoJerry usable logs.


    That being sadi: If I hadn't connected for a month or two, and I had telnet access, you're darned right that the first thing I'd do is try to clear logs/block svclog.upload from being created/whatever it TOOK to get my TiVo back on line. :mad:

    BittMann
     
  7. Illusion

    Illusion New Member

    29
    0
    Jun 1, 2008
    The issue has cropped up again on my neighbor's Tivo after a few weeks of 100% successful calls.

    Mine is currently doing well still....currently.
     
  8. bittmann

    bittmann Member

    68
    0
    Apr 19, 2005
    South...
    I know I'm going back in time a little bit on this one, but thought it worth commenting upon as I've switched back & forth between network and dial several times in the interim, and have tried to keep tabs on what is happening:

    From looking at the route data in the TiVo itself, I suppose that switching from PPP dialup to turbonet could potentially cause funkiness with the default route. While it is possible to re-initialize (or manually change) the network configuration, the easiest way by far to recover from this issue would be (IMO, and in my experience) to simply restart the recorder. When switching from TurboNet to PPP dialup, however, it seems to "just work" here...a restart certainly won't hurt in that situation, either. That being said, I haven't had to reboot myself -- every time I've switched turbonet to PPP it's "just worked". Not to say that this would be the case for everyone, though, naturally (if for whatever reason you lose your network default route, that will definitely bork your communication the next time you try to make a daily call over the network).

    And from my experience, a coldstart (pulling the power, letting everything spin down, etc.) is not required...simply doing a restart from the TiVo menu will completely re-load the kernel and re-establish the network configuration. While a coldstart would be useful in a situation where hardware is "hung", it generally isn't (and shouldn't be!) something that is necessary for clearing network issues.

    But like I said: That's MY experience...which may not be what everyone else sees.

    BittMann
     
  9. Illusion

    Illusion New Member

    29
    0
    Jun 1, 2008
    Just so you know, me and my neighbor are kinda acting as a control here. We both have Phillips Series 1 on dial up. We use different dial in numbers. We have changed no settings at all since this issue came up. Sometimes it works, sometimes it does not. We have both experienced long periods of repeated failures, and long periods of repeated successes. Long periods in this case is in the weeks time-frame.
     
  10. joeysmith

    joeysmith New Member

    95
    0
    Jan 9, 2002
    I got my null modem adapter the day after my connecting problem cleared up. I was all set to try the hack but didn't need it. I don't think there are that many turbonet problems anymore. The only one I am aware of is dlee708's mother's TIVO (somebody correct me if I am wrong here). Since my issue cleared up I have not had one single failure. Have not had a chance to test dialup again. I did get a failure the last time I tried.
     
  11. tzone

    tzone New Member

    16
    0
    Feb 28, 2002
    Not true. I for one am still having turbonet issues and have been providing TiVoJerry info/captures on the side. Also keep in mind that my S1 unit has been working reliably with a turbonet card for about 5 years up until recently. Additionally, the two S3 units in my house have had zero issues, so there certainly is something funky happening on the S1 side.

    Maybe TiVoJerry could pop in here and provide a status update. Even if it was something as simple as, "we're still looking into it", it would be better than what we have to date (which is currently nothing).

    /troy
     
  12. joeysmith

    joeysmith New Member

    95
    0
    Jan 9, 2002
    are you totally unable to connect? have you ruled out hw issues? mine turned out to be a partially seated turbonet (also worked reliably for years). the led light on the board turned on as if it was working, and it got the link light on my switch lit as well. i did have dialup issues so i know it wasn't just the turbonet.
     
  13. bittmann

    bittmann Member

    68
    0
    Apr 19, 2005
    South...
    Check many of the previous posts. This isn't a "non-connect" or "broken networking" issue (like you were having) -- this is a "networking works, we talk to TiVo, we exchange quite a few packets -- then TiVo stops talking to us" issue. In several of the previous communications traces, you can see that we continue to TRY to talk to TiVo, and TiVo doesn't respond. Then, when we "give up" and announce our intent to disconnect, the very server that isn't responding to the data that we're sending acknowledges the disconnect. Which I'll be quick to point out couldn't happen if there was a lack of (or a dropped) connection.

    And then there's the other side of the issue -- in many cases, simply re-trying the connection another time, or two-- or three -- will finally yield a successful connection. Local hardware issues don't USUALLY go away by themselves without a reboot/restart/whatever.

    And the 3rd leg of the stool: While we can't (easily) get dumps from ppp, one can view the tclient and tcdebug logs, and one can see the same sort of "behavior" in those logs as one sees on turbonet, so there is that as well.

    So, while it's undoubtedly the situation that some of the issues out there aren't TiVo issues (witness yours as one handy example), there is *definitely* "something" going on that is out of user control. In my opinion, anyhow.

    BittMann
     
  14. tzone

    tzone New Member

    16
    0
    Feb 28, 2002
    The issue is sporadic at best, however I'm fairly confident that it is not a HW issue at this point (I've already swapped turbonet cards with another that I have). I've also reimaged the drive in the unit (TWICE) to see if that helps (it does not). Also, see my previous post where I captured the failure from TiVo's side (HTTP/1.1 500 Internal Server Error). They should have a good data point, as I was able to capture that server error in a Wireshark file and I did send it to TiVoJerry for review (and dlee for that matter). I think we're seeing a legitimate issue on TiVo's side and I'd like to hear for sure whether TiVo has identified the problem or not.

    http://www.tivocommunity.com/tivo-vb/showthread.php?p=7071556#post7071556

    /troy
     
  15. joeysmith

    joeysmith New Member

    95
    0
    Jan 9, 2002
    actually i did have issues, specifically with dialup while my turbonet was out of commission and it was just not working at all. it was just at one point that someone reported that things cleared up that i thought to dial out to the west coast. this somehow got me all the way through guided setup and downloads. it was only after that i figured out my turbonet problem and i got that going as well. since then it has been flawless, but one time i performed some dialup tests to the local numbers i did get another failure. i have the sense that a band-aid solution was put in place that gets people thru eventually. this is why i am questioning whether there are turbonets out there that could not get thru at all.
     
  16. dlee0708

    dlee0708 New Member

    115
    0
    Sep 20, 2002
    Lewisville, TX
    Not sure it makes any difference, but on my mothers Tivo this isn't quite what happens. The Tivo sends the first large packet, then no response from Server, this repeats for like 3 minutes, the Server then sends a Internal Error packet with an ack which indicates the server did not receive the first large packet, then the server sends a FIN packet (end connection) with the wrong ACK as far as the Tivo is concerned, the Tivo then ACKs with the correct Seq number it was expecting from the Server (it doesn't send a FIN back yet because there are outstanding packets that have not been acknowledged by the server) and then the Tivo Server sends a RST packet (blow the connection no matter what) and then the Tivo ACKs the RST packet with a Seq number that matches the Seq/ACK received from the TivoServer.
     
  17. QBiN

    QBiN New Member

    51
    0
    May 23, 2006
    It's been a while since I've posted on this subject, but I have an update that I wanted to share. Since mid-January, I had been succeeding with dialup calls (external modem) only about 1 out of 10 calls. Nonetheless, it was barely enough to keep me from running out of guide data. TurboNet hasn't worked since 12/2/08. I wanted to get telnet working so I could see what was going on, but since I had other/bigger fish to fry in my life I ignored the S1 problem for a while.

    Today, I realized instantcake had already set me up with a working telnet server to my S1 years ago that I never realized.

    Long story short, I telnet'ed in and watched the log as I tried to use the TurboNet... Failed during the testing new call options phase (no new news here). I then tried deleting all files in the /var/logs directory (from some of the advice of others on this thread) and... <drum roll>... IT WORKED!

    Since it was only a test of the call options, I then told it to make the Daily Call and... that worked too! That is literally the first successful TurboNet call since before 12/2/08.

    I'll let you know if it starts dying again. I'll check on it daily. Based on my experience, this HAS to do with the svclog (or the svclog.upload that get's generated during the daily call) as it get's posted to mlog.cgi in some way. I'll try to track how large svclog gets and if it leads to another future failure.

    For now, I'm just astonished that it worked.
     
  18. pianoman

    pianoman :-|

    3,751
    0
    Jun 26, 2002
    Metairie, LA
    This mirrors my experience exactly. Deleting the logs will ensure that the next call completes.
     
  19. dlee0708

    dlee0708 New Member

    115
    0
    Sep 20, 2002
    Lewisville, TX
    OOOOhhhhhh, you guys are killing me. I am SOOOOOOO kicking myself for not setting up telnetd in my moms Tivo when I put in the larger hard-drive or added the TurboNet.
     
  20. ciper

    ciper New Member

    2,010
    0
    Nov 4, 2004
    Isn't it enabled by default when you install the drivers?

    If FTP is running you could use it to delete the logs probably.
     

Share This Page