# It's nearly 2012..is TiVoToGo still foiled by stream glitches?



## viggin (Oct 9, 2011)

Hi friends,

I'm trying to pull a 2 hour show from my TiVo using kmttg. The download fails at 49 minutes every time. I've tired also getting the show through the web interface as well, but to no avail.

Searching around I discovered that this is because of a hiccup in the stream as recorded to the TiVo. So I reviewed the file and sure enough...2 frame glitch at 49 minutes 3 seconds.

I do not have another TiVo that I can transfer the show to.

Is there any other known workaround? Is there any way to get TiVo's attention on this? I sent them an email. It looks like this issue has existed for at least!! 3-4 years.


----------



## moyekj (Jan 24, 2006)

Another possible workaround is to record another airing of the program if available.
Another less optimal workaround is record TiVo analog output using a PC video capture card.


----------



## wmcbrine (Aug 2, 2003)

What type of TiVo is it? You could perhaps try a transport-stream-mode transfer, although there are other problems with those.


----------



## Dan203 (Apr 17, 2000)

On the Premiere units they switched to a new Transport Stream based format for TiVoToGo files. The TS muxer is not only faster but seems to be a lot more tolerant of stream glitches and will usually continue transferring beyond the glitch. Although it's still not without issues I've seen some files where the show appears to transfer to completion but after the glitch the file has no audio. So even with the newest technology there is still no guarantee that you'll be able to transfer a program trouble free.

Dan


----------



## gonzotek (Sep 24, 2004)

Since you have the two tivos and can transfer between them, another workaround option is to transfer the first working half of the program to the second tivo, stopping the transfer just before the glitch(that will be the tricky part), then download it from the second tivo to the pc. Then pause the first tivo just after the glitch and transfer that 'from the paused point' on the second tivo, and then download that from the second tivo to the pc. Then join the two halves with a video editor.

/edit: Actually, you might be able to decrypt the first broken half with tivodecode and save some time there.


----------



## Phantom Gremlin (Jun 20, 2002)

gonzotek said:


> Since you have the two tivos


Your technique would work if he had two TiVos, but he says he doesn't:



viggin said:


> I do not have another TiVo that I can transfer the show to.


----------



## gonzotek (Sep 24, 2004)

Phantom Gremlin said:


> Your technique would work if he had two TiVos, but he says he doesn't:


I have no idea how I misread that as "I do have" 
Sorry


----------



## tvhank (Oct 25, 2010)

Dan203 said:


> On the Premiere units they switched to a new Transport Stream based format for TiVoToGo files. The TS muxer is not only faster but seems to be a lot more tolerant of stream glitches and will usually continue transferring beyond the glitch. Although it's still not without issues I've seen some files where the show appears to transfer to completion but after the glitch the file has no audio. So even with the newest technology there is still no guarantee that you'll be able to transfer a program trouble free.
> 
> Dan


How do you remove the wrapper from the TS file and what programs convert the TS file to another file format? Thanks.


----------



## Dan203 (Apr 17, 2000)

The encryption can be removed using the old DirectShow Dump, but to convert it to something over then TS you'll need something that can remux from TS to whatever format you want it to be in.

I don't want this to sound like a plug but VideoReDo can do both. It can open the encrypte .tivo file directly and you can save it to any format we support. (i.e. .mpg, .mp4, .mkv, etc...)

Dan


----------



## opieant (Dec 7, 2006)

If you can't do a transport stream transfer, it's at least possible to start the transfer from after where the interruption takes place instead. I don't think kmttg can do this for you though without some modifications. Several months ago I tried temporarily hardcoding the necessary parameters into kmttg so that "curl" would resume from where a failed transfer left off and it worked okay. It took a bit of fiddling with the offset (starting with the size of the file with the beginning of the recording) to get past the spot the TiVo was choking on, but it worked in the end. The result was one file had the start of the recording, and a second file had the end after where the damage was. Maybe it's worth suggesting some kind of resume support be added to kmttg, or at least support for partial transfers from an offset.


----------



## wmcbrine (Aug 2, 2003)

opieant said:


> If you can't do a transport stream transfer, it's at least possible to start the transfer from after where the interruption takes place instead.


Do tell. I had not been able to make this work when I tried it before.


----------



## opieant (Dec 7, 2006)

wmcbrine said:


> Do tell. I had not been able to make this work when I tried it before.


If you just want to fiddle with the kmttg code like I did, you can add something like the following after the other lines with "command.add(...);" in download.java:


```
//offset: roughly the size of the partial/start file in bytes, probably a bit more to get past the bad spot
long resumeOffset = 2700000000L;
command.add("-C");
command.add(""+resumeOffset);
```
Of course, you'll want to rename your partial download of the beginning of the recording first so you don't overwrite it. 

If you want to use curl directly from a command line, something like the following will work:

