TiVo Community
TiVo Community
TiVo Community
Go Back   TiVo Community > Main TiVo Forums > TiVo Help Center
TiVo Community
Reply
Forum Jump
 
Thread Tools
Old 02-09-2009, 04:09 PM   #391
bittmann
Registered User
 
Join Date: Apr 2005
Posts: 57
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
bittmann is offline   Reply With Quote
Old 02-09-2009, 07:08 PM   #392
bittmann
Registered User
 
Join Date: Apr 2005
Posts: 57
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 is offline   Reply With Quote
Old 02-10-2009, 01:25 AM   #393
brendag4
Registered User
 
Join Date: Apr 2005
Posts: 92
Bittmann,

Quote:
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.
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
brendag4 is offline   Reply With Quote
Old 02-10-2009, 08:19 AM   #394
BobCamp1
Registered User
 
Join Date: May 2002
Posts: 992
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...ght=dst+update
BobCamp1 is offline   Reply With Quote
Old 02-10-2009, 08:33 AM   #395
pianoman
:-|
 
pianoman's Avatar
 
Join Date: Jun 2002
Location: Metairie, LA
Posts: 3,663
Quote:
Originally Posted by bittmann View Post
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.
You need to completely delete the log files. I have not missed a call since I deleted every file in the /var/log directory.
__________________
You inspired me, Pianoman! -- M82A1A
Pianoman, you have inspired me. -- hefe
Pianoman, that's not very inspiring. -- edhara
pianoman is offline   Reply With Quote
Old 02-10-2009, 08:37 AM   #396
bittmann
Registered User
 
Join Date: Apr 2005
Posts: 57
Quote:
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
bittmann is offline   Reply With Quote
Old 02-10-2009, 08:56 AM   #397
pianoman
:-|
 
pianoman's Avatar
 
Join Date: Jun 2002
Location: Metairie, LA
Posts: 3,663
Quote:
Originally Posted by bittmann View Post
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.
__________________
You inspired me, Pianoman! -- M82A1A
Pianoman, you have inspired me. -- hefe
Pianoman, that's not very inspiring. -- edhara
pianoman is offline   Reply With Quote
Old 02-10-2009, 09:39 AM   #398
joeysmith
Registered User
 
joeysmith's Avatar
 
Join Date: Jan 2002
Posts: 95
Quote:
Originally Posted by brendag4 View Post
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 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.

Last edited by joeysmith : 02-10-2009 at 09:53 AM.
joeysmith is offline   Reply With Quote
Old 02-10-2009, 10:07 AM   #399
bittmann
Registered User
 
Join Date: Apr 2005
Posts: 57
Quote:
Obviously the log files were recreated, but I'm not sure if there's a size at which things will start failing again.
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
bittmann is offline   Reply With Quote
Old 02-10-2009, 10:39 AM   #400
pianoman
:-|
 
pianoman's Avatar
 
Join Date: Jun 2002
Location: Metairie, LA
Posts: 3,663
Quote:
Originally Posted by bittmann View Post
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.
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.
__________________
You inspired me, Pianoman! -- M82A1A
Pianoman, you have inspired me. -- hefe
Pianoman, that's not very inspiring. -- edhara
pianoman is offline   Reply With Quote
Old 02-11-2009, 01:42 AM   #401
brendag4
Registered User
 
Join Date: Apr 2005
Posts: 92
Joey...

Quote:
I didn't clear my log files to get out of guided setup. I simply changed the areacode to "818".
When you got out by changing the area code, was the TurboNet fixed at that time? Just wondering if our problems of getting out of Guided Setup were due to us having connection problems with the network. (Your TurboNet was not properly seated and my router had partially come unplugged.) Maybe our Guided Setup issue was just a coincidence and not related to this problem.

I know you have said you deleted the logs, so I guess I was assuming that was how you got out of Guided Setup or I forgot how the story went.

I have continued to have problems after deleting the logs... but it usually makes completes the call. If not it only takes a few calls to get it.

