Thanks moyekj. It's definitely VRD that is crashing. It happens within moments (1st frame), and the dialog info is the same as above. I tried running it standalone with the dimension filter applied, and also through kmttg with the filter applied. All results are the same.

Thanks moyekj. It's definitely VRD that is crashing. It happens within moments (1st frame), and the dialog info is the same as above. I tried running it standalone with the dimension filter applied, and also through kmttg with the filter applied. All results are the same.

For reporting VRD crashes your best bet is the VRD Forums and uploading a sample for VRD folks to take a look.

I have Kmttg set this way. The tivo files goes in a folder that is named to be deleted. I have the MPG files going to a folder named for Videoredo auto processor. In the configuration it is set to delete the tivo files. I use the Kmttg help to do the updates. With Kmttg v1pOp it not encoding the tivo files to mpg but it not deleting the tivo files.
What could be the problem with this now? The only thing I changed was the use RPC to get the NPL when possible.

I believe that all of these requirements are being met. I have two .m4v files (show.m4v and show_iPod.m4v) and two .m4v.txt files (show.m4v.txt and show_iPod.m4v.txt), but after the two encodes are completed, Atomic Parsley is only run on show.m4v. No error messages are displayed, and I can manually run Atomic Parsley on the show_iPod.m4v file after the run without problems.

I tracked down the problem preventing 2nd Atomic run and it is fixed in next release. Associated with this problem, atomic jobs were unnecessarily being queued behind other jobs, but now they launch right away without waiting for other jobs to complete.

I have Kmttg set this way. The tivo files goes in a folder that is named to be deleted. I have the MPG files going to a folder named for Videoredo auto processor. In the configuration it is set to delete the tivo files. I use the Kmttg help to do the updates. With Kmttg v1pOp it not encoding the tivo files to mpg but it not deleting the tivo files.
What could be the problem with this now? The only thing I changed was the use RPC to get the NPL when possible.

Don't understand what you wrote. Please clarify your post and include any kmttg log messages.

I tracked down the problem preventing 2nd Atomic run and it is fixed in next release. Associated with this problem, atomic jobs were unnecessarily being queued behind other jobs, but now they launch right away without waiting for other jobs to complete.

Awesome! Thanks for looking into this. I'll look forward to checking out the next release.

With the semi-frequent C133 error problem lately, I noticed that the RPC connection doesn't work when in that situation.

Could kmttg fall back to the non-RPC method if it gets an error? That way it would "just work" even in the situations where Tivo can't keep their !@#$ servers running, and we wouldn't have to change our prefs back and forth..

With the semi-frequent C133 error problem lately, I noticed that the RPC connection doesn't work when in that situation.

Could kmttg fall back to the non-RPC method if it gets an error? That way it would "just work" even in the situations where Tivo can't keep their !@#$ servers running, and we wouldn't have to change our prefs back and forth..

That's odd, for series 4 and later units I didn't think MyShows listings were affected. Things like Guide and Search used to be affected. Recently, however I changed the RPC calls related to MyShows so it's possible something was affected, though I wasn't having problems last night. If you still have associated error message can you post it here?

With the semi-frequent C133 error problem lately, I noticed that the RPC connection doesn't work when in that situation.

Could kmttg fall back to the non-RPC method if it gets an error? That way it would "just work" even in the situations where Tivo can't keep their !@#$ servers running, and we wouldn't have to change our prefs back and forth..

That's odd, for series 4 and later units I didn't think MyShows listings were affected. middlemind server is not used directly for MyShows retrieval, though it's possible indirectly the TiVo relies on servers for some of that information. Things like Guide and Search used to be affected since they do use middlemind servers indirectly. Recently, however I changed the RPC calls related to MyShows so it's possible something was affected, though I wasn't having problems last night. If you still have associated error message can you post it here?

Sorry, I knew I should have kept it.. I don't suppose it keeps the log?

I'll post it the next time I see it. (Also, I did have a couple of other java errors trying something else during the C133 time, but I didn't figure out reproducible steps for that part -- it was AFTER this part I was able to repro though.)

I don't seem to be having networking problems at the moment, but RPC is failing on my Roamio, but succeeding on my Premiere 4.. one's sitting on the other, connected to the same switch that my laptop is.. I'm fairly sure this is the kind of error I was seeing last night too:

I don't seem to be having networking problems at the moment, but RPC is failing on my Roamio, but succeeding on my Premiere 4.. one's sitting on the other, connected to the same switch that my laptop is.. I'm fairly sure this is the kind of error I was seeing last night too:

