The MAK is the media access key - it is a number unique to your account that is used to encrypt your recordings. KMTTG (actually TivoDecode) needs this value to decrypt the video it downloads. The MAK is available either at your tivo.com account or from the tivo itself, I believe under "Messages and Settings/Media Access Key".

If you have multiple tivos on your account, all of them will have the same MAK.

...The first time you bring up this window you will need to set the proper value for Total Disk Space (GB) field at the top of the window.

What is the size in GB? I have the TiVo that is 45 hours (not the larger 120 hours)...

I'm curious about this too. I'm guessing it is the size of the media partitions, but not knowing the sizes of the system partition(s) makes it hard to determine if you know the drives capacities, which should be easily found by going to the manufacture's websites. Are the sizes of the various TiVo model's system partitions documented anywhere?

Thank you. I tried it and the 2 minute timeout solves the problem I was having. When that was solved, I started having another problem but I haven't been able to put my finger on it. Not sure if it was autotune, my TiVos, or something else, but I was getting errors with my downloads part of the time. I'll report if I narrow anything down.

Forgive the delay, I was busy and just now got back to this. My experience with the Java downloads is probably not what was hoped. While the java downloads do seem to work at times, they also abort sometimes. They do not stall like the curl downloads do (they die immediately), but when the java downloads abort, they often leave the TiVo in a state that no longer allows any new downloads to be started. Restarting kmttg doesn't help with this. I have to reboot the TiVo in order to get downloads working again.

So, for the time being, I have switched back to using the curl downloads. I have a recompiled kmttg with custom curl parameters so curl can detect stalls and exit, allowing kmttg to retry. This is still the only solution I have yet found that allows kmttg to at least continue functioning rather than becoming stuck until get it moving again. I am not sure on the status of curl itself being the problem or it being something else. The fact that java downloads also seem to abort would seem to contradict the theory that it was only a curl problem.

Has anyone else come up with a better solution for the now over a month old curl stalling issue?