I keep forgetting and saying I deleted the logs when really I just renamed the the directory because it was not sure if I would lose a needed file. But it seems they are recreated.

When you changed the area code, did you have to make a lot of calls to get through? I tried it but it didnt work.. so not sure if I just did not try it enough times.

BrendaG4
brendag4 is offline   Reply With Quote
Old 02-11-2009, 08:15 AM   #402
joeysmith
Registered User
 
joeysmith's Avatar
 
Join Date: Jan 2002
Posts: 95
Quote:
Originally Posted by brendag4 View Post
Joey...

When you got out by changing the area code, was the TurboNet fixed at that time? Just wondering if our problems of getting out of Guided Setup were due to us having connection problems with the network. (Your TurboNet was not properly seated and my router had partially come unplugged.) Maybe our Guided Setup issue was just a coincidence and not related to this problem.
<snip>
BrendaG4
No it was not, and I think the whole turbonet episode for me might have been a red herring. I even know when it probably got knocked loose - I had lifted and turned the Tivo around as I had hooked up an IR blaster for my OTA digital receiver. I had already gotten through one guided setup at that point. The Tivo actually froze and I had to pull the plug and reboot. I then decided I wanted to change my hook up settings to "off air" instead of cable - this is when I found my turbonet had started getting problems during guided setup. I then switched to dialup and found that wasn't working either. Googling quickly pointed me to this thread.

After I got through guided setup with the 818 code I opened up the box again, almost resigned to a fresh cake install (to try and get the turbonet working). It was then I discovered that the turbonet was not seated properly. The green led light on the board and on the switch port had fooled me. After that, it started working again. I did try a dialup afterward and got one failed test out of four. The turbonet stopped working after the failed test but rebooting took care of that problem. Somebody had posted that it needs a reboot if you switch from dialup to ethernet - which is probably correct.
joeysmith is offline   Reply With Quote
Old 02-11-2009, 08:33 AM   #403
bittmann
Registered User
 
Join Date: Apr 2005
Posts: 57
Quote:
Originally Posted by brendag4 View Post
Maybe our Guided Setup issue was just a coincidence and not related to this problem.
I, myself, would certainly think that is a reasonable assumption.

Quote:
I have continued to have problems after deleting the logs... but it usually makes completes the call. If not it only takes a few calls to get it.
I would expect that to be the case, if you're suffering from the same POST issues that I and some others seem to be legitimately, if intermittently, experiencing.

Here's how you can tell, since you have telnet access: If your system goes to "connecting" and simply sets there, or goes to "downloading" for a long period of time, you can log in to your box and issue the command

tail /var/log/tclient

If the resulting display ends in something that looks like this:

Quote:
Feb 4 13:51:34 (none) comm[129]: CommUtil: connection to host 204.176.49.2, port 80, err 0x0
Feb 4 13:51:34 (none) comm[129]: Uploading HTTP Header for modLog of /var/log/svclog: POST /tivo-service/mlog.cgi HTTP/1.0^M Content-Length: 2342^M ^M

and/or

Quote:
Feb 4 13:51:34 (none) comm[129]: CommUtil: connection to host 204.176.49.2, port 80, err 0x0
Feb 4 13:51:34 (none) comm[129]: Uploading HTTP Header for modLog of /var/log/svclog: POST /tivo-service/mlog.cgi HTTP/1.0^M Content-Length: 2342^M ^M
Feb 4 13:54:31 (none) comm[129]: XferRqst timeout waiting to read


and repeated "tail" commands show no progress up to and until the TiVo dialin fails --

-- then you're NOT having "networking" issues, you're having "TiVo is not talking to me" issues, and that (probably) isn't something that you can fix on your own.


Conversely, if you don't see something like the above, then you don't have this particular "not talking to me" issue, and you'll need to start troubleshooting based on the problem that you're observing.

Quote:
Originally Posted by joeysmith View Post
I think the whole turbonet episode for me might have been a red herring
I'm thinking you're right about that.

That being said, you (or anyone) who has telnet access can do the above command if you think that your TiVo is hanging during download...and if you see something like I linked in there, at least you'll have an inkling about what's going on.