```
curl --retry 3 --anyauth --globoff --user tivo:MAK --insecure --cookie-jar cookies.tmp --url "URL" --output OUT -C OFFSET
```
where MAK, URL, OUT, and OFFSET need to be replaced with your MAK, the MPEG-PS download URL from the Now Playing page, the output file name/path, and the offset for resuming (at least the size of the file from the interrupted transfer of the beginning of the recording, probably a bit more).

This only works for program stream transfers unfortunately, at least on S3/HD units. I don't have a Premiere to experiment with so I don't know about it. TiVo's incomplete implementation of TS support on S3/HD units (using Format=video/x-tivo-mpeg&System=ts) chokes on most transfers in the same spot after less than 100 MB (at least on FiOS) even if there aren't any problems with the recording, and those can't be resumed.


----------



## moyekj (Jan 24, 2006)

Didn't work for me. I used:

```
curl.exe --retry 3 --anyauth --globoff --user tivo:MAK --insecure --cookie-jar cookie.tmp --url URL --output OUT -C 2900477107
```
And result was:

```
Exit code: 33
** Resuming transfer from byte position 2900477107
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed

  0    31    0    31    0     0    124      0 --:--:-- --:--:-- --:--:--   124
  0    31    0    31    0     0    124      0 --:--:-- --:--:-- --:--:--     0
  0    51    0     0    0     0      0      0 --:--:-- --:--:-- --:--:--     0
curl: (33) HTTP server doesn't seem to support byte ranges. Cannot resume.
```


----------



## opieant (Dec 7, 2006)

moyekj said:


> Didn't work for me. I used:
> 
> ```
> curl.exe --retry 3 --anyauth --globoff --user tivo:MAK --insecure --cookie-jar cookie.tmp --url URL --output OUT -C 2900477107
> ```


Interesting. I did this on a file reporting 3.08GB size in Now Playing before I posted earlier and had no problems:

```
curl --retry 3 --anyauth --globoff --user tivo:MAK --insecure --cookie-jar cookies.tmp --url "http://192.168.1.2/download/The%20Story%20of%20Mankind.TiVo?Container=%2FNowPlaying&id=2027646&Format=video/x-tivo-mpeg" --output "l:\TEMP.TiVo" -C 2700000000
** Resuming transfer from byte position 2700000000
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
  0    31    0  520M    0     0  1478k      0 --:--:--  0:06:00 --:--:-- 1440k
```
Aside from my MAK, that's exactly what's in the command window.

What TiVo model were you using? Also, were you trying to resume a good recording or a damaged one?


----------



## moyekj (Jan 24, 2006)

opieant said:


> Interesting. I did this on a file reporting 3.08GB size in Now Playing before I posted earlier and had no problems:
> 
> ```
> curl --retry 3 --anyauth --globoff --user tivo:MAK --insecure --cookie-jar cookies.tmp --url "http://192.168.1.2/download/The%20Story%20of%20Mankind.TiVo?Container=%2FNowPlaying&id=2027646&Format=video/x-tivo-mpeg" --output "l:\TEMP.TiVo" -C 2700000000
> ...


I tried resuming a "good" recording - don't have a damaged one that won't transfer.
I tried both with S3 OLED and Premiere models and both gave the exact same error I reported above about server not supporting byte ranges.
My curl version:

```
curl 7.18.0 (i586-pc-mingw32msvc) libcurl/7.18.0 OpenSSL/0.9.7c zlib/1.2.3
Protocols: tftp ftp telnet dict ldap http file https ftps
Features: Largefile NTLM SSL libz
```


----------



## opieant (Dec 7, 2006)

moyekj said:


> I tried resuming a "good" recording - don't have a damaged one that won't transfer.
> I tried both with S3 OLED and Premiere models and both gave the exact same error I reported above about server not supporting byte ranges.
> My curl version:
> 
> ...


Same version of curl here, and I'm currently using a TiVo HD so it should be behaving the same as your S3.

I just ran a few more tests on both HD and SD channels and they were all successful except for the first attempt when I forgot to replace "MAK" with my actual MAK value. When I forgot to fill in the MAK value I received the same error as you, so it looks like curl just reports that the resume operation is failing when something else is really the problem.

First try your transfer from a command line without the parameters for resuming to make sure that isn't the problem, then add those parameters back in if the normal transfer worked okay. Of course, you should make sure your MAK is entered correctly, you have quotes around your URL, and the offset is valid for the file you're trying to transfer.


----------



## moyekj (Jan 24, 2006)

OK, stupid me, I was adding the -C # via kmttg but combined them such that it was ending up as "-C #" for curl which is why it wasn't working. Once you make that mistake then subsequent downloads fail from same TiVo and you have to reboot to fix the server. So after making that mistake I corrected it but subsequent download attempts failed anyway until a reboot. In any case I did get this working now on a couple of different shows from a Premiere. Sounds like a worthy option to add to kmttg for downloads: byte offset

P.S. I did also try specifying byte range using curl -r option, for example:
-r 40000-50000
That unfortunately did not work.


----------



## opieant (Dec 7, 2006)

moyekj said:


> P.S. I did also try specifying byte range using curl -r option, for example:
> -r 40000-50000
> That unfortunately did not work.


Glad to hear you got resuming working. As far as byte ranges are concerned, it should be easy enough to simulate support for that in kmttg by terminating curl after the desired number of bytes have been received.


----------



## Phantom Gremlin (Jun 20, 2002)

moyekj said:


> Sounds like a worthy option to add to kmttg for downloads: byte offset


Wow! I haven't hit this bug, and I do have multiple TiVos so I could work around it. But having a capability like that in kmttg would obviously help a lot of people.

This whole concept of free and open source software is still amazing to me. Contrast with, e.g. TiVo Desktop Plus. Rhetorical question: does anyone think that TD+ would ever add a capability like this? Rhetorical answer: NO!


----------



## moyekj (Jan 24, 2006)

The TiVo web server is very finicky about resume though. If you give an offset that is higher than actual file size or any other kind of problem then it goes into "server busy" mode and you have to reboot to fix. So instead of allowing user to specify a specific byte offset I'm going to have option to resume from current pause point for a show on the TiVo. I think it makes sense to do it that way anyway since one would want to find the point you want to resume from on the TiVo anyway.


----------



## wmcbrine (Aug 2, 2003)

But the pause point is specified in seconds, rather than bytes, is it not?


----------



## moyekj (Jan 24, 2006)

wmcbrine said:


> But the pause point is specified in seconds, rather than bytes, is it not?


 The XML has <ByteOffset> field for shows with pause points (field does not exist otherwise). I've got an implementation in place and it's working very well from a couple of tests I tried. I find a spot towards the end of a show and then exit playback then refresh NPL and then resume download and confirm it picks up exactly where I left the pause point.

Not sure when TiVo added support for this (maybe it was there all along) and if it applies to Series 2 TiVos as well. I think last time I tried this I tried byte range which didn't work which is why I figured it wasn't supported.


----------



## ccrider2 (Nov 1, 2007)

moyekj said:


> The TiVo web server is very finicky about resume though. If you give an offset that is higher than actual file size or any other kind of problem then it goes into "server busy" mode and you have to reboot to fix. So instead of allowing user to specify a specific byte offset I'm going to have option to resume from current pause point for a show on the TiVo. I think it makes sense to do it that way anyway since one would want to find the point you want to resume from on the TiVo anyway.


Running kmttg v0p8l.
Is the option to resume from current pause point incorporated yet?
I've looked and looked, but can't seem to figure out how to make it work.

Excellent idea though!

I have many shows that I only need parts. I'm currently letting the transfer complete to an estimated end point of the desired segment. Then start VideoReDo and save the segment, then Cancel the Job.

So this would be cool to start the transfer at the beginning of the desired segment and then do the VideoReDo thing....real time saver.

Thanks for the wonderful App,


----------



## moyekj (Jan 24, 2006)

ccrider2 said:


> Running kmttg v0p8l.
> Is the option to resume from current pause point incorporated yet?
> I've looked and looked, but can't seem to figure out how to make it work.


 Yes, it's in there.

1. Make sure File->Resume Downloads boolean is enabled
2. Set a pause point for a program on your TiVo
3. Refresh Now Playing List in kmttg (It's important you do this after you set the pause point on TiVo).
4. Begin download and you should see kmttg spit out a message that it is resuming download.


----------



## ccrider2 (Nov 1, 2007)

moyekj said:


> Yes, it's in there.
> 
> 1. Make sure File->Resume Downloads boolean is enabled
> 2. Set a pause point for a program on your TiVo
> ...


Neat. :up: ...I guess I just gotta be led sometimes. 

Thanks moyekj,


----------



## agredon (Jul 26, 2011)

moyekj said:


> Yes, it's in there.
> 
> 1. Make sure File->Resume Downloads boolean is enabled
> 2. Set a pause point for a program on your TiVo
> ...


Resume doesn't seem to work. I tried it on KMTTG and it gave me the same "Doesn't seem to support byte ranges" error others reported with cURL. No surprise since it seems to simply invoke cURL.


----------



## moyekj (Jan 24, 2006)

agredon said:


> Resume doesn't seem to work. I tried it on KMTTG and it gave me the same "Doesn't seem to support byte ranges" error others reported with cURL. No surprise since it seems to simply invoke cURL.


 What model TiVo did you try it on? I know it works for my Premiere units.


----------



## agredon (Jul 26, 2011)

moyekj said:


> What model TiVo did you try it on? I know it works for my Premiere units.


Premiere (Older - Not XL - Model)


----------

