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?

I joined this forum for the sole purpose of sending TivoJerry my TSN. I too experience the same problems most are having - call failed, call interrupted, etc. While the recent discussions have been about clearing logs, I only have the dial-up option and do not have access to the file system. This is frustrating to say the least as I constantly, on a daily basis, babysit to see what it did. Does anyone know if this affects series 2 boxes? If not, what's the difference? I would like to upgrade to HD, but their boxes only support cable while I'm on DirecTV. I would hate to waste my lifetime subscription transfer on a non-HD machine, but am tempted to do so. This has been going on too long! I am hopeful that a resolution is in the works, but I don't see any indication of that happening. Is this going to be one of those problems where it just gets brushed off? There's got to be many more out there that just aren't posting.

I've also been having problems on a recently repurposed Series 1 unit with Lifetime service and turbonet. I initially thought that my old turbonet card (ISA riser with Kingston NIC) was going bad so I opened another Series 1 of mine that is retired and took out the newer (much smaller) NIC and put that in the unit. It made no difference. I even went so far as to reimage the drive in the unit and repeat guided setup but that seemed to take on the order of 15-20 tries for it to complete (but it eventually did amongst a bunch of service unavailable and call interrupted messages).

My question for TiVoJerry is: Do you still need captures of the failed events? If so I can get out my old 10baseT hub and use wireshark to capture a failed call if you would like. I see that several others have already provided you with TCP captures so I just want to see if you would like to have more data or not before I go to all the work to set this up.

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:

.
.
.(data in Original Post on 02/07/2009)

Well, I think my mother has pretty much had it with this situation. She has not had a successful connection since Dec 3, no program guide data since Dec 17.

I took the data from my Tcp capture and wrote a simple little test program to send the same connetion to Tivo and it works fine (acks the 2nd packet). The difference is the 2nd packet sent by my test program is 536 bytes instead of 1460 like the Tivo is sending. For some stinking reason Vista is setting the MTU down to 576 when I run my program and just sending 536 bytes at a time. But if I run Outlook Express and send a large file it sends much larger packets (still not 1460, but at least larger than 536). I don't know where this problem is, but I am giving up on this. I wish Tivo would at least tell us what is going on. Just even knowing if the packets are getting to TivoInc would be something. But as far as telling us what they have determined what is wrong, nothing has come back.

I've also been having problems on a recently repurposed Series 1 unit with Lifetime service and turbonet. I initially thought that my old turbonet card (ISA riser with Kingston NIC) was going bad so I opened another Series 1 of mine that is retired and took out the newer (much smaller) NIC and put that in the unit. It made no difference. I even went so far as to reimage the drive in the unit and repeat guided setup but that seemed to take on the order of 15-20 tries for it to complete (but it eventually did amongst a bunch of service unavailable and call interrupted messages).

My question for TiVoJerry is: Do you still need captures of the failed events? If so I can get out my old 10baseT hub and use wireshark to capture a failed call if you would like. I see that several others have already provided you with TCP captures so I just want to see if you would like to have more data or not before I go to all the work to set this up.

/troy

Troy,

If you ever connect up the Hub, I am curious does yours fail the same way my mothers does (see post on 02/07/2009 for full data if you want to see it). My mothers makes a connection, sends a Http POST packet of 63 bytes, then sends 1460 bytes, gets the ack from TivoInc of the first 63 bytes (ack 64) but never gets an ack from TivoInc for the 2nd 1460 byte packet. Then all you see is the Tivo resend the 2nd packet about 10 times and then a Server error from TivoInc (still just acking the first 63 bytes) and the connection ends.

Haven't posted for awhile, but the past few days I have been getting about 30% failures, either service unavailable during connecting or call interrupted during downloading. Much better than in Dec and Jan but obviously still not fixed as I had earlier thought. Oh well, at least I have up to date guide data with a little babysitting.

One thing, though, I have really learned to appreciate the UI of the S1; it is blazing fast and I am not blindsided by ads like I am on my S2

I'd really like to keep the old Sony purring along as long as possible. I plan on getting a HD model if they ever support clear QAM with guide data. I personally have no use for a STB with 900 channels and really only want my locals in HD. The SciFi channel crap is still going to be crap regardless of whether it is in HD or not.

OTA is a non starter for me as I cannot use an outdoor antenna and the two indoor ones I tried worked as well as hooking up a banana instead.

I joined this forum for the sole purpose of sending TivoJerry my TSN. I too experience the same problems most are having - call failed, call interrupted, etc. While the recent discussions have been about clearing logs, I only have the dial-up option and do not have access to the file system. This is frustrating to say the least as I constantly, on a daily basis, babysit to see what it did. Does anyone know if this affects series 2 boxes? If not, what's the difference? I would like to upgrade to HD, but their boxes only support cable while I'm on DirecTV. I would hate to waste my lifetime subscription transfer on a non-HD machine, but am tempted to do so. This has been going on too long! I am hopeful that a resolution is in the works, but I don't see any indication of that happening. Is this going to be one of those problems where it just gets brushed off? There's got to be many more out there that just aren't posting.

Well, I think my mother has pretty much had it with this situation. She has not had a successful connection since Dec 3, no program guide data since Dec 17.