ferror, is that THD units that you have trouble with? I had 2 S3 OLED units for years and now have a Premiere and 1 S3 OLED and have never been able to reproduce the download issues - my downloads are very reliable no matter which method I use (lately I've been using exclusively the Java download method which is slightly faster than curl for some reason). Since I can't reproduce the problem I can't really help much. What is the error spit out with Java download? Perhaps it can be setup as something to ignore since I have more control over Java downloads than with curl.

Forgive the delay, I was busy and just now got back to this. My experience with the Java downloads is probably not what was hoped. While the java downloads do seem to work at times, they also abort sometimes. They do not stall like the curl downloads do (they die immediately), but when the java downloads abort, they often leave the TiVo in a state that no longer allows any new downloads to be started. Restarting kmttg doesn't help with this. I have to reboot the TiVo in order to get downloads working again.

So, for the time being, I have switched back to using the curl downloads. I have a recompiled kmttg with custom curl parameters so curl can detect stalls and exit, allowing kmttg to retry. This is still the only solution I have yet found that allows kmttg to at least continue functioning rather than becoming stuck until get it moving again. I am not sure on the status of curl itself being the problem or it being something else. The fact that java downloads also seem to abort would seem to contradict the theory that it was only a curl problem.

Has anyone else come up with a better solution for the now over a month old curl stalling issue?

This might not be in any way related, but I figure I would throw it out there. I have pyTivo running on my NAS and I typically use that for downloads (so the PC doesn't have to be on while the downloads take forever).

I ran into a problem at one point when pyTivo added download queues. It seemed that pyTivo was "overwhelming" the Tivo HD webserver, with requests too frequently, which caused it to stop responding to web requests until a reboot. This was fixed by adding in a delay between the individual requests (it was incorporated by wmcbrine).

Now here is the some of the strange stuff: This problem varied by user/box and what was tuned. It was actually (believe it or not) more apt to happen when the tuners were idle. I happened less frequently when the tuners were in use, leading me to believe the web server was responding when the rest of the system was not ready.

Different TiVo HD boxes exhibited different behavior, the only real difference being the installed hard drive. One with stock hard drive had the problem 100% of the time while one with an upgraded drive was infrequent. A friend who had a different upgraded drive than myself actually had the problem 100% as well.

In the end, the delays fixed the problem for pyTivo, but it did lead me to believe that there are apparently timing differences between boxes especially with different hard drives.

I think it would be interesting to see what the tuner configurations are when curl has a hiccup. Maybe tuners being idle is bad for your particular unit or there is something strange going on with the drive.

I realize this is a FAQ, but will this or any of the other Tivo download programs (that work on a Mac) let me download the ORIGINAL file (only tivodecode-d, not modified otherwise) AND create an audio version in one step?

Seems like many of them let me choose the 'output type', but for various programs, I'd like to do both in one step (at least on my end user point of view).. perhaps even putting them in separate directories, but that's probably not necessary.

(I have lately been essentially creating podcasts of various TV shows that I realize I get 90+% of the content by just listening, esp at 2x on my phone! Various news/documentary shows, and a zillion lettermans I have saved up.)

ferror, is that THD units that you have trouble with? I had 2 S3 OLED units for years and now have a Premiere and 1 S3 OLED and have never been able to reproduce the download issues - my downloads are very reliable no matter which method I use (lately I've been using exclusively the Java download method which is slightly faster than curl for some reason). Since I can't reproduce the problem I can't really help much. What is the error spit out with Java download? Perhaps it can be setup as something to ignore since I have more control over Java downloads than with curl.

I am running two THDs. One of them is running an original drive with a 500GB DVR Expander. It is generally used for extra tuners (and just viewing sports, etc.) when the other unit is busy. The second unit has a 1TB upgraded internal drive, and a 1TB DVR expander married to it. I tried a Premiere for a few months, but decided to sell it. The HDUI was too slow to use and the downloads actually caused reboots and lockups on the Premiere. My guess is that TiVo has their hands way too full right now to deal with fixing bugs that only impact a tiny segment of users. When I made the decision to sell the Premiere, the THDs were working perfectly. So, unfortunately this new problem crept in shortly after that.

Quote:

Originally Posted by vectorcatch

..snip..
In the end, the delays fixed the problem for pyTivo, but it did lead me to believe that there are apparently timing differences between boxes especially with different hard drives.

I think it would be interesting to see what the tuner configurations are when curl has a hiccup. Maybe tuners being idle is bad for your particular unit or there is something strange going on with the drive.

It is interesting that you mention the idle tuners issue because when I tried the autotune feature for a short time, I actually did notice more problems with downloading than usual. What actually made me turn off autotune, however, was the fact that it would take me out of a show in the middle. I often leave shows paused for awhile and come back to find it jumped out, or worse I jumped out while watching. Autotune is a neat idea, but it is too bad the TiVo interface only works in the foreground, as if the remote control is being used, rather than just changing the channels in the background. Thanks for pointing out the timing issue. I will start watching what the tuners are doing a bit more closely to see if there is any correlation.

The average download speeds from the THD are fast enough to allow kmttg to keep up as long as I don't fall way behind. So, I am going for more stability and less speed right now. At the moment, I am not getting the error with java downloads at all, but earlier it was happening constantly. If I see the error again, I will capture it and post it here.

When i have KMTTG downloading a HD movie file (say Spiderman for example), the .tivo file is 8gb & when KMTTG converts it to a .mpg file, it stays at the exact same 8gb size.

Is there a way to compress the file size & keep the quality? I am using the default settings & its set to ff_h264_high_rate.

Is there another program that will shrink the file size more? I tried using AVS video converter but that seems to shrink the file down to 1gb & the quality was terrible.

Any ideas?

THanks,
RIch

You need to enable the "encode" task to encode to a different format (and potentially shrink file size). It's impossible to encode to any size and preserve full quality - encoding is a lossy process no matter how you do it.

You need to enable the "encode" task to encode to a different format (and potentially shrink file size). It's impossible to encode to any size and preserve full quality - encoding is a lossy process no matter how you do it.

Yes, this is true. However, he may be only talking about visual quality and not bit-for-bit exact. You can probably get ~50% size savings with ffmpeg/handbrake encoding to h.264 codec that will be very difficult to visually notice a quality difference.

BTW, I built a handbrake profile for kmttg for another user that should inverse telecine FILM based material (not good for European material) and encode with constant quality rather than a fixed bitrate. I haven't done more than simple testing with it myself. I used CRF=21 which I find good for HD material, but I would recommend using CRF=19 for SD. Attached if you are interested.

update: Now that I think about how Handbrake works again, I don't think feeding it European material will in itself be a problem. Handbrake is smart enough to detect the pullup pattern. It simply cannot remove any blends created during the PAL-->NTSC conversion.

Thanks for the help guys! I watching movies with my son on the Tivo premiere. The quality doesnt need to be perfect for my viewing.

I looked at the attachment, does that encode in the mp4 format vs the mpg?

Should I just remove the .txt & pop it into the KMTTG directory? Do I do anything else to make it work? Is there something I can use on the other Mpgs?

Thanks,
Rich

Rich, it will encode to mp4 container using the h.264 codec. You can remove the .txt and add it to the encode directory in kmttg. You can use it on any mpg most likely. Kevin already has some other options in kmttg for ffmpeg or handbrake encoding profiles (ff_tivo_hd/sd or hb_tivo_hd/sd). You may want to stick with one of those until Kevin blesses off my profile. I haven't really done much testing with it since I encode my videos with a different method, but my limited testing showed it worked ok.

I am trying to encode some videos using ffmpeg, for some reason I am getting no audio. If I select one of the handbrake options it works. Ultimately I want the tivo_sd profile.

My guess is you ARE getting audio but the player you are using to play it back can't play videos containing AC3 audio in MP4 container. Note that those do play back if you push the videos to TiVo or if you use a player such as VLC Videolan.
(The handbrake profiles are all using AAC audio which most players have no problem handling which is why you get audio for those with your player).

My guess is you ARE getting audio but the player you are using to play it back can't play videos containing AC3 audio in MP4 container. Note that those do play back if you push the videos to TiVo or if you use a player such as VLC Videolan.
(The handbrake profiles are all using AAC audio which most players have no problem handling which is why you get audio for those with your player).

I am not getting audio on the Tivo either.

__________________
Wondering when the next trip to To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. will be ?

Are you pushing to TiVo using pyTivo (not pulling)? medianfo is a good tool to use to examine the contents of a video file - lists audio and video details which can then easily determine if there is actually an audio stream in your mp4 file. Post the mediainfo information for your mp4 file here if it's not clear what you are looking at.

Are you pushing to TiVo using pyTivo (not pulling)? medianfo is a good tool to use to examine the contents of a video file - lists audio and video details which can then easily determine if there is actually an audio stream in your mp4 file. Post the mediainfo information for your mp4 file here if it's not clear what you are looking at.

I am pulling the video using tivo desktop. I'll check out media info and report back.

__________________
Wondering when the next trip to To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. will be ?

I am pulling the video using tivo desktop. I'll check out media info and report back.

That explains it. Whenever you pull a video it always transcodes non-mpeg2 video to mpeg2 on the fly. TiVo Desktop can't handle doing that transcode on the fly properly for mp4 files with AC3 audio. The best option is to use pyTivo and do a push, which then avoids having to transcode back to mpeg2 (and associated further quality hit) and transfers much quicker as well.
Another option is to use streambaby to stream the file to your TiVo instead of a pyTivo push.

You will find mediainfo will show you have AC3 audio and VLC player will be able to play it back with audio on your PC.

That explains it. Whenever you pull a video it always transcodes non-mpeg2 video to mpeg2 on the fly. TiVo Desktop can't handle doing that transcode on the fly properly for mp4 files with AC3 audio. The best option is to use pyTivo and do a push, which then avoids having to transcode back to mpeg2 (and associated further quality hit) and transfers much quicker as well.
Another option is to use streambaby to stream the file to your TiVo instead of a pyTivo push.

You will find mediainfo will show you have AC3 audio and VLC player will be able to play it back with audio on your PC.

For Pytivo do I need pytivo and pytivo push? I tried streambaby and was unsatisfied with the results. Not sure if my comptuer or my network is too slow but I got lots of pauses.

__________________
Wondering when the next trip to To view links or images in signatures your post count must be 10 or greater. You currently have 0 posts. will be ?

I have a hockey game on my tivo that was recorded off of NHLHD. In its raw state, it was in excess of 14GB. I transferred it to my PC and ran it through VRD - both to qsf it and to remove commercials (it was transferred/decrypted with KMTTG). I then used kmttg to encode it to mp4 using the ff_tivo_hd profile - it took 13 hours (when I transcode with VRD, it takes about 4.5 hours - still a big number, but significantly less). The resulting file was playable on my PC (VLC) but could not be pushed with pytivo because of it size - 5.5GB - I had to use qtfaststart to rearrange the atoms before it became pushable.

Now it pushes fine, and transfers in a reasonable amount of time, but the video quality is horrible - it has a "strobe" effect that is quite disconcerting to watch. I can pull it to my tivo, and the transcode quality is just fine, but it again takes about 13 hours to transcode.

I haven't yet tried pushing the VRD encoded version of the file to see how that does, but until I do, I was wondering if anyone has a possible explanation for the poor video quality and long encode times.

For Pytivo do I need pytivo and pytivo push? I tried streambaby and was unsatisfied with the results. Not sure if my comptuer or my network is too slow but I got lots of pauses.

Don't understand the question. Once you have pyTivo installed it has the capability to do pushes after you configure it with your tivo.com login & password. You can then initiate the push from pyTivo web page or from kmttg after you set things up correctly. Visit pyTivo thread or pyTivo forums for more details on setting up pyTivo for pushes.

I have a hockey game on my tivo that was recorded off of NHLHD. In its raw state, it was in excess of 14GB. I transferred it to my PC and ran it through VRD - both to qsf it and to remove commercials (it was transferred/decrypted with KMTTG). I then used kmttg to encode it to mp4 using the ff_tivo_hd profile - it took 13 hours (when I transcode with VRD, it takes about 4.5 hours - still a big number, but significantly less). The resulting file was playable on my PC (VLC) but could not be pushed with pytivo because of it size - 5.5GB - I had to use qtfaststart to rearrange the atoms before it became pushable.

Now it pushes fine, and transfers in a reasonable amount of time, but the video quality is horrible - it has a "strobe" effect that is quite disconcerting to watch. I can pull it to my tivo, and the transcode quality is just fine, but it again takes about 13 hours to transcode.

I haven't yet tried pushing the VRD encoded version of the file to see how that does, but until I do, I was wondering if anyone has a possible explanation for the poor video quality and long encode times.

What TiVo model do you have? The original S3 OLED models are pretty bad at H.264 playback compared to Premiere. I'm not sure about THD units as I never owned one. How is playback on the PC? If it is OK there then it suggests the TiVo decoder is the problem.
As far as long encoding times it's not surprising - H.264 encoding is very compute intensive and ff_tivo_hd profile is setup to use a pretty high bit rate and your source file is HD. Not sure which profile you used for VRD, but if you used MP4 File (Generic) then note that you will get 2 channel AAC audio. There's a special non-standard VRD profile that can be used if you want AC3 audio, but after generating it you won't be able to open it in VRD (hence why it's not officially released).

I'm getting an increasing number of videos that can't be played on my tivo or even with VLC. It doesn't matter what profile I use. The hard drive on my tivo was failing. I thought that might be the cause, videos with errors.

Problem still occurs with shows recorded on my new drive. Time to troubleshoot.

Bad files always give me an error with atomic parsley. I'm not sure if atomic parsley is corrupting the files (cause of the problem) or if the error is letting me know there is a problem with the file. Problem seems to occur more often with larger videos (over 4 Gig output file).