Separate names with a comma.
Discussion in 'TiVo Home Media Features & TiVoToGo' started by moyekj, Mar 15, 2008.
I was hoping to use the Network Connect button on the S2.
Edit: I can still use v0p9i for that.
When I said toggle, I meant I checked it, saved the prefs, unchecked it, and saved the prefs.
The download stopped at 2.49GB again. Ugh.
I guess I will see if it's being broadcast again.
Doing that wouldn't change anything. The whole idea was to try download in a different format (TS container instead of mpeg container) to see if that would work. But since you wouldn't have a good way of decrypting it's kind of pointless anyway even if it worked.
v1p0e version just released.
If using version v1p0b or later you can update kmttg automatically to latest release using Help->Update kmttg.
Among some other changes:
* Contains a new Web remote tab which can be used on the new Roamio units to bring up web pages on the Roamio unit using the TiVo internal Opera web browser.
* Adds additional columns to the remote Season Passes table as requested recently.
* Adds Export Channels button to the remote Guide tab to create a channel lineup CSV file containing list of channels currently set as included or excluded in channel list.
Consult release_notes for full details.
I'd appreciate any insight you guys have about this weird problem.
I usually have kmttg set to generate metadata and decrypt the files with tivodecode. (I have VideoRedo TV Suite but I haven't used it very much.)
IIRC this file was transferred with v1p0d. I just updated the tools this morning when I updated to v1p0e, so I'm not sure which version of tivodecode was used when the jobs were run.
I was transferring an episode of So You Think You Can Dance. The show was 2 hours long. The TiVoHD says that the show is 3.09 GB; kmttg reports that the episode is 3.10 GB. Windows Explorer shows 3,057,635 KB for the .tivo file and 3,057,635 KB for the decrypted .mpeg.
So far so good, right?
Before I delete the original recordings from the TiVoHD, I usually do a spot-check by playing the files; I do a cursory check to make sure the start and end of the recordings match, and check a couple of spots in the middle. If the size looks right and the recording time is okay, I cross my fingers that the inside isn't too glitched and delete the original. On the Windows 8 desktop, I usually play the decrypted file with VLC.
VLC is reporting that this episode is 27 minutes and change. The start of the recording looks like the start. The end looks like the end. None of the other files I've transferred recently report strange running times with VLC.
I haven't done a side-by-side test where I play the recording all the way through on the TiVo and the desktop to see what else might vary. I haven't opened up the file in VideoRedo, or moved it to my XP laptop, where TiVo Desktop is installed, or moved it to my Mac.
At the moment VLC is at 2.0.8 Twoflower, but it also showed the weird running time before VLC was upgraded to this version.
I suspect this is NOT a problem with kmttg but with something in VLC. Obviously I'm not going to find the glitch without playing the show all the way through, and I will test the recording with VideoReDo and the other options I mentioned above. But I wanted to post and see if anyone else has seen anything like this before.
murgatroyd, especially seeing as you have VideoRedo you should always run "QS Fix" step to clean up timestamp issues.
Might be worth checking to see what Media Player Classic or Media Player Home Cinema Edition show.
Ran QS Fix and VLC shows 1:59:58 (consistent with other episodes).
Not sure if this is really a KMTTG question, but it affects how I decide to transfer the files.
As far as post processing goes, when using Virtualdub to perform an IVTC conversion from 29.97 to 23.976 files, TS seems to not IVTC as well as the MPG files. There's much more clear usable frames using the traditional transfer/tivodecode to MPEG2 method than forcing Transport Stream and using VideoReDo to decode. Both with QS turned on of course.
Incidentally, neither is as good as just using a capture card at 29.97 -- though why that might be I have no idea. (Of course the quality of the image is worse than the raw files, but the actual un-blended frames are clearer).
Does anyone have any insights or tips on a better settings to achieve a more usable transferred file?
Suggestions on what this nifty new feature could be used for?
Start there and read through the rest of the thread.
It's early days so still exploring. However, since you can design your own HTML5 pages it could become the next-generation HME platform (better if/when TiVo follows through with an SDK). There's a basic proof of concept HTML5 page I posted here for streaming mp4 with H.264 video & AAC audio using custom controls that responds to certain TiVo remote button presses. Note that works on Mini platform as well and doesn't have the HME 1.1GB buffer limitation as it is true streaming. Also being HTML based, for example if you want to stream shows to your TiVo hosted by somebody else's server via internet you could easily do so.
Granted, currently being limited to mp4 with H.264 video & AAC audio doesn't make it very useful as a general streaming solution but if/when TiVo has an SDK that may open up more possibilities.
I actually came to ask just that. I'm trying to store a new season of a TV show I haven't caught up with on my PC until I'm ready to watch but episode 1 is cutting off after transferring 200MB. I'll try a TS download. I can still send that back to my Tivo using PyTivo, right?
I'm wondering if anyone can help me out with the encoding profiles supplied with KMTTG. I primarily use the program in conjunction with PyTivo to remove files from my Tivo to save space and then transfer them back when I'm ready to watch. I also encode them using the ff_ipad profile to take with me if I'm traveling. Simply downloading and decrypting is sufficient for my purposes, but I would like to have the option to encode into an mp4 of smaller file size. I have a few questions:
1) What's the difference between the ff_264_high_rate profile and the ff_tivo_hd profile? They seem identical to me.
2) I've encoded 1 episode of a show using the ff_tivo_hd profile and everything seemed to work fine, however when I try to play it on my computer I get "Error 2041 - an invalid sample description...." When I try to transfer this file using PyTivo the transfer appears to work fine, but the file never shows up on my Tivo (I can post a PyTivo log if necessary). I have no issue transferring mpg files using PyTivo and no issue transferring mp4 files encoded using the ff_ipad profile.
1) They are very similar but not identical - slightly different encoding params.
It's likely the player you are using on PC can't handle mp4 container with AC3 audio. If you play it with VLC VideoLAN it should play fine.
Are you transferring using push or pull? If using pull method then unless you configured pyTivo for ts=on it will re-encode to mpeg2 when transferring which is not something you want. So either use pull method with ts=on config or use push to transfer to your TiVo, so that either way there is no transcoding back to mpeg2 happening.
1) Is one better than the other to use? I'd like to use the best profile to maintain good fidelity with HD content.
2) I downloaded VLC player and the file plays fine. Thanks.
I'm not sure how you configure for ts=on, but I transferred using push. The file appears to transfer to completion after ~13 minutes (I get the "done transferring" message with bytes transferred and average transfer rate) and a few seconds later another transfer of the same file starts. This transfer appears to finish after ~1 minute and I get the "done transferring" message that tells me that 0 bytes were transferred at 0.00mbps and there is no file on my Tivo or in my recently deleted folder. I can see the file on my Tivo during the initial transfer, but if I try to play it while it's transferring I just get a blank screen or a frozen image of live tv. I have no issues with mpg files or mp4 files encoded using ff_ipad.
I know I asked almost this same thing before, and you said along the lines of "tivo to tivo transfers do direct byte transfers"..
But more specifically, does nobody know exactly how Tivos transfer *between* them? Or because the curl method works most of the time, did nobody bother to implement the alternative method? (I'm not meaning to imply laziness.)
I now have a couple of recordings I'd like to keep the *end* of, but because of glitches, can't transfer them. I may end up being able to transfer them to my TivoHD, then transfer the end.. But I'm somewhat seriously consolidating into one 6 tuner Roamio.. so *a* solution to this would be good at some point.
Is there any info about the tivo to tivo transfer, and how it differs from what kmttg does?
(i.e. why it succeeds even with glitchy programs)
TTG transfers are quite CPU intensive because they require decrypt/demux/remux/encrypt and some glitches in the recording probably break the demux/remux parts. You can emulate an MRV transfer to your PC by adding the following formatting to the URL (which is what MRV transfers between 2 TiVos uses):
Don't know for sure but it's likely with that format you are avoiding at least demux/remux if not decrypt/encrypt as well, so glitches in the recording won't affect anything. You can probably try the above and see that transfer to your computer will succeed in that format, but it's academic because good luck figuring out how to decrypt the resulting file...
I need help! I'm trying to use kmttg to transfer from my S3's to my new Roamios, but when I try to start the service I get the error: [SC] StartService: OpenService FAILED 5:
Access is denied.
Any help will be greatly appreciated.
Read the auto_transfers Wiki which covers that situation. If on Windows 7 or higher with UAC enabled you will likely need to set javaw.exe to run as Administrator to be able to install the service.