I took the data from my Tcp capture and wrote a simple little test program to send the same connetion to Tivo and it works fine (acks the 2nd packet). The difference is the 2nd packet sent by my test program is 536 bytes instead of 1460 like the Tivo is sending. For some stinking reason Vista is setting the MTU down to 576 when I run my program and just sending 536 bytes at a time. But if I run Outlook Express and send a large file it sends much larger packets (still not 1460, but at least larger than 536). I don't know where this problem is, but I am giving up on this. I wish Tivo would at least tell us what is going on. Just even knowing if the packets are getting to TivoInc would be something. But as far as telling us what they have determined what is wrong, nothing has come back.

FWIW: I messed around with my TiVo a bit, setting the MTU on the NIC way down. Tried 1460, 1400, 800, and 128 (!!) byte MTUs with the same result -- regardless of MTU, sometimes it'd hang on the POST, sometimes it wouldn't. For what little THAT's worth.

I have a SA series2 that's joining in on the data guide loss. Haven't been able to successfully download & install since December. When I do a search for local numbers they are found and downloaded no problem but if i try any in- state numbers with test phone connection or make daily call, they all fail. Tried 818 450 1705 & 602 605-1880 & other states as well. Burbank and Arizona came the closest to completion but failed on download or install. I was going to try a new image install as well, thinking perhaps an older software version might work but apparently doesn't look well. If an older image doesn't remedy the problem does that point to a integral motherboard situation for the series 1 & 2 that conflicts with new scripts from Tivo Central? I have a hughes sddvr40 that downloads data as always. Not ready to do a Cl&Del yet, although I believe that has been tried already. Can you serial connect to unmodded series2?

FWIW: I messed around with my TiVo a bit, setting the MTU on the NIC way down. Tried 1460, 1400, 800, and 128 (!!) byte MTUs with the same result -- regardless of MTU, sometimes it'd hang on the POST, sometimes it wouldn't. For what little THAT's worth.

BittMann

BittMann,

That is real interesting information. Could you set the MTU down to 576, do a Daily Call and post the the Tcp capture like you did on 02/09, except also post the HTTP POST /tivo-service..., the next packet the Tivo sends (seq 64) and then the next 2 packets received by TivoInc (or the whole thing if you want). I would do this myself, but its my Mom's Tivo that is having the problem and it doesn't have telnet access (still kicking myself for not adding that). I mainly want to see the size of the packets sent to TivoInc and what ack packets coming back from TivoInc telling me what packets it has received.

I just don't understand why my test program running on my mom's computer gets responses from TivoInc, but the Tivo doesn't. I thought it was because of the MTU difference, but your little test shows different and I just want to see what the difference is when you set the MTU down to what her computer has it set at. I can change my program to look like your test and see what happens on my mom's Tivo. Maybe we can figure out what is making it fail, because it appears Tivo isn't making any effort to tell us. This is the first time I haven't defended Tivo, but I have not heard Jack Squat from them, so I have changed my tune.. I'm not expecting a fix from Tivo necessarily, but at least info on what they know. I have spent a ton of time and my mothers time trying to help find the problem instructing my 82 year old mother on how to set up the network and then me getting the trace and sending to it Tivo with all the info and I don't think they have done anything (or if they have done anything they haven't said anything).

The one thing that for sure Tivo should know is whether the packets sent from my mom's Tivo are making it to TivoInc. If they aren't getting there, then I can tell her ISP they need to fix whatever it is that is blocking the packets to TivoInc, but I don't feel I should do that unless I know for sure that TivoInc is not getting the packets.

And don't give up on TiVo just yet. If this was "easy", it would've been fixed earlier. And if it wasn't something that they are going to try to fix, TivoJerry wouldn't be involved.

BittMann

I can certainly wait for you to have a chance. Glad you are able to this.

I probably shouldn't have gotten harsh, but it's starting to get frustrating. To be honest, I really don't think my my mothers problem is really a Tivo problem (Tivo DVR or Server at TivoInc), but a network issue that is not handling this old HTTP HTML1.0 format (or something like that), but TivoInc should be able to look at our logs, compare them to what there Ethereal/WireCapture are seeing on their end and tell us where the problem is. It happens on my mothers Tivo 100% of the time. It would be very simple to figure this out, look at my mothers capture, look on their side and see if they are getting the packets. Dang, I tried to keep from going negative, but I did it again. Please Tivo, restore my faith.

If you ever connect up the Hub, I am curious does yours fail the same way my mothers does (see post on 02/07/2009 for full data if you want to see it). My mothers makes a connection, sends a Http POST packet of 63 bytes, then sends 1460 bytes, gets the ack from TivoInc of the first 63 bytes (ack 64) but never gets an ack from TivoInc for the 2nd 1460 byte packet. Then all you see is the Tivo resend the 2nd packet about 10 times and then a Server error from TivoInc (still just acking the first 63 bytes) and the connection ends.

I connected everything up this morning (old Netgear 10baseT hub and Wireshark). My capture does look very similar to yours with several retransmissions on both ends and eventually ends with:

HTTP/1.1 500 Internal Server Error

Note that this is in a house with two TiVoHD units that connect just fine to the tivo service via broadband everyday.

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.

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

guys just bringing this up again. I followed cgf's method way back in early January and it is still working. I am able to get successful calls over turbonet daily.

by the way, I came here to look up something else but was surprised to find this problem is still happening. VERY disappointing response from Tivo

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.

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.

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:

Quote:

Originally Posted by dcstager

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.

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.

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.

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.

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.