I have had file transfers working fine for a very long time in both kmttg and Tivo Desktop. Today they suddenly stopped working. I can see the Tivos and get the Now Playing Lists, but when I start a transfer it aborts with an error. Tivo Desktop log says "error 4" but I can't find anywhere what that means.

File transfers started failing on 3 Tivos simultaneously.

I tried a whole bunch of things. Stumbled across one thing that worked. Changed kmttg to use Java instead of Curl. Tivo Desktop still does not work.

If anyone has any ideas, I'd love to hear them. If not, at least I'm documenting a partial fix for this problem

I have had file transfers working fine for a very long time in both kmttg and Tivo Desktop. Today they suddenly stopped working. I can see the Tivos and get the Now Playing Lists, but when I start a transfer it aborts with an error. Tivo Desktop log says "error 4" but I can't find anywhere what that means.

File transfers started failing on 3 Tivos simultaneously.

I tried a whole bunch of things. Stumbled across one thing that worked. Changed kmttg to use Java instead of Curl. Tivo Desktop still does not work.

If anyone has any ideas, I'd love to hear them. If not, at least I'm documenting a partial fix for this problem

Does Desktop start to copy and then suddenly announce that it can't find the file?

The same thing started to happen to me just a few hours ago. I've been pulling and pushing shows using pyTivo for years and kmttg for the last couple months with never an issue. I've rebooted my PC about 6 times and the TivoHDs at least twice and the router a couple times and still no dice. I can transfer files between TiVos but I can't get them to a PC whether using Tivo Desktop, pyTivo, or kmttg.

By the way, I can't get a transfer going from my Win7 notebook or my XP PC, either.

The same thing started to happen to me just a few hours ago. I've been pulling and pushing shows using pyTivo for years and kmttg for the last couple months with never an issue. I've rebooted my PC about 6 times and the TivoHDs at least twice and the router a couple times and still no dice. I can transfer files between TiVos but I can't get them to a PC whether using Tivo Desktop, pyTivo, or kmttg.

Could this be some kind of zero day attack?

I kind of doubt it's a zero day attack. I'm thinking it might be a date-dependent issue in curl.

Does Desktop start to copy and then suddenly announce that it can't find the file?

For me, it gets the metadata and then chokes on the .TiVo file. pyTivo says it's a 400 error and Tivo Desktop just says the file transfer failed and puts a red "x" next to the program in the listing. kmttg returns:

<h2>Bad Request</h2>
Download failed to file: <parsed filename>.TiVo
Exit code: 0
% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed

Okay, but there's no way to get Desktop to use Java instead of curl, is there?

and just for the stats, I'm running 2.8.2 on XP.

Sometimes it's fast and sometimes it's slow, but before now it's pretty much worked, wired and wireless.

And I just checked.

I've actually got 2 PCs running Desktop, one in the family room for the TiVos in there and one in the bedroom for the TiVos in there, although they're all on the same LAN, fixed IPs all around, and occasionally there's cross-pollination, where one room needs to "borrow" a tuner, with the show to copied to the "right" PC later on.

I noticed the same problem everyone else here on the Board has been describing. This, 24 hrs. after a successful 30 hour run of a block of programming transfers (I move large chunks to a 2tB archive drive to free up space for copy protected stuff on the TiVo HDD). Anyway, I get the message files transfer interrupted and then a detailed message that says the file(s) couldn't be located. I've screwed around now with several different program titles to see if a network or Comcast is trying to pull a fast one and copy protect a bunch of stuff but tried and true PBS stuff wouldn't move just as much as Discovery Channel stuff. I stopped Bonjour and tried TiVo Beacon with no change in result.

I suspect some poorly tested "upgrade" was sourced out overnight Thursday and this is causing the problem....I am too bleary eyed to check right now. How do we foment enough discontent with TiVo to get them to fix this very unacceptable situation?

