Series 1 not downloading data

I guess we could determine it this way:

For anyone with telnet access into their TiVo ... if, while the status is "connecting" for an extended period of time, they are able to execute the ntpdate command I listed earlier and it actually succeeds, then the network is up and it isn't their fault.

If they can't ntpdate, it's not TiVo's fault.

Maybe.

/bin/ntpdate -d 204.176.49.10 204.176.49.11 204.176.49.12

BittMann

 

I got it to work with the Burbank, CA number 1-818-450-1795. I'll dial the local 845 area code numbers today to see if any work. Haven't checked them yet.

 

I finally got with my mom and had her hook up my ethernet hub and got a trace of Service Unavailable failure. I have PM TivoJerry about it.

It sends a POST of the log file and fails to get the 2nd packet to the Tivo Server.

1. The first packet has the content-length field with the first packet being 63 bytes (the not sending the content-length field problem of several years ago must have been fixed).

2. Then the Tivo sends the next 1460 bytes

3. A response from the server is received for the first 63 bytes (ack 64)

4. The Tivo doesn't see the ack for the next 1460 bytes, so it resends the 1460 bytes again

5. Still no response and this happens for about 5 minutes (resends it 10 times with no response from the Server).

6. The Server sends a Internel Server Error back to the Tivo and the Ack it sends with it indicates it never has received any bytes after byte 63 (Ack 64).

I am positive everyone is going to jump on its a Tivo Server problem because it says a Server Internel Error, but the fact that the HTTP error coming back from the server has an Ack of 64 indicates the TCP/IP stack on the operating system did not receive the 2nd packet (the 1460 bytes). If its a problem at the Server, its not an application/process that TivoInc has that is the problem, but a problem in the Operating System Tcp/ip stack on the Tivo Server (which I assume is Linux). I find this highly unlikely. One thing I do notice is that the HTTP POST sent to the Tivo Server is HTTP/1.0. All the browsers now use HTTP/1.1. I don't know enough about the protocol differences to know what all the differences are, but I would think that would be something to look at and I would bet if the Tivo would start using HTTP/1.1 the problem would go away.

Here is the dump:


No. Time Source Destination Protocol Info
25 2009-02-06 20:18:45.718430 192.168.1.4 204.176.49.2 TCP 1157 > http [SYN] Seq=0 Ack=0 Win=512 Len=0 MSS=1460

Frame 25 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 0, Ack: 0, Len: 0

No. Time Source Destination Protocol Info
26 2009-02-06 20:18:45.801446 204.176.49.2 192.168.1.4 TCP [TCP ZeroWindow] http > 1157 [SYN, ACK] Seq=0 Ack=1 Win=0 Len=0

Frame 26 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:1e:2a:08:cd:98, Dst: 00:0b:ad:32:12:1f
Internet Protocol, Src Addr: 204.176.49.2 (204.176.49.2), Dst Addr: 192.168.1.4 (192.168.1.4)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1157 (1157), Seq: 0, Ack: 1, Len: 0

No. Time Source Destination Protocol Info
27 2009-02-06 20:18:45.801866 192.168.1.4 204.176.49.2 TCP 1157 > http [ACK] Seq=1 Ack=1 Win=1460 Len=0

Frame 27 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 1, Ack: 1, Len: 0

No. Time Source Destination Protocol Info
28 2009-02-06 20:18:45.883590 204.176.49.2 192.168.1.4 TCP [TCP Window Update] http > 1157 [ACK] Seq=1 Ack=1 Win=4236 Len=0

Frame 28 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:1e:2a:08:cd:98, Dst: 00:0b:ad:32:12:1f
Internet Protocol, Src Addr: 204.176.49.2 (204.176.49.2), Dst Addr: 192.168.1.4 (192.168.1.4)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1157 (1157), Seq: 1, Ack: 1, Len: 0

No. Time Source Destination Protocol Info
29 2009-02-06 20:18:45.941223 192.168.1.4 204.176.49.2 HTTP POST /tivo-service/mlog.cgi HTTP/1.0

Frame 29 (117 bytes on wire, 117 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 1, Ack: 1, Len: 63
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
30 2009-02-06 20:18:45.997559 192.168.1.4 204.176.49.2 HTTP Continuation

Frame 30 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
31 2009-02-06 20:18:46.124868 204.176.49.2 192.168.1.4 TCP http > 1157 [ACK] Seq=1 Ack=64 Win=4299 Len=0

Frame 31 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:1e:2a:08:cd:98, Dst: 00:0b:ad:32:12:1f
Internet Protocol, Src Addr: 204.176.49.2 (204.176.49.2), Dst Addr: 192.168.1.4 (192.168.1.4)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1157 (1157), Seq: 1, Ack: 64, Len: 0

No. Time Source Destination Protocol Info
32 2009-02-06 20:18:46.127006 192.168.1.4 204.176.49.2 HTTP Continuation

Frame 32 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 1524, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
33 2009-02-06 20:18:46.579883 192.168.1.4 204.176.49.2 HTTP Continuation

Frame 33 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
34 2009-02-06 20:18:47.499395 192.168.1.4 204.176.49.2 HTTP Continuation

Frame 34 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
35 2009-02-06 20:18:49.339722 192.168.1.4 204.176.49.2 HTTP Continuation

Frame 35 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
36 2009-02-06 20:18:51.544298 192.168.1.1 192.168.1.4 UDP Source port: 4457 Destination port: 40116

Frame 36 (174 bytes on wire, 174 bytes captured)
Ethernet II, Src: 00:1e:2a:08:cd:98, Dst: 00:0b:ad:32:12:1f
Internet Protocol, Src Addr: 192.168.1.1 (192.168.1.1), Dst Addr: 192.168.1.4 (192.168.1.4)
User Datagram Protocol, Src Port: 4457 (4457), Dst Port: 40116 (40116)
Data (132 bytes)

0000 54 4d 44 50 01 00 00 11 00 78 00 00 00 02 00 74 TMDP.....x.....t
0010 54 4d 53 53 5f 54 45 53 54 5f 4e 4f 44 45 00 00 TMSS_TEST_NODE..
0020 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0030 30 30 31 45 32 41 30 38 43 44 39 38 38 38 45 45 001E2A08CD9888EE
0040 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0050 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0060 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................
0070 ff ff ff ff 00 00 00 00 00 00 00 01 ff ff ff ff ................
0080 ff ff ff ff ....

No. Time Source Destination Protocol Info
37 2009-02-06 20:18:51.544721 192.168.1.4 192.168.1.1 ICMP Destination unreachable

Frame 37 (202 bytes on wire, 202 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 192.168.1.1 (192.168.1.1)
Internet Control Message Protocol

No. Time Source Destination Protocol Info
38 2009-02-06 20:18:53.019933 192.168.1.4 204.176.49.2 HTTP Continuation

Frame 38 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
39 2009-02-06 20:19:00.380300 192.168.1.4 204.176.49.2 HTTP Continuation

Frame 39 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
40 2009-02-06 20:19:15.101513 192.168.1.4 204.176.49.2 HTTP Continuation

Frame 40 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
41 2009-02-06 20:19:44.543057 192.168.1.4 204.176.49.2 HTTP Continuation

Frame 41 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
42 2009-02-06 20:20:43.427037 192.168.1.4 204.176.49.2 HTTP Continuation

Frame 42 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
43 2009-02-06 20:22:41.194548 192.168.1.4 204.176.49.2 HTTP Continuation

Frame 43 (1514 bytes on wire, 1514 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 64, Ack: 1, Len: 1460
Hypertext Transfer Protocol

No. Time Source Destination Protocol Info
44 2009-02-06 20:23:45.952129 204.176.49.2 192.168.1.4 HTTP HTTP/1.1 500 Internal Server Error (text/html)

Frame 44 (767 bytes on wire, 767 bytes captured)
Ethernet II, Src: 00:1e:2a:08:cd:98, Dst: 00:0b:ad:32:12:1f
Internet Protocol, Src Addr: 204.176.49.2 (204.176.49.2), Dst Addr: 192.168.1.4 (192.168.1.4)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1157 (1157), Seq: 1, Ack: 64, Len: 713
Hypertext Transfer Protocol
Line-based text data: text/html

No. Time Source Destination Protocol Info
45 2009-02-06 20:23:45.952548 204.176.49.2 192.168.1.4 TCP http > 1157 [FIN, ACK] Seq=714 Ack=64 Win=4299 Len=0

Frame 45 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:1e:2a:08:cd:98, Dst: 00:0b:ad:32:12:1f
Internet Protocol, Src Addr: 204.176.49.2 (204.176.49.2), Dst Addr: 192.168.1.4 (192.168.1.4)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1157 (1157), Seq: 714, Ack: 64, Len: 0

No. Time Source Destination Protocol Info
46 2009-02-06 20:23:45.952978 192.168.1.4 204.176.49.2 TCP 1157 > http [ACK] Seq=2984 Ack=715 Win=4380 Len=0

Frame 46 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:0b:ad:32:12:1f, Dst: 00:1e:2a:08:cd:98
Internet Protocol, Src Addr: 192.168.1.4 (192.168.1.4), Dst Addr: 204.176.49.2 (204.176.49.2)
Transmission Control Protocol, Src Port: 1157 (1157), Dst Port: http (80), Seq: 2984, Ack: 715, Len: 0

No. Time Source Destination Protocol Info
47 2009-02-06 20:23:51.303601 204.176.49.2 192.168.1.4 TCP http > 1157 [RST, ACK] Seq=715 Ack=64 Win=4299 Len=0

Frame 47 (60 bytes on wire, 60 bytes captured)
Ethernet II, Src: 00:1e:2a:08:cd:98, Dst: 00:0b:ad:32:12:1f
Internet Protocol, Src Addr: 204.176.49.2 (204.176.49.2), Dst Addr: 192.168.1.4 (192.168.1.4)
Transmission Control Protocol, Src Port: http (80), Dst Port: 1157 (1157), Seq: 715, Ack: 64, Len: 0

 

I can see a situation in which an misconfigured netfilter (say, something designed to mitigate a distributed denial-of-service attack by dropping large packets if a traffic threshold has been reached) could make the server behave exactly like we're seeing now. Not that I'm suggesting that this IS what is happening, but if you filter or otherwise prevent end-to-end connections for large packets for "whatever reason", the resulting behavior would look pretty similar to what we're seeing right now.

BittMann

 

I just started thinking I wonder if the problem is the first thing out of the Tivo is a http POST. That has got to be pretty unusual and I wonder if there is some transparent proxy/netfilter etc that is causing it to hiccup and not send it on to Tivo. Although it appears that TivoServer is getting the 1st 63 bytes and acks it, so most likely that isn't the problem. Also for grins I had my moms Computer do a HTTP get to the TivoServer before she tried the Daily call (so whatever was between my moms router and the TivoServer would see a GET request before the POST) and that didn't help.

I am really kicking myself for not getting telnet access into my moms Tivo when I installed the TurboNet card so I could delete that dang log file, but I just didn't have time to do that at the time.

Still havent heard from TivoJerry yet (but it hasn't been very long and I don't expect him to be monitoring this every second).

 

Could be. I run a small development shop, and one of our favorite sayings is "it's a bear when something almost works." (Well, we don't use *quite* those words...)

Nothing is quite so darned hard to troubleshoot than something that works some of the time. And it SEEMS that this is one of those situations.

BittMann

 

Actually, this one seems to be

1. For some it works all the time. My brother has Series 1/Lifetime/Turbonet has never had an issue.

2. For some it never works. My mothers is identical to by brothers (Series 1/Lifetime/Turbonet) except hers has a 80Gig drive. Hers has not got past the connecting stage since Dec 2,2008.

3. Others works if they clear out the log file.

4. Others works if they try it multiple times over and over.

 

I converted my Sony Ser1 to dialing in at 1:15 AM and 4:30 AM (Mtn time as mentioned in my thread 11 post) and have had 5 nights of error free service.

Cheers,

DON

 

One thing everyone should try if they haven't already is to do a cold reboot every time you try and switch between connecting by modem and connecting by network. Just changing settings does not work immediately. You have to unplug it, let it spin down completely, then plug it back in.

Switching from network to modem you have to do this. Changing from modem to network you have to do it. The network connect works best. A turbonet card or cachecard is cheap on ebay since lots of people are finished with the series 1 hardware.

 

Who said network connect works best? I believe there's posts in this thread implying it's inconclusive. Also, what ebay are you looking at? I've been checking ebay for two months for cheap turbonet cards and there has only been two available, the cheapest being $46 (not really what I would call cheap, especially since I need 3 of them).

 

just a bit of an update:

I checked my TiVo today, and after seeing that my daily call had failed, just to try something different, this time I cleared my log files

(cat /dev/null > {log.file.name})

and kicked off a manual call.

I still had to do a total of 5 calls (IIRC) before I completed. The first call went to Downloading and hung ("interrupted"), the next 3 calls hung at Connecting ("unavailable"), and the last call went to Downloading and finished.

In each case, the process got hung up while talking to mlog.cgi.

So -- for me, it looks like clearing log files isn't any better than leaving them populated....I'm still running more or less about 1 successful call every 5-7 attempts.

BittMann

 

Aha! And I was able to capture a tcpdump of a 500 error from the remote server during a test call. I'd seen this earlier, but this time I have proof. I did update TivoJerry with that info, in case it's of interest.

From the dump:

Code:

18:38:11.486339 IP 204.176.49.2.80 > 10.10.10.160.1103: P 1:714(713) ack 63 win
 4418
        0x0000:  4500 02f1 8b3a 4000 f106 e96f ccb0 3102  E....:@....o..1.
        0x0010:  0a0a 0aa0 0050 044f 351a 4440 122c be60  .....P.O5.D@.,.`
        0x0020:  5018 1142 fdc3 0000 4854 5450 2f31 2e31  P..B....HTTP/1.1
        0x0030:  2035 3030 2049 6e74 6572 6e61 6c20 5365  .500.Internal.Se
        0x0040:  7276 6572 2045 7272 6f72 0d0a 4461 7465  rver.Error..Date
        0x0050:  3a20 5475 652c 2031 3020 4665 6220 3230  :.Tue,.10.Feb.20
        0x0060:  3039 2030 303a 3333 3a31 3120 474d 540d  09.00:33:11.GMT.
        0x0070:  0a53 6572 7665 723a 2041 7061 6368 650d  .Server:.Apache.
        0x0080:  0a43 6f6e 7465 6e74 2d4c 656e 6774 683a  .Content-Length:
        0x0090:  2035 3337 0d0a 436f 6e6e 6563 7469 6f6e  .537..Connection
        0x00a0:  3a20 636c 6f73 650d 0a43 6f6e 7465 6e74  :.close..Content
        0x00b0:  2d54 7970 653a 2074 6578 742f 6874 6d6c  -Type:.text/html
        0x00c0:  3b20 6368 6172 7365 743d 6973 6f2d 3838  ;.charset=iso-88
        0x00d0:  3539 2d31 0d0a 0d0a 3c21 444f 4354 5950  59-1....<!DOCTYP
        0x00e0:  4520 4854 4d4c 2050 5542 4c49 4320 222d  E.HTML.PUBLIC."-
        0x00f0:  2f2f 4945 5446 2f2f 4454 4420 4854 4d4c  //IETF//DTD.HTML
        0x0100:  2032 2e30 2f2f 454e 223e 0a3c 6874 6d6c  .2.0//EN">.<html
        0x0110:  3e3c 6865 6164 3e0a 3c74 6974 6c65 3e35  ><head>.<title>5
        0x0120:  3030 2049 6e74 6572 6e61 6c20 5365 7276  00.Internal.Serv
        0x0130:  6572 2045 7272 6f72 3c2f 7469 746c 653e  er.Error</title>
        0x0140:  0a3c 2f68 6561 643e 3c62 6f64 793e 0a3c  .</head><body>.<
        0x0150:  6831 3e49 6e74 6572 6e61 6c20 5365 7276  h1>Internal.Serv
        0x0160:  6572 2045 7272 6f72 3c2f 6831 3e0a 3c70  er.Error</h1>.<p
        0x0170:  3e54 6865 2073 6572 7665 7220 656e 636f  >The.server.enco
        0x0180:  756e 7465 7265 6420 616e 2069 6e74 6572  untered.an.inter
        0x0190:  6e61 6c20 6572 726f 7220 6f72 0a6d 6973  nal.error.or.mis
        0x01a0:  636f 6e66 6967 7572 6174 696f 6e20 616e  configuration.an
        0x01b0:  6420 7761 7320 756e 6162 6c65 2074 6f20  d.was.unable.to.
        0x01c0:  636f 6d70 6c65 7465 0a79 6f75 7220 7265  complete.your.re
        0x01d0:  7175 6573 742e 3c2f 703e 0a3c 703e 506c  quest.</p>.<p>Pl
        0x01e0:  6561 7365 2063 6f6e 7461 6374 2074 6865  ease.contact.the
        0x01f0:  2073 6572 7665 7220 6164 6d69 6e69 7374  .server.administ
        0x0200:  7261 746f 722c 0a20 7370 2d61 646d 696e  rator,..sp-admin
        0x0210:  4074 6976 6f2e 636f 6d20 616e 6420 696e  @tivo.com.and.in
        0x0220:  666f 726d 2074 6865 6d20 6f66 2074 6865  form.them.of.the
        0x0230:  2074 696d 6520 7468 6520 6572 726f 7220  .time.the.error.
        0x0240:  6f63 6375 7272 6564 2c0a 616e 6420 616e  occurred,.and.an
        0x0250:  7974 6869 6e67 2079 6f75 206d 6967 6874  ything.you.might
        0x0260:  2068 6176 6520 646f 6e65 2074 6861 7420  .have.done.that.
        0x0270:  6d61 7920 6861 7665 0a63 6175 7365 6420  may.have.caused.
        0x0280:  7468 6520 6572 726f 722e 3c2f 703e 0a3c  the.error.</p>.<
        0x0290:  703e 4d6f 7265 2069 6e66 6f72 6d61 7469  p>More.informati
        0x02a0:  6f6e 2061 626f 7574 2074 6869 7320 6572  on.about.this.er
        0x02b0:  726f 7220 6d61 7920 6265 2061 7661 696c  ror.may.be.avail
        0x02c0:  6162 6c65 0a69 6e20 7468 6520 7365 7276  able.in.the.serv
        0x02d0:  6572 2065 7272 6f72 206c 6f67 2e3c 2f70  er.error.log.</p
        0x02e0:  3e0a 3c2f 626f 6479 3e3c 2f68 746d 6c3e  >.</body></html>
        0x02f0:  0a                                       .

THAT I'm pretty sure TiVo should be able to see in their server logs. Apache, by default, doesn't throw a server error without trying to log that fact in the error log. So, unless logging is completely turned off on the servers (unlikely), then a server error that corresponds to the timestamp in that message should be there waiting to be verified from their end. I think.

BittMann

 

Bittmann,

It may be that clearing the logs is no better than other methods, or it could be that what works for some people doesn't work for other people. Also it might be the only way to get out of Guided Setup.

I remember reading that the log clearing fix does not stick.. because I guess the size gets too big again or whatever the issue is with them comes back.

I was not able to get out of Guided Setup until I renamed the log directory. I made so many tries over so many days before that I have no idea how many times I called and it failed. I tried all the ideas such as putting the 1 and area code + number in the dialing prefix. (Maybe I did not try each idea for long enough because I did stuff like go down the list of numbers and only trying them 1 time each.) The only thing that worked was renaming the log directory. After I renamed the logs, I think I did 2 calls that failed, and then the third call finished almost immediately.

After that, yes I still somtimes have trouble connecting but it goes through after a few tries. I have not deleted the logs since the time I did it to get out of Guided Setup.

I have never run out of Guide data.. but then again I have been keeping on top of it because I noticed shows having no description, so I checked and saw that calls were failing. I never let it get to the point of giving me an error message about running out of Guide data. it could be that the longer it is allowed to fail, the harder it is to get calls to complete.

Hmm... I think I was getting more successful calls at first after renaming the log directory than now... maybe I should see how many successful calls I get after clearing the logs and getting success.. how many more I get before they start to fail again. But not sure if I should do stuff like that if Tivo is monitoring my unit because then maybe that would be removing evidence.

I have PM'ed TivoJerry with the answers to the dialup user questions. (I have a TurboNet but I do not have broadband.)

BrendaG4

 

Not to pour more fuel on this fire, but the Series 1 DST work-around isn't going to work well if people's Tivos can't make daily calls. DST starts on March 8 -- less than one month away. People should be prepared to keep an eye on their manual recordings from March 8 to April 5.

THe effects of this are better discussed in this thread: http://www.tivocommunity.com/tivo-vb/showthread.php?t=344459&highlight=dst+update

 

You need to completely delete the log files. I have not missed a call since I deleted every file in the /var/log directory.

 

But...doesn't Linux, by default, create the logfile that it's attempting to log to if the logfile does not exist?

Are you saying that, right now, you have a totally empty /var/log directory?

BittMann

 

Code:

/var/log # ls -l
total 1141
-rw-r--r--   1 0        0               0 Feb  8 08:19 Okdebug
-rw-r--r--   1 0        0            1173 Feb  9 11:43 Okernel
-rw-r--r--   1 0        0             615 Feb  9 00:25 Omessages
-rw-r--r--   1 0        0           76542 Feb  9 11:43 Otcdebuglog
-rw-r--r--   1 0        0           70235 Feb  9 11:43 Otclient
-rw-r--r--   1 0        0               0 Feb  8 08:19 Otvdebuglog
-rw-r--r--   1 0        0               0 Feb  8 08:19 Otverr
-rw-r--r--   1 0        0          453162 Feb  9 11:43 Otvlog
-rw-r--r--   1 0        0               0 Feb  9 11:43 kdebug
-rw-r--r--   1 0        0           10073 Feb 10 13:01 kernel
-rw-r--r--   1 0        0               0 Jan 27 00:17 maillog
-rw-r--r--   1 0        0             996 Feb 10 14:54 messages
-rw-r--r--   1 0        0               0 Jan 27 00:17 secure
-rw-r--r--   1 0        0             177 Feb 10 14:53 svclog
-rw-r--r--   1 0        0           23158 Feb 10 14:53 tcdebuglog
-rw-r--r--   1 0        0           46507 Feb 10 14:53 tclient
-rw-r--r--   1 0        0           25201 Feb 10 14:53 tivoLog.prv
-rw-r--r--   1 0        0            3785 Feb 10 14:22 tivoLog.prv.gz
-rw-r--r--   1 0        0            4456 Feb 10 14:22 tivoLog.prv.gz.bfg
-rw-r--r--   1 0        0               0 Feb 10 14:22 tivoLog.pub
-rw-r--r--   1 0        0               0 Feb  9 11:43 tvdebuglog
-rw-r--r--   1 0        0               0 Feb  9 11:43 tverr
-rw-r--r--   1 0        0          434673 Feb 10 14:54 tvlog
/var/log #

That's my /var/log directory currently. Obviously the log files were recreated, but I'm not sure if there's a size at which things will start failing again.

 

I didn't clear my log files to get out of guided setup. I simply changed the areacode to "818". My turbonet had gotten jarred loose somewhere along the way, I think it had already started failing before that point. The idiot light on the board, as well as on the switch, was still on which made me think it was ok. After the good dialup calls into the "818" number, I reseated my turbonet and that worked straight off. The dir listing on my /var/log looks exactly as the one just posted.

 

OK...so your log files don't look significantly different than mine do, it appears. You are logging, you are still uploading to TiVo, etc.

Clearing the log files might help if you have a HUGE amount of data to upload, and you have a line that's prone to randomly dropping. More data means longer transmission times, and i you have a line that will "drop" randomly and the transmission takes a significant amount of time, you have more of a chance that the line will drop during a transmission.

Clearing the log files doesn't appear to have much of a bearing on what at least some of us are seeing, however. I definitely have a good connection that does not "drop" (proven by the ability of the TiVo to "ntpdate" repeatedly during the failed call), but that the far end of the link simply doesn't accept the upload of the data, no matter how small the transmission.

At least, that's what I'm seeing here, anyway.

BittMann

 

Just as a datapoint -- I am not on dialup, but am connecting via a Turbonet card. I was unable to do any packet sniffing when things weren't working due to lack of a hub, but it never appeared that the connection was dropping in midstream.