Really, as long as even as few as 1 in 5 dialins goes through, most folks won't even notice that they have a "problem". It's only when enough dialins in a row fail, and you start getting warnings about running out of guide data, that the issue even becomes apparent.

And what makes this hard to troubleshoot: Even if you DO unsuccessfully try to force a call or two, and then you call TiVo's help desk who asks you to force a call or 2 more -- plus, the automated daily calls that should happen anyway -- if this is truly a "sometimes it works, sometimes it doesn't" issue, then one of those tries will probably go through, and that user might just be "fine" from that point forward.

Until it happens again, of course.

BittMann
bittmann is offline   Reply With Quote
Old 02-11-2009, 08:59 AM   #404
joeysmith
Registered User
 
joeysmith's Avatar
 
Join Date: Jan 2002
Posts: 95
Something did change as there were many reports of not being able to connect at all since December. These reports seem to have subsided. I had many days of not being able dial in until that first successful call. A friend who had dialup problems tells me it's cleared up for him as well...
joeysmith is offline   Reply With Quote
Old 02-11-2009, 09:25 AM   #405
bittmann
Registered User
 
Join Date: Apr 2005
Posts: 57
Quote:
Originally Posted by joeysmith View Post
Something did change as there were many reports of not being able to connect at all since December. These reports seem to have subsided. I had many days of not being able dial in until that first successful call. A friend who had dialup problems tells me it's cleared up for him as well...
Like I said: As long as a user has a successful connection every now and then, then as far as that user is concerned, there's not a problem. That doesn't mean that there's not a problem, just that the problem isn't really affecting you.

Heck, lately the problem hasn't really affected ME (dialins do go through periodically) -- it's just that after TivoJerry wanted logs I began to watch more closely.

BittMann
bittmann is offline   Reply With Quote
Old 02-11-2009, 10:23 AM   #406
joeysmith
Registered User
 
joeysmith's Avatar
 
Join Date: Jan 2002
Posts: 95
Quote:
Originally Posted by bittmann View Post
Like I said: As long as a user has a successful connection every now and then, then as far as that user is concerned, there's not a problem. That doesn't mean that there's not a problem, just that the problem isn't really affecting you.

Heck, lately the problem hasn't really affected ME (dialins do go through periodically) -- it's just that after TivoJerry wanted logs I began to watch more closely.

BittMann
Not sure we're saying the same thing. I believe there was a definite problem going back to December-January and I experienced those symptoms myself on dialup, not being able to complete any calls repeatedly. I also believe that there has been some kind of change (don't know where) so that those symptoms still occcur sporadically but now calls are going through. You seem to be saying that nothing has really changed at all.
joeysmith is offline   Reply With Quote
Old 02-11-2009, 10:48 AM   #407
GBL
covert opiniative
 
GBL's Avatar
 
Join Date: Apr 2000
Location: Twin Cities, MN
Posts: 1,636
As a long time Tivo user with 3 still active life time Series 1 units who also encounters the same problem let me just add a couple of thoughts:

Quote:
Originally Posted by bittmann View Post
That being said, you (or anyone) who has telnet access can do the above command if you think that your TiVo is hanging during download...and if you see something like I linked in there, at least you'll have an inkling about what's going on.
BittMann
1) viewing the logs is also possible without telnet access and without turbonet etc. Simply enable backdoors and, on TiVo central, press Clear, Enter, Clear, Thumbs up. Then right arrow until you get to the log you want to look at. Use Thumbs down/up (beginning/end of log) up/down arrow, channel up/down (page up/down) to navigate the log. Left arrow returns to tivo central.

Quote:
Originally Posted by bittmann View Post
Like I said: As long as a user has a successful connection every now and then, then as far as that user is concerned, there's not a problem. That doesn't mean that there's not a problem, just that the problem isn't really affecting you.

Heck, lately the problem hasn't really affected ME (dialins do go through periodically) -- it's just that after TivoJerry wanted logs I began to watch more closely.