I have a three year old Series 3 HD that I've upgraded to a 2tb drive, and a new Premier still in the box that I'm behind on setting up due to some computer issues that had me distracted......if this is TiVo's new policy, the Premier can stay in the box and get returned - it is of no use to me.

I noticed the same problem everyone else here on the Board has been describing. This, 24 hrs. after a successful 30 hour run of a block of programming transfers (I move large chunks to a 2tB archive drive to free up space for copy protected stuff on the TiVo HDD). Anyway, I get the message files transfer interrupted and then a detailed message that says the file(s) couldn't be located. I've screwed around now with several different program titles to see if a network or Comcast is trying to pull a fast one and copy protect a bunch of stuff but tried and true PBS stuff wouldn't move just as much as Discovery Channel stuff. I stopped Bonjour and tried TiVo Beacon with no change in result.

I suspect some poorly tested "upgrade" was sourced out overnight Thursday and this is causing the problem....I am too bleary eyed to check right now. How do we foment enough discontent with TiVo to get them to fix this very unacceptable situation?

I have a three year old Series 3 HD that I've upgraded to a 2tb drive, and a new Premier still in the box that I'm behind on setting up due to some computer issues that had me distracted......if this is TiVo's new policy, the Premier can stay in the box and get returned - it is of no use to me.

