The clock is wrong because it's right!

Advertisements

I'm having the same problem on my Mac OSX 10.7.5 Lion. Everything was working fine until last week. I changed the date to Feb 15 on my Mac and now I'm able to download. It must be due to iTivo itself and not the operating system. Thanks for the suggestion. What a relief!

 

Neither -- it's the TiVo. iTivo is behaving correctly.

Don't change the system date; try this:

http://www.tivocommunity.com/tivo-vb/showthread.php?p=9527390#post9527390

 

Since it's affecting my S3 OLED apparently this issue has been present for a while (and someone reported it with an S2)?

Scott

 

As far as I can tell by googling for HTTP logs from Tivos, that cookie expiry date has been hardcoded to this for TTG transfers ever since they introduced the feature in 2005, from S2 all the way up to recent Premieres.

As to why they decided to use a hardcoded date in February 2013... I couldn't tell you.

 

Advertisements

Maybe back then, TiVo didn't have faith that they would still be in business in 2013.

 

Speaking of which, the next "doomsday" date is December 2016. That's when the SSL certificate on the Series 3 boxes expires. I don't have a S2 to test with, but I'm guessing that expires sooner.

 

There's also client side PKCS12 certificates for iOS/Android software set to expire 2/14/2014. Haven't checked recent versions to see if they have extended that expiration date. Maybe this time next year we'll have a new iOS/Android crisis on hand...

 

Series 2 cert expires January 9, 2015, at least on the one I have. Of course, 3rd-party client software (and even Tivo Desktop itself presumably, considering it's a curl commandline option) can easily be configured to ignore an expired cert in much the same way it works around the cookie problem.

 

SSL is only used to grab the show listings. The actual transfer is not encrypted. I don't think TD uses curl to grab the listing data as such it will probably fail without any way of fixing it. The SSL certificate isn't technically valid since it has no CA so 3rd-party software already likely ignores it.

 

That's easy enough to update assuming TiVo doesn't shut down their app development before next year.

 

I've seen notting's proof that the date is hardcoded, and has been for many years (probably since the beginning). So just to nail the coffin on this thing, I thought I'd grep my copy of an old tivoapp (11.0b) for the string, in case it was there in plain text. They wouldn't do that, right? Yeah, they would:

Code:

Set-Cookie: sid=%s; path=/; expires="Saturday, 16-Feb-2013 00:00:00 GMT";

On the plus side, this means it should be easy to patch on a hacked TiVo.

 

I've been trying to fix this problem for almost 2 hrs now, lucky I came across this thread. So, basically, every time I want to transfer and file I have to set the date back to the 13th from now on??

 

Whar happens if you don't have a curl.conf file?

I think I deleted it yesterday when I was trying to fix this ridiculous problem....

Even after a reinstall I don't seem to have one. Can I create one or download one?

Thanks, JW

 

Cool. Thanks.

 

Why not just download the one Unitron was nice enough to post in the link he provided?

 

If you are sure you are looking in the right place and can't find it, just create one. If it doesn't fix the problem, it means you didn't put it in the correct folder.