and remember, the old style connection is working and I already downloaded a bunch of recordings (making room for more Olympics).

That's interesting - the above failure seems to be because you have 1 or more shows that don't have a title for some reason which I didn't think was possible. That failure is at a point beyond which all RPC data is already collected for a show and kmttg is just trying to find/construct the URLs needed for metadata and download.
Try the kmttg.jar in this zip file which accounts for that possibility and I think should solve your issue:https://drive.google.com/file/d/0B0S...it?usp=sharing

Quote:

Originally Posted by pdc

Awesome! Thanks for looking into this. I'll look forward to checking out the next release.

pdc, above kmttg.jar has the atomic related fix in it too if you want to test it out.

Series 3 units don't support H.264 cable channel recordings (in TS container). If you REALLY want to transfer to your HD unit you will need to remux to use mp4 container instead of mpeg2 TS container and then PUSH back to your HD using pyTivo. Since that requires decrypting and you can't use tivodecode on H.264, only something like VideoRedo TVSuite will work to do that.

You should be able to pull H.264 .TiVo files (in TS container) back to your Roamio using latest TiVo Desktop or recent pyTivo.

Thanks for the quick reply. For this particular program, I don't REALLY want to go to that much effort. Maybe in the future.

I would like to figure out why the program won't transfer back to the Roamio via pyTivo. It is marked with a red X and says "Transferring prohibited by the copyright holder." and a duration of 0:00. Other (non h.264) files in the share transfer fine.

I set up TiVo desktop and pointed it to the same share. It's transferring now and I get video and audio on the Roamio.

I must have something set up wrong with pyTivo. I just installed it today. Not sure which version it is, but it is the wmcbrine fork. kmttg is v1p0p. TiVo desktop is 2.8.3.

I could just use TiVo desktop, but I would like to get pyTiVo working.

Should post in pyTivo thread for pyTivo help, but 1st thing I would suspect is what ffmpeg.exe you are pointing pyTivo configuration to - you should use a recent version. (pyTivo uses ffmpeg to analyze video files including .TiVo files, and is probably not able to read the H.264 .TiVo file properly).

I tried 3 different ffmpeg files (one "older build of FFmpeg known to work well with pyTivo" I downloaded today, one that came with kmttg dated December, and the latest from zeranoe I got tonight), using either the Restart or Shutdown buttons from the pyTivo browser settings page after each change. No luck. Then I shut down everything and restarted from pyTivo.py and now it's working like it's supposed to. Yay! It's possible one of the other ffmpeg files might also work, but I'm not that curious tonight.

Interestingly, even the TiVoHD will let me try to transfer the file now, but the blue light only flashes for a second before it gives up.

I am using version V1P0K and since I upgraded from Win 7 to Win 8.1 (and installed this version of KMTTG), my downlaods that are loaded to my iPad have the video and audio out of sync. They usually start a second out of sync but by the end of an hour show, they are close to 20+ seconds out of sync. I have used the encode profile "me_ipad" for a few years and so I retried them with the "ff_ipad" encode profile and it still does the same thing.
Is it the version of KMTTG I have or is it the encode profile? I need help, the downloads are unusable at this point.

Interestingly, even the TiVoHD will let me try to transfer the file now, but the blue light only flashes for a second before it gives up.

That's because they are encrypted. When an h.264 video is being transferred to any TiVo series 3 or earlier, it must be transcoded to MPEG2. If it is encrypted, it must first be decrypted. pyTivo uses tivodecode to decrypt, and it cannot decrypt h.264.

I am using version V1P0K and since I upgraded from Win 7 to Win 8.1 (and installed this version of KMTTG), my downlaods that are loaded to my iPad have the video and audio out of sync. They usually start a second out of sync but by the end of an hour show, they are close to 20+ seconds out of sync. I have used the encode profile "me_ipad" for a few years and so I retried them with the "ff_ipad" encode profile and it still does the same thing.
Is it the version of KMTTG I have or is it the encode profile? I need help, the downloads are unusable at this point.

You need to enable "QS Fix" task as part of your flow. Best option is to configure kmttg with VideoRedo which it will then use for QS Fix, but short of that kmttg will use ProjectX for that task instead.

After transferring files with kmttg, I generally do a quick check of the mpeg file outputted by kmttg to make sure the entire recording was transferred before I delete the original file from my TiVo. Usually this means opening the qsfixed mpeg file with VLC and checking a couple of points in the recording to see that it looks okay, and comparing the scenes at the very end to make sure the file wasn't truncated.