BittMann
2) I have yet to run out of guide data on any of my tivos - so i totally agree with you. However, since some users do run out of guide data, it is a problem that needs to be addressed by Tivo and apparently is looked at by TivoJerry.

3) my logs also show a timeout failure after post to mlog.cgi.
__________________
"Driving requires the brain cells of a mule, and a license."
To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts.


unpaid volunteer, TiVo army
GBL is offline   Reply With Quote
Old 02-11-2009, 10:49 AM   #408
bittmann
Registered User
 
Join Date: Apr 2005
Posts: 57
Quote:
Originally Posted by joeysmith View Post
Not sure we're saying the same thing. I believe there was a definite problem going back to December-January and I experienced those symptoms myself on dialup, not being able to complete any calls repeatedly. I also believe that there has been some kind of change (don't know where) so that those symptoms still occcur sporadically but now calls are going through. You seem to be saying that nothing has really changed at all.
I don't think we are saying the same thing. I'm concentrating on the demonstrated "no response from mlog.cgi" issue that we discovered after TivoJerry's request for tcpdumps and logfiles. What this has to do with the problems (some) experienced in December-January (and earlier, maybe?)? I don't know---maybe nothing.

And I'm not saying that nothing has changed since January. Maybe something has. Like I said: I don't know -- I wasn't looking at logs and tcpdumps back then.

All I do know is: If my TiVo can't POST to mlog.cgi, the download fails (either at connecting, or after downloading for a while). And I do know that I'm not the only user who has seen this failure happen, and that I'm not the only user who has actually caught it in the act of failing in a network dump. And I do know that it doesn't fail all of the time (obviously), and that many/most users likely wouldn't know that there was an issue EVEN IF they were affected by this problem as long as the dialin goes through every few days.

So, if your assertion is that something changed in January that made things better, I'll let you make that assertion, no argument from me, because I don't know any different (and suspect that you may very well be correct). But I won't agree that there are not "other" ongoing problem, because I (and others) have logs that indicate otherwise...even if the actual end-user impact of those problems are limited in scope or severity.

BittMann

UPDATED: @GBL -- Thanks for the additional datapoint. So: If you're browsing the tclient log via whatever methodology (telnet, tivoweb, or backdoor, etc.) after a download fails, then all you need to do is look for any instance of an "XferRqst timeout waiting to read" following a POST to mlog.cgi, and if you find one, you'll be verifying that you're (probably) seeing the same issue that several of us are noting now. Sound about right?

Last edited by bittmann : 02-11-2009 at 11:09 AM.
bittmann is offline   Reply With Quote
Old 02-11-2009, 10:56 AM   #409
joeysmith
Registered User
 
joeysmith's Avatar
 
Join Date: Jan 2002
Posts: 95
sounds good. i agree that there are ongoing problems as evidenced by spot dial up checks i did after i got things going again. cgi's are a kluge and are definitely not a scalable solution. not surprised it's burping the way it is. struggled with many a cgi problem in web 1.0...
joeysmith is offline   Reply With Quote
Old 02-11-2009, 01:00 PM   #410
dlee0708
Registered User
 
Join Date: Sep 2002
Location: Lewisville, TX
Posts: 105
Quote:
Originally Posted by joeysmith View Post
Not sure we're saying the same thing. I believe there was a definite problem going back to December-January and I experienced those symptoms myself on dialup, not being able to complete any calls repeatedly. I also believe that there has been some kind of change (don't know where) so that those symptoms still occcur sporadically but now calls are going through. You seem to be saying that nothing has really changed at all.
For some maybe things have changed, but for my mom absolutely no calls have gone thru since December 3. She has had no Guide data since December 3. It is still exactly the same for her.

I finally got my mom to hook up the Hub I sent her and we captured a Network Trace of the failure and I have sent that to TivoJerrry.
dlee0708 is offline   Reply With Quote
Old 02-11-2009, 03:13 PM   #411
Sir_winealot
Seenyer Member
 
