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.

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.

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.

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.)

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.

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.

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.

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.

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.

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.

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

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

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.

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...

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.

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.

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

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

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.

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?

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...

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.

(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...)

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....

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.

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.

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.

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.

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.

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.

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?