This was driving me CRAZY. Could not for the life of me figure out WTH. Thanks to notting for figuring it out...& how, may I ask? I'm a PC "power user"--no formal technical training but I've taught myself web programming (HTML, css, javascript), I write complicated batch files to automate procedures, I build my own desktops, etc. So I'm no technical dummy, but I didn't even know Tivos used cookies in the first place (don't recall seeing that in any documentation--and I do read the stuff), and I also just took a peek through kmttg's directory and couldn't see any likely place the Tivo might've been storing cookies. All kudos to your genius, and I'd love to know how you got to the bottom of this.

Anyhow, if the Tivos keep doing this and we have to keep turning back the clock, maybe the effect will rub off on users and we'll start looking younger...

I mentioned this in the other thread, but the TiVo box apparently doesn't care what the value of the SID cookie is, as long as it's being sent. As such you can "create" your own cookie and set it to expire in the future and it will work. See:

As I mentioned in the post below that, TiVo Desktop already checks for a cookie file to read from, but doesn't actually create one so it should be possible to simply give TiVo Desktop a modified cookie file and have it work.

All kudos to your genius, and I'd love to know how you got to the bottom of this.

I've gotten that error before over the web interface when I had disabled cookies entirely in Firefox. Once I remembered that, it was then just trying to figure out why the cookies weren't working. After trying a few other things, dumping the HTTP headers with curl showed the that it was sending a cookie that had already expired.

I hope that it's getting the cookie expiry date to send from the service when it phones home to see if transfers are enabled. If it's hardcoded in the software, it's going to be a lot longer for a fix since they'll need software updates for all three platforms. (if they're even going to bother fixing the S2s and S3s.)

I mentioned this in the other thread, but the TiVo box apparently doesn't care what the value of the SID cookie is, as long as it's being sent. As such you can "create" your own cookie and set it to expire in the future and it will work. See:

As I mentioned in the post below that, TiVo Desktop already checks for a cookie file to read from, but doesn't actually create one so it should be possible to simply give TiVo Desktop a modified cookie file and have it work.

TiVo Desktop uses curl.exe. Since TiVo Desktop passes it's own arguments to curl, there's no one size fits all fix for that. I posted in the other thread that the automated (but not easiest) would be to override the parameters that TiVo Desktop uses either by getting TiVo Desktop to call a batch file (if possible) passing along all the parameters except cookie one (using ours instead) or changing the curl program itself to hard code the cookie.

TiVo Desktop uses curl.exe. Since TiVo Desktop passes it's own arguments to curl, there's no one size fits all fix for that. I posted in the other thread that the automated (but not easiest) would be to override the parameters that TiVo Desktop uses either by getting TiVo Desktop to call a batch file (if possible) passing along all the parameters except cookie one (using ours instead) or changing the curl program itself to hard code the cookie.

So is it curl itself that cares about whether there's a cookie file and whether it's up to date?

Will everything work as before as long as we make it happy?

If so, sounds like the cure isn't to change the Y2K-ish problem with the TiVos, but to put out Desktop 2.8.3.we_screwed_up and to tell everybody running open source alternatives how to snooker curl into not caring about it.

So is it curl itself that cares about whether there's a cookie file and whether it's up to date?

Will everything work as before as long as we make it happy?

If so, sounds like the cure isn't to change the Y2K-ish problem with the TiVos, but to put out Desktop 2.8.3.we_screwed_up and to tell everybody running open source alternatives how to snooker curl into not caring about it.

It's not curl, it's the TiVo box that needs to be snookered. Here's how cookies work:

1. Web browser client requests a page from a HTTP server.
2. When the server responds with the requested page can include zero or more cookies. The server tells the client how long they are valid for in addition to a few other details that aren't important to this discussion.
3. In future requests to the server the client will include the cookie it was previously given as long as it hasn't expired. There are other conditions, but they also aren't relevant here.

That's it. The web server on the TiVo box was and still is serving the SID cookie to clients (curl, Firefox, whatever). The issue is that the server is telling the clients the cookie expired on Feb 16, 2013 at 12 AM GMT. As such the clients trash the cookie and don't include it when initiating the download of shows. The server expects the cookie and returns an error if it's missing, which is why everything broke today.

Now curl (and browser addons) can send user generated cookies to the server. Meaning it can send cookies it never received from the server. If the TiVo web server software was coded correctly, it would only allow downloads if the value of the SID cookie it receives matches the one it sent, but do to what I can only assume is a bug, it doesn't care if the values don't match. It only cares that there is a value.

As such we can use curl to send a bogus SID cookie to the TiVo web server and it happily allows the download to start. This requires changing a command line parameter sent to curl, which is what kmttg was changed to do now. TiVo Desktop is not sending the parameter to curl and I don't know of any easy way to intercept the call TiVo Desktop makes to curl.exe to inject the parameter. As such the only work around I can think of for TiVo Desktop is to patch either TiVo Desktop to send the command or curl think it received it. Of the two, curl would be easier as it's open source. I'm sure if TiVo doesn't fix this soon, someone will do that.

It's not curl, it's the TiVo box that needs to be snookered. Here's how cookies work:

1. Web browser client requests a page from a HTTP server.
2. When the server responds with the requested page can include zero or more cookies. The server tells the client how long they are valid for in addition to a few other details that aren't important to this discussion.
3. In future requests to the server the client will include the cookie it was previously given as long as it hasn't expired. There are other conditions, but they also aren't relevant here.

That's it. The web server on the TiVo box was and still is serving the SID cookie to clients (curl, Firefox, whatever). The issue is that the server is telling the clients the cookie expired on Feb 16, 2013 at 12 AM GMT. As such the clients trash the cookie and don't include it when initiating the download of shows. The server expects the cookie and returns an error if it's missing, which is why everything broke today.

Now curl (and browser addons) can send user generated cookies to the server. Meaning it can send cookies it never received from the server. If the TiVo web server software was coded correctly, it would only allow downloads if the value of the SID cookie it receives matches the one it sent, but do to what I can only assume is a bug, it doesn't care if the values don't match. It only cares that there is a value.

As such we can use curl to send a bogus SID cookie to the TiVo web server and it happily allows the download to start. This requires changing a command line parameter sent to curl, which is what kmttg was changed to do now. TiVo Desktop is not sending the parameter to curl and I don't know of any easy way to intercept the call TiVo Desktop makes to curl.exe to inject the parameter. As such the only work around I can think of for TiVo Desktop is to patch either TiVo Desktop to send the command or curl think it received it. Of the two, curl would be easier as it's open source. I'm sure if TiVo doesn't fix this soon, someone will do that.

So we can expect TiVo to get right on that as soon as they run out of third parties to try to blame?