New program for 1 step TTG downloads, decryption, encoding - kmttg

[mlippert]

Originally Posted by cO8W6zlv

My Netgear ReadyNAS started failing to archive TiVo shows earlier this month. It will download 1KB TiVo and .nfo files then fail. I deleted these and retried. Now the ReadyNAS does not "see" the files at all.

I thought I read somewhere that TiVo supports ReadyNAS.

Well, I'm not sure this is the right thread for this question. And I think it might be better said that ReadyNAS supports TiVo rather than the other way around .

The problem on the ReadyNAS (I'm fairly sure) is the expired cookie issue that has been discussed in numerous other threads w/ regards to problems downloading in Tivo Desktop, kmttg and pyTivo. People on the TCF have figured out how to fix those 3 applications.

I am (maybe naively) expecting that eventually (maybe months) TiVo will have an update to the software on the TiVo (hopefully for both the S3s and the Premieres) that fixes the issue.

In the meantime perhaps checking the Netgear ReadyNAS forums (1 thread on topic)?

I have a ReadyNAS myself, but I've been using kmttg to download shows from my Tivo, and recently pyTivo to play shows from my ReadyNAS media share on the Tivo, so I haven't looking into fixing the ReadyNAS connection.

Mike

[wmcbrine]

Originally Posted by mlippert

I am (maybe naively) expecting that eventually (maybe months) TiVo will have an update to the software on the TiVo (hopefully for both the S3s and the Premieres) that fixes the issue.

The most recent terrible official comment from TiVo: "But since our solution is expected to be on the TiVo Desktop PC client and not the DVR itself, the fix should resolve the transfer issue for any platform that works with TiVo Desktop." Um, no, TiVo, you can't fix it in TD, because it's not broken there. You can only work around it in TD. Hence the term "workaround".

[Fofer]

Geez. Who's minding the store over there? Hopefully they'll read here and get the real fix -- the fine folks here are doing their jobs for them!

[unitron]

Originally Posted by wmcbrine

The most recent terrible official comment from TiVo: "But since our solution is expected to be on the TiVo Desktop PC client and not the DVR itself, the fix should resolve the transfer issue for any platform that works with TiVo Desktop." Um, no, TiVo, you can't fix it in TD, because it's not broken there. You can only work around it in TD. Hence the term "workaround".

If they do that, can notting and morac sue for copyright infringement?

[mattack]

Originally Posted by cO8W6zlv

My Netgear ReadyNAS started failing to archive TiVo shows earlier this month. It will download 1KB TiVo and .nfo files then fail. I deleted these and retried. Now the ReadyNAS does not "see" the files at all.

I thought I read somewhere that TiVo supports ReadyNAS.

Even though we know what the workaround is, I suggest you contact Netgear (and possibly point them to the info describing the underlying problem). Since you have an official product you bought, you should try to get support for it, and who knows, maybe they'll prod Tivo.

[wmcbrine]

Originally Posted by unitron

If they do that, can notting and morac sue for copyright infringement?

You're assuming they'd use the same workaround... I'm pointing out that, no matter what they do in TD, it is by its nature a workaround, since the bug is on the TiVo side.

Anyway, no, it's too trivial to be copyrightable.

[windracer]

I'm trying to figure out if I can fix the ToGo code in Galleon in a similar manner to work around the cookie issue. Galleon is using the Apache httpclient libraries in java. I thought it might be as easy as adding:

get.setRequestHeader("Cookie", "sid=abc");

before the execute method, but that doesn't seem to work.

moyekj, I don't know the back-end details of what you're doing in kmttg, obviously, but since it's in java could you give me a hint as to how you implemented your fix so maybe I can apply that to Galleon's code?

Thanks!

[unitron]

Originally Posted by wmcbrine

...
Anyway, no, it's too trivial to be copyrightable.

Oh, so it's only good enough for a patent on the obvious.

[moyekj]

Originally Posted by windracer

I'm trying to figure out if I can fix the ToGo code in Galleon in a similar manner to work around the cookie issue. Galleon is using the Apache httpclient libraries in java. I thought it might be as easy as adding:

get.setRequestHeader("Cookie", "sid=abc");

before the execute method, but that doesn't seem to work.

moyekj, I don't know the back-end details of what you're doing in kmttg, obviously, but since it's in java could you give me a hint as to how you implemented your fix so maybe I can apply that to Galleon's code?

Thanks!

You can take a look at the code online. Relevant file is:
http://code.google.com/p/kmttg/sourc...main/http.java
Look inside "cookieInputStream" method. 1st connection just connects without authentication to grab the cookies. Then a 2nd connection is made with cookies and authentication.

NOTE: I didn't make any changes to this after the expired cookie was discovered. It worked regardless. The workaround was implemented for curl downloads.

[windracer]

Originally Posted by moyekj

You can take a look at the code online. Relevant file is:
http://code.google.com/p/kmttg/sourc...main/http.java
Look inside "cookieInputStream" method. 1st connection just connects without authentication to grab the cookies. Then a 2nd connection is made with cookies and authentication.

Thanks. Looking at my debugging code I might have been looking in the wrong place to begin with, so I'll track down the right place and then see if there's anything I can do.

[dlfl]

Originally Posted by wmcbrine

The most recent terrible official comment from TiVo: "But since our solution is expected to be on the TiVo Desktop PC client and not the DVR itself, the fix should resolve the transfer issue for any platform that works with TiVo Desktop." Um, no, TiVo, you can't fix it in TD, because it's not broken there. You can only work around it in TD. Hence the term "workaround".

This is TiVo's payback for the hundreds of comments on this forum disrespecting TiVo Desktop. If you want to use non-TiVo software for TTG transfers you can darn well do your own fix ... err... workaround.

[howards]

Originally Posted by moyekj

kmttg needs the TSN # to determine if machine is mind enabled, and if it can't get the TSN from Bonjour then it tries to get it from middlemind.tivo.com if you have TiVo username & password specified. If you login to this page do you see your S2 TiVo listed as one of the options?
https://www3.tivo.com/tivo-tco/go.do?def=tco.todo.page
If not then that's probably why.

I'm not sure if S2 TiVos used Bonjour to advertise themselves or not. Perhaps if you let kmttg use TiVo Beacon to detect TiVos for a few minutes your S2 TSN should be found: Configure-Tivos-Detect with TiVo Beacon instead of Bonjour (and make sure "Look for Tivos on network" is enabled). Once the TSN is found it's saved for next session so then those error messages should go away.

The link you posted above took me to a Tivo page had both my series 2s listed but also said:

DVR management is not available on your selected box

We're sorry, DVR management is available only for TiVo-manufactured Series 3/TiVo HD and TiVo Premiere DVRs. If you received your box from your TV service provider, please contact your provider.

I did not have kmttg configured to look for Tivos at all - just hardcoded the IP addresses (I use static IPs so they never change). I did try enabling using Tivo Beacon as you suggested, and just enabling it was enough to get rid of the message about not being able to find the TSN.

Strange that this only occurred with 1 of my 2 Series 2s, but thank you for the fix.

[Call Me Richard]

Originally Posted by cO8W6zlv

My Netgear ReadyNAS started failing to archive TiVo shows earlier this month. It will download 1KB TiVo and .nfo files then fail. I deleted these and retried. Now the ReadyNAS does not "see" the files at all.

I thought I read somewhere that TiVo supports ReadyNAS.

Same thing happened to me. I've reported it to Netgear Support, with a reference to the thread Sudden file transfer failure: kmttg and Tivo Desktop.

Have you reported it to Netgear? I'd like to have some backup here, so they don't think I just some random idiot that doesn't know how to work this!

[wmcbrine]

Originally Posted by dlfl

This is TiVo's payback for the hundreds of comments on this forum disrespecting TiVo Desktop. If you want to use non-TiVo software for TTG transfers you can darn well do your own fix ... err... workaround.

Yeah, well, I did that, and they still haven't. So much for payback.

[unitron]

Originally Posted by wmcbrine

The most recent terrible official comment from TiVo: "But since our solution is expected to be on the TiVo Desktop PC client and not the DVR itself, the fix should resolve the transfer issue for any platform that works with TiVo Desktop." Um, no, TiVo, you can't fix it in TD, because it's not broken there. You can only work around it in TD. Hence the term "workaround".

I'm confused, what are all of these platforms other than the TiVo that work with TiVo Desktop, and how many were adversely affected by the St. TiVo's Day Massacre time bomb, and how, and how is patching Desktop going to fix anything for them?

[philhu]

Originally Posted by wmcbrine

The most recent terrible official comment from TiVo: "But since our solution is expected to be on the TiVo Desktop PC client and not the DVR itself, the fix should resolve the transfer issue for any platform that works with TiVo Desktop." Um, no, TiVo, you can't fix it in TD, because it's not broken there. You can only work around it in TD. Hence the term "workaround".

This is horrible. Tivo has their heads up their a*ses.

<rant on>

They are writing terrible code, with no long term thought to it. Perfect example is ProgramID and the HDGUI using that to get season/episode and SDGUI using EpisodeNum

So, on shows loaded from other than tivos, like from a website, the Tivo will display the sea/eps in the SDgui and not display it in the HDGui

How come every release of software is a new experience in pain for tivo. Fix 3, add 1 and break 4. Have they not heard of regression testing?

And why does the HDGui take 2+ YEARS to finish? And why is it so slow to use? Sometimes PAINFULLY SLOW.

<rant off>

BTW, I still have a series 1, Sony SVR2000 running with lifetime. It's sole purpose in life, for 9 years, has been to record, in analog from the video out of a cable box, the Young and the Restless, for my wife. I've changed cable boxes 3 times, but it still sends IR to the box, and records the composite out

[lpwcomp]

Originally Posted by unitron

I'm confused, what are all of these platforms other than the TiVo that work with TiVo Desktop, and how many were adversely affected by the St. TiVo's Day Massacre time bomb, and how, and how is patching Desktop going to fix anything for them?

I think they are talking about the platforms on which TD runs, i.e. various flavors of Windows.

[wmcbrine]

Originally Posted by lpwcomp

I think they are talking about the platforms on which TD runs, i.e. various flavors of Windows.

...and Mac. Theoretically there's a Mac version. It sucks even more than TD for Windows, but it's there.

[lrhorer]

Originally Posted by wmcbrine

The most recent terrible official comment from TiVo:

<sigh> The proper fix requires replacing less than 10 bytes in the tivoapp code, and they could (should) have had this in place and out the door in a matter of a day, with every TTG capable Tivo on the planet getting an update within a week. Instead they are going to make users upgrade their software in an attempt to implement a kludge.

This is really pathetic. 'Most gripes that come across on these conferences blame TiVo for things of which they are not really culpable or responsible, but this is just a botched job on TiVo's part all the way around.

[lrhorer]

Originally Posted by wmcbrine

...and Mac. Theoretically there's a Mac version. It sucks even more than TD for Windows, but it's there.

Kinda like this bug, actually.

[Fofer]

Sheesh. It's no wonder why the HD UI remains incomplete. My hunch is that all the actual programmers and engineers have left the TiVo building. Maybe a few interns are peeking at the code and trying their best?

[lpwcomp]

Originally Posted by lrhorer

<sigh> The proper fix requires replacing less than 10 bytes in the tivoapp code, and they could (should) have had this in place and out the door in a matter of a day, with every TTG capable Tivo on the planet getting an update within a week. Instead they are going to make users upgrade their software in an attempt to implement a kludge.

I didn't realize you were so intimately familiar with TiVo's s/w change and deployment process.

Should they do this? Yes. Will they do this? No. From their point of view, changing TD addresses the issue and "fixes" the problem for most users. It wouldn't fix it for me if I was still using TD but like most other s/w providers, they don't care about people using unsupported OS's like Win2K nor do they care about third party apps. They might care about the ReadyNAS, but I suspect that even there that they will tell Netgear to change things on their end.

[Fofer]

Originally Posted by lpwcomp

I didn't realize you were so intimately familiar with TiVo's s/w change and deployment process.

I'm pretty familiar with it from an end-user perspective, having had (and supported) many TiVo boxes installed in many homes over the course of a decade.

Their s/w change and deployment process sucks.

[lpwcomp]

Originally Posted by philhu

So, on shows loaded from other than tivos, like from a website, the Tivo will display the sea/eps in the SDgui...

Not really. It just displays whatever is in the episodeNumber field, which mayt or may not be of the form ssee.

Originally Posted by philhu

... and not display it in the HDGui.

If you add the correct programId to the metadata, you can sometimes get season and episode to display in the HDUI.

[lrhorer]

Originally Posted by lpwcomp

I didn't realize you were so intimately familiar with TiVo's s/w change and deployment process.

You mean their internal process, which is to say policy? If internal policies get in the way of proper support, they need to be dumped.

If you mean the pysical deployment mechanism, then yes, I am very familir with it. It's pretty trivial.

If you mean the code requirements, then I am completely familiar with it. I'm considering making the changes to my versions of tivoapp, and not waiting for Tivo. If they follow their published intent, then I almost surely will.

Originally Posted by lpwcomp

Should they do this? Yes. Will they do this? No. From their point of view, changing TD addresses the issue and "fixes" the problem for most users.

No, it doesn't, from anyone's point of view. They have to publish a new version of TDT, which is every bit as difficult and resource consuming as publishing a new version of tivoapp, plus they then have to manually try to get everyone who has an old version of TDT to upgrade, and support all the users who have issues with the transition, perhaps for years to come.

This looks very much like a prime example of what happens when a company allows marketing types to override the good sense of the engineers.

Originally Posted by lpwcomp

It wouldn't fix it for me if I was still using TD but like most other s/w providers, they don't care about people using unsupported OS's like Win2K nor do they care about third party apps.

From their perspectrive, that is not really the point. Again, from their perspective, they can invest a trivial amount of resources to completely fix the issue with no further repercussions regardless of the user or his platform, or they can create a neverending support issue for themselves.

Originally Posted by lpwcomp

They might care about the ReadyNAS, but I suspect that even there that they will tell Netgear to change things on their end.

They might do all sorts of things. That does not make any of them wise or fiscally prudent.

[lrhorer]

Originally Posted by Fofer

I'm pretty familiar with it from an end-user perspective, having had (and supported) many TiVo boxes installed in many homes over the course of a decade.

Their s/w change and deployment process sucks.

In the past they have responded very effectively and quickly to squash bugs. Deployment of new features is not the issue, here.

[unitron]

I'd just like to see an honest explanation from them for why they coded in this time bomb in the first place.

[lpwcomp]

Originally Posted by lrhorer

YIf you mean the pysical deployment mechanism, then yes, I am very familir with it. It's pretty trivial.

I take it then that you either used to work for TiVo in s/w development or have actually spoken or corresponded with someone who does/did. You know for a fact that it is "trivial" to deploy a fix to a single module to every Series2, 3 & 4 platform? Do you know for sure that the mechanisms are even still in place to deploy fixes to Series2 or 3 boxes? Not to mention the fact that if TiVo were actually performing unit, regression, and acceptance testing, even a trivial change would be more complex than you are implying.

Originally Posted by lrhorer

If you mean the code requirements, then I am completely familiar with it. I'm considering making the changes to my versions of tivoapp, and not waiting for Tivo. If they follow their published intent, then I almost surely will.

And what makes this particular approach the "right" one rather than merely the easiest. Simply modifying the expiration date of the cookie is just as much of a kludge as modifying TD.

Originally Posted by lrhorer

No, it doesn't, from anyone's point of view. They have to publish a new version of TDT, which is every bit as difficult and resource consuming as publishing a new version of tivoapp, plus they then have to manually try to get everyone who has an old version of TDT to upgrade, and support all the users who have issues with the transition, perhaps for years to come.

Once again, you know this how?

Originally Posted by lrhorer

This looks very much like a prime example of what happens when a company allows marketing types to override the good sense of the engineers.

No, this looks more like something that was partially but never fully implemented - verifying a transfer request. And the fact that this code was in there got lost in the cracks.

Originally Posted by lrhorer

From their perspectrive, that is not really the point. Again, from their perspective, they can invest a trivial amount of resources to completely fix the issue with no further repercussions regardless of the user or his platform, or they can create a neverending support issue for themselves.

How? Which part of THEY DON'T CARE ABOUT THIRD PARTY APPS! do you not understand?

Originally Posted by lrhorer

They might do all sorts of things. That does not make any of them wise or fiscally prudent.

How exactly is this going to adversely affect their bottom line?

[lpwcomp]

Originally Posted by lrhorer

In the past they have responded very effectively and quickly to squash bugs. Deployment of new features is not the issue, here.

Tell that to the Series1 owners stil waiting for a fix to the DST problem.

[lrhorer]

Originally Posted by lpwcomp

Tell that to the Series1 owners stil waiting for a fix to the DST problem.

They did fix that for most users, and quickly. My Sister's S1 DirecTiVo always has the correct time. So did my Philips SA TiVo, until it died.