I transferred the Opening Ceremony of the current Winter Olympics (with padding, the duration was 4:07). The file size reported by my TiVoHD is 6.16 GB.

kmttg's display of the NP List agrees with what the TiVo says, reporting a running time of 4:07 and a size of 6.16 GB.

I opened the file with VLC (2.1.3 Rincewind); the running time of the recording is 41:38.

I said "oh, crap, another glitched recording" and examined the file with the explorer in Windows. The file size reported is 5.81 GB (6,247,352,320 bytes) and the running time 04:07:23.

I had recently installed the K-Lite Codec pack and Media Player Classic (1.7.1.247 (f520e2b) from December 18th last year) so I tried that next. MPC displays the running time of 04:07:23.

This is on my Win8 desktop which has VRD TS 3.20.629 installed, but not TiVo Desktop. (IIRC I had installed the Codec Pack to make up for the lack of TiVo Desktop.) I am only using VRD TS for QS Fix at the moment; I haven't used it for editing.

So my questions are:

1) Is this expected? That is, as long as the MPC can display the entire recording, and W8 and MPC agree on the running time, should I care what W8 tells me about the file size? How much variation should I expect? (I realize this is an artifact of how the different OSes report the file size.)

2) Which media players are generally the most robust? (I'm okay with using MPC if I have to, but if there are better players out there, I'd like to know.)

3) Do I need anything else to edit with VideoRedo TS if I don't have TiVo Desktop Plus installed? Because I expect I'll need to edit down some of these recordings real soon now.

I'll go back and read the thread, but if there are things that I can't do with VRD TS because I don't have TiVo Desktop Plus installed, I'd appreciate a pointer to the appropriate thread or a recap. (My previous desktop's hard drive is comatose, and I've been too lazy/busy to call TiVo about retrieving the key for TiVoDesktop Plus for that install; it's old enough that the information is not online.)

Sorry for the off-topic parts of this post, but I wanted to post a caution because I thought at first there might have been an issue with kmttg not transferring the entire recordings. But if MPC can play the file, I guess that kmttg worked fine and the problem is with VLC. If I'm overlooking something or you have other troubleshooting tips, please let me know. Thanks.

P.S. keeping kmttg up to date is so easy now. It's really a pleasure to use, and keeps getting better and better.

__________________
"The capacity of human beings to disappoint me is never ending." -- Ereth

You need to enable "QS Fix" task as part of your flow. Best option is to configure kmttg with VideoRedo which it will then use for QS Fix, but short of that kmttg will use ProjectX for that task instead.

OK. I have never used QS Fix or VideoRedo before (and have been using kmttg for this same process for almost 2 years). Why would this have changed and what is QS Fix doing that it will fix an audio/video mismatch?

OK. I have never used QS Fix or VideoRedo before (and have been using kmttg for this same process for almost 2 years). Why would this have changed and what is QS Fix doing that it will fix an audio/video mismatch?

"QS Fix" fixes timestamp issues in the mpeg2 files which are common in digital cable recordings. Most mpeg2 decoders are very forgiving for these errors, so playing back the original mpeg2 file you may not see any problems. But encoders are much more sensitive to errors, so you need to clean up any timestamp issues before attempting to re-encode to something else, otherwise you run the risk of A/V sync issues such as you are seeing. For series 2 units which make their own encodings from analog you don't need QS Fix, but any digital cable recording is prone to having problems. As to why you didn't have problems before there can be many factors, one of them being luck.

Thanks for the help, I will try QS Fix now and see how it works. But another question:

What file needs to be deleted so that KMTTG will rebuild the Tivo names? Of my 4 Tivo's, 3 have been renamed in the past 6 months and so I still get tabs for the old and the new names. In the Settings tab for TiVo's, only the correct ones show but somewhere it remembers them all. How can I get them to clean up so I only get 4 tabs?

Thanks for the help, I will try QS Fix now and see how it works. But another question:

What file needs to be deleted so that KMTTG will rebuild the Tivo names? Of my 4 Tivo's, 3 have been renamed in the past 6 months and so I still get tabs for the old and the new names. In the Settings tab for TiVo's, only the correct ones show but somewhere it remembers them all. How can I get them to clean up so I only get 4 tabs?

In kmttg GUI go to config-TiVos tab and delete the ones you don't want.