Join Date: Nov 2000
Posts: 2,082
Since I've given TiVoJerry our S1 SN, our unit has completed its call every day for the last 5-6 days or thereabouts. Seems to be working normally now... at least for us.
__________________

Sony 60" SXRD HDTV
Sony 42" A10 HDTV
Sharp 32" LC-32DA5U HDTV
Panasonic 32" LX70 HDTV
HR10-250 x 3
Sony T-60

Sir_winealot is offline   Reply With Quote
Old 02-11-2009, 06:26 PM   #412
bittmann
Registered User
 
Join Date: Apr 2005
Posts: 57
Heh...same failure mode, different fingerprint.

Quote:
Feb 11 18:16:35 (none) comm[140]: CommUtil: connection to host 204.176.49.2, port 80, err 0x0
Feb 11 18:16:35 (none) comm[140]: read 8095 bytes of upload data for HServerRqst
Feb 11 18:16:35 (none) comm[140]: read 2626 bytes of upload data for HServerRqst
Feb 11 18:19:10 (none) WatchdogAction[139]: WatchdogAction::Trigger: callActive for 1800 interval-secs
Actually transferred 2 packets before giving up the ghost this time.

(Hmmm....I wonder what would happen if one were to write a quick mlog.cgi script that simply redirected POST data to /dev/null, and then added a firewall rule to force port 80 communications to the local server? Naah...)

BittMann
bittmann is offline   Reply With Quote
Old 02-11-2009, 09:12 PM   #413
joeysmith
Registered User
 
joeysmith's Avatar
 
Join Date: Jan 2002
Posts: 95
a common enough scenario would be that the cgi has a memory leak so after some time the server starts acting weird then eventually refuses to take connections or whatever. an equally common quick and dirty fix is to schedule frequent reboots to clear the condition (been there done that). so the problem is still there but being cleared more often....
joeysmith is offline   Reply With Quote
Old 02-11-2009, 11:20 PM   #414
danm628
Registered User
 
Join Date: May 2002
Location: Vancouver, WA
Posts: 221
Based on what others are seeing I suspect that TiVo may have multiple servers. They could be mapped via DNS or mapped via a mux at the IP level so they all have the same address. (I haven't checked if I always connect to the same IP, too much stuff to do at work to spend time testing this.)

If they are using multiple servers it is possible that only some of them are causing the failure. Worst case, all of the servers fail except for one. If you manage to connect to the good server then things work. Otherwise you fail.

Just a thought based on dealing with similar problems in the past. Of course I could be 100% off base here.

My Series 1 manages a couple of good connections a week. Enough to keep it running for now.

- Dan
danm628 is offline   Reply With Quote
Old 02-11-2009, 11:56 PM   #415
dlee0708
Registered User
 
Join Date: Sep 2002
Location: Lewisville, TX
Posts: 105
Quote:
Originally Posted by danm628 View Post
Based on what others are seeing I suspect that TiVo may have multiple servers. They could be mapped via DNS or mapped via a mux at the IP level so they all have the same address. (I haven't checked if I always connect to the same IP, too much stuff to do at work to spend time testing this.)

If they are using multiple servers it is possible that only some of them are causing the failure. Worst case, all of the servers fail except for one. If you manage to connect to the good server then things work. Otherwise you fail.

Just a thought based on dealing with similar problems in the past. Of course I could be 100% off base here.

My Series 1 manages a couple of good connections a week. Enough to keep it running for now.

- Dan
My mother would be deliriously happy if she could get just 1 connection/week. She has had 0 connections since December 3 (this translates to no guide information at all for 2.5 months). I think she has just about had it if something doesn't change in the next couple of days.
dlee0708 is offline   Reply With Quote
Old 02-12-2009, 02:46 AM   #416
badcrc
Thread Killer
 
Join Date: Aug 2000
Location: Bremerton WA
Posts: 165
Quote:
Originally Posted by dlee0708 View Post
My mother would be deliriously happy if she could get just 1 connection/week. She has had 0 connections since December 3 (this translates to no guide information at all for 2.5 months). I think she has just about had it if something doesn't change in the next couple of days.
Sorry if you mentioned this before, but I'm curious, has your mom tried several dial-in numbers and tried each of them at least 8-10 times in a row? Mine give me a different error almost every time when it fails, but eventually it gets through. It's strange though, in the last few days they all seem to be working more reliably, though still failing regularly. I did send all three of my TSNs to TivoJerry last Friday.
__________________
Three TiVo HDR112 Series 1 with lifetime
163 hours, 93 hours, 91 hours.
badcrc is offline   Reply With Quote
Old 02-12-2009, 07:28 AM   #417
joeysmith
Registered User
 
joeysmith's Avatar
 
Join Date: Jan 2002
Posts: 95
Quote:
Originally Posted by danm628 View Post
Based on what others are seeing I suspect that TiVo may have multiple servers. They could be mapped via DNS or mapped via a mux at the IP level so they all have the same address. (I haven't checked if I always connect to the same IP, too much stuff to do at work to spend time testing this.)
<snip>

- Dan
The normal way it's done is to implement some sort of load balancing mechanism usually via some kind of network appliance. You would see one ip address and it would take care of distributing to the back ends. I would not be surprised if they have a number of servers, specially with the old web tech that seems to be causing the hiccups. Since last week, I have not had failures via my turbonet connection. I can try a test again today on the dialups.
joeysmith is offline   Reply With Quote
Old 02-12-2009, 07:28 AM   #418
dlee0708
Registered User
 
Join Date: Sep 2002
Location: Lewisville, TX
Posts: 105
Quote:
Originally Posted by badcrc View Post
Sorry if you mentioned this before, but I'm curious, has your mom tried several dial-in numbers and tried each of them at least 8-10 times in a row? Mine give me a different error almost every time when it fails, but eventually it gets through. It's strange though, in the last few days they all seem to be working more reliably, though still failing regularly. I did send all three of my TSNs to TivoJerry last Friday.
Thanks for the suggestions, but I sent her TSN to TivoJerry 2 weeks ago and she has TurboNet and not dial-in so she doesn't have the ability to use different Dial-ins. Hers never gets past the connecting stage therefore never gets to the accumulating downloading Guide stage (always fails sending log up to TivoInc) and therefore the retrying over and over doesn't work for her as it does for others.
dlee0708 is offline   Reply With Quote
Old 02-12-2009, 07:29 AM   #419
joeysmith
Registered User
 
joeysmith's Avatar
 
Join Date: Jan 2002
Posts: 95
Quote:
Originally Posted by badcrc View Post
Sorry if you mentioned this before, but I'm curious, has your mom tried several dial-in numbers and tried each of them at least 8-10 times in a row? Mine give me a different error almost every time when it fails, but eventually it gets through. It's strange though, in the last few days they all seem to be working more reliably, though still failing regularly. I did send all three of my TSNs to TivoJerry last Friday.
Or tried other areacodes that seem to be working better?
joeysmith is offline   Reply With Quote
Old 02-12-2009, 08:18 AM   #420
bittmann
Registered User
 
Join Date: Apr 2005
Posts: 57
Something I wonder...could anyone with a later version TiVo check their logs and see if that particular CGI is still part of the nightly call, and if so, is it an HTTP1.1 or 1.0 "claimed" connection in the logs. Erm...Has that already been reported here and I just missed it?

BittMann
bittmann is offline   Reply With Quote
Reply
Forum Jump




Thread Tools


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Advertisements

TiVo Community
Powered by vBulletin® Version 3.6.8
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
vBulletin Skins by: Relivo Media

(C) 2013 Magenium Solutions - All Rights Reserved. No information may be posted elsewhere without written permission.
TiVoŽ is a registered trademark of TiVo Inc. This site is not owned or operated by TiVo Inc.
All times are GMT -5. The time now is 11:07 AM.
OUR NETWORK: MyOpenRouter | TechLore | SansaCommunity | RoboCommunity | MediaSmart Home | Explore3DTV | Dijit Community | DVR Playground |