I can't really read the text in the picture but sounds to me like you are exploring inside the kmttg zip file and then double clicking on kmttg.jar which doesn't work. You have to fully extract the zip file to some location (don't put it under Program Files) and then double click on kmttg.jar there.

I can't really read the text in the picture but sounds to me like you are exploring inside the kmttg zip file and then double clicking on kmttg.jar which doesn't work. You have to fully extract the zip file to some location (don't put it under Program Files) and then double click on kmttg.jar there.

Thanks for looking but no, I have extracted it to a new locations, 2 different times to two separate locations and they all do the same thing. This makes me think it is a Java issue but I can't figure out what.

I went to Java dot com and downloaded from there and then I also went to the link provided in the instructions to make sure I also got the 32 bit version and installed that. None of those things have helped.

Looking at the current code, the "qsfix" task specifically starts by looking to qsfix the .mpg file if it exists, else the .TiVo file otherwise. This makes sense if you don't have at least a partial install of TiVo Desktop such that decrypting .TiVo files is not possible. So not sure if changing to look for .TiVo file 1st is the right thing to do here. I suppose if the context is from "decrypt" task then that would be a reasonable thing to do, but for general "qsfix" probably not.

Not if you specifically start from .TiVo file in FILES tab. Let me look into it more closely. But I'm curious why you have existing .mpg file already along with .TiVo file?

Transitioning from ps download/tivodecode to ts download/VideoRedo.

Quote:

Originally Posted by moyekj

EDIT: You're right it does pick up the .mpg file instead of .TiVo file as a starting point. But the rename still works for me.

At this point I have no idea what is actually happening. I had assumed that the rename wasn't happening based on the date and the fact that the content of the .mpg was not changing. The rename may be happening and the date not changing may be some weirdness with Win 8.1.

Looking at the current code, the "qsfix" task specifically starts by looking to qsfix the .mpg file if it exists, else the .TiVo file otherwise. This makes sense if you don't have at least a partial install of TiVo Desktop such that decrypting .TiVo files is not possible. So not sure if changing to look for .TiVo file 1st is the right thing to do here. I suppose if the context is from "decrypt" task then that would be a reasonable thing to do, but for general "qsfix" probably not.

I checked in some changes just now that if running qsfix in context of "decrypt" task, then look for .TiVo file as starting point instead of .mpg file. Original logic still applies assuming starting point as .mpg file when it exists if running qsfix from "qsfix" task context.
If you svn update and build from source again you can test the change.

I checked in some changes just now that if running qsfix in context of "decrypt" task, then look for .TiVo file as starting point instead of .mpg file. Original logic still applies assuming starting point as .mpg file when it exists if running qsfix from "qsfix" task context.
If you svn update and build from source again you can test the change.

Thanks for the quick response. It may be awhile before I can test it. There appears to be a conflict with my mods and more recent releases. I am still running v1p0k_beta.

I may have to start over and re-apply my mods by hand. This is using Eclipse Kepler release.

c:\kmttg>kmttg.jar
Exception in thread "main" java.lang.NoClassDefFoundError: C:\kmttg\kmttg/jar
Caused by: java.lang.ClassNotFoundException: C:\kmttg\kmttg.jar
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Could not find the main class: C:\kmttg\kmttg.jar. Program will exit.

c:\kmttg>java -jar kmttg.jar
'java' is not recognized as an internal or external command,
operable program or batch file.

The NoClassDefFoundError error usually happens when default class is not defined in a manifest file. However, kmttg.jar has proper manifest file which properly defines the main class:
Main-Class: com.tivo.kmttg.main.kmttg

So not sure why your Java installation is not finding it...

Try this. You first have to figure out full path to javaw.exe which you can do with command:
ftype jarfile

Then take the full path to javaw.exe and add -cp kmttg.jar com.tivo.kmttg.main.kmttg which explicitly defines the class to use. i.e. In example above it would be:
"C:\Program Files (x86)\Java\jre7\bin\javaw.exe" -cp kmttg.jar com.tivo.kmttg.main.kmttg

c:\kmttg>kmttg.jar
Exception in thread "main" java.lang.NoClassDefFoundError: C:\kmttg\kmttg/jar
Caused by: java.lang.ClassNotFoundException: C:\kmttg\kmttg.jar
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Could not find the main class: C:\kmttg\kmttg.jar. Program will exit.

c:\kmttg>kmttg.jar
Exception in thread "main" java.lang.NoClassDefFoundError: C:\kmttg\kmttg/jar
Caused by: java.lang.ClassNotFoundException: C:\kmttg\kmttg.jar
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Could not find the main class: C:\kmttg\kmttg.jar. Program will exit.

c:\kmttg>java -jar kmttg.jar
'java' is not recognized as an internal or external command,
operable program or batch file.

c:\kmttg>

Any thoughts?

Quote:

Originally Posted by RBeatse

Well, I did as you asked and I got the same message but as soon as it put the error message out it started the program. So, I guess it is working?!? THANK YOU, either way!!

c:\kmttg>kmttg.jar
Exception in thread "main" java.lang.NoClassDefFoundError: C:\kmttg\kmttg/jar
Caused by: java.lang.ClassNotFoundException: C:\kmttg\kmttg.jar
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
Could not find the main class: C:\kmttg\kmttg.jar. Program will exit.

I checked in some changes just now that if running qsfix in context of "decrypt" task, then look for .TiVo file as starting point instead of .mpg file. Original logic still applies assuming starting point as .mpg file when it exists if running qsfix from "qsfix" task context.
If you svn update and build from source again you can test the change.

Once again, thanks for the quick response. After figuring out what my problem was (I needed to update the entire project, not just the src), I managed to build a working version and it works fine. I then re-applied my patch and it also works fine.

Edit: The date thing does indeed appear to be a Win 8(.1?) "feature", wherein if you rename a file to an already existing file, it keeps the create date of the existing file.

I've really only started using kmttg since installing a roamio - it would have been useful with my old series 3, but I didn't know about it since I never needed to look for the transfer functionality. Now that I've found it, it's my go-to remote for TiVo.

Two questions:
1) is there a kmttg app for android? It does so much more than the apps out there and seems small and portable enough to be able to be ported.

2) kmttg can transfer more than other TiVo methods - can you expand it to allow for complete transfer of relevant files on a hard drive upgrade? I'm talking about wishlists, thumbs up/down, files created during guided setup, other personal settings?

Pretty much everything useful I know what to do with RPC operations is included in some form in kmttg. Probably about 80% of the RPC functions that I know of are not authorized to run with iOS/Android authentication level, so functionality we have is limited and is all based on reverse engineering.

Best Android App I know of is arantius' TiVo Commander which is a better version than what TiVo offers. I have no interest in working on an Android version of anything and the TTG related tasks are not well suited to run on that kind of platform anyway.

Looking at the current code, the "qsfix" task specifically starts by looking to qsfix the .mpg file if it exists, else the .TiVo file otherwise. This makes sense if you don't have at least a partial install of TiVo Desktop such that decrypting .TiVo files is not possible. So not sure if changing to look for .TiVo file 1st is the right thing to do here. I suppose if the context is from "decrypt" task then that would be a reasonable thing to do, but for general "qsfix" probably not.

Hi and Happy New Year.

I'll second that. I "qsfix" with VRD. Although it is not a dealbreaker either way I look at it, I'd rather be required to manually delete or rename any existing MPG, in lieu of accidentally overwriting the file which would necessitate a complete re-run somewhere else.

I'll second that. I "qsfix" with VRD. Although it is not a dealbreaker either way I look at it, I'd rather be required to manually delete or rename any existing MPG, in lieu of accidentally overwriting the file which would necessitate a complete re-run somewhere else.

I'm not complaining you understand since I think things are working the way I want them to now, and maybe I'm dense, but I fail to understand the logic here. If I have the "Overwrite existing files" option checked and I tell kmttg to begin the process with a specific file or TiVo recording, why would I want it to use existing files in lieu of the ones created by the process?

I'm not complaining you understand since I think things are working the way I want them to now, and maybe I'm dense, but I fail to understand the logic here. If I have the "Overwrite existing files" option checked and I tell kmttg to begin the process with a specific file or TiVo recording, why would I want it to use existing files in lieu of the ones created by the process?

It has been a while since I last looked, but I think that only applies to pre-existing .tivo files on the computer, as per Tivo-to-computer KMTTG transfer. If that gets interrupted then it will obviously need to be replaced with a whole file.

The other possibility that I am understanding being an .mpg file (for many, this would be the QSF output). So theoretically if a movie is downloaded and QSF'd a second time by accident, then the QSF subroutine would detect an existing .mpg and not overwrite it, saving the user a bit of extra time. Or costing them, depending on how you look at it.

I could be wrong about some of this since I run it with the "overwrite" checkbox deselected and the "delete decrypted .tivo file" selected, but it would seem to me that the same logic that applies to the .tivo file would also need to explicitly be defined by the programmer to apply to the .mpg file as well (if so desired).

It has been a while since I last looked, but I think that only applies to pre-existing .tivo files on the computer, as per Tivo-to-computer KMTTG transfer. If that gets interrupted then it will obviously need to be replaced with a whole file.

The other possibility that I am understanding being an .mpg file (for many, this would be the QSF output). So theoretically if a movie is downloaded and QSF'd a second time by accident, then the QSF subroutine would detect an existing .mpg and not overwrite it, saving the user a bit of extra time. Or costing them, depending on how you look at it.

I could be wrong about some of this since I run it with the "overwrite" checkbox deselected and the "delete decrypted .tivo file" selected, but it would seem to me that the same logic that applies to the .tivo file would also need to explicitly be defined by the programmer to apply to the .mpg file as well (if so desired).

The change I made only applies to the "decrypt" task. If you are running "qsfix" task the old logic of looking at .mpg file 1st still applies. This makes sense to me since purpose of decrypt task is to decrypt .TiVo file.

It has been a while since I last looked, but I think that only applies to pre-existing .tivo files on the computer, as per Tivo-to-computer KMTTG transfer. If that gets interrupted then it will obviously need to be replaced with a whole file.

The option is at the bottom of the "File Settings" screen and so presumably it refers to all files created during processing. And that's the way it did work until I switched to VideoRedo.

Quote:

Originally Posted by christheman

The other possibility that I am understanding being an .mpg file (for many, this would be the QSF output). So theoretically if a movie is downloaded and QSF'd a second time by accident, then the QSF subroutine would detect an existing .mpg and not overwrite it, saving the user a bit of extra time. Or costing them, depending on how you look at it.|

Most of the time, the reason you are redoing everything is because there was a problem with the end result. If you know an interim file is good, start there and re-run from that point. In addition, anyone using tivodecode will have the .mpg file created by the decrypt step. If you're using VideoRedo, the .mpg was created by qsfix so whyy are you running it through qsfix again.

Quote:

Originally Posted by christheman

I could be wrong about some of this since I run it with the "overwrite" checkbox deselected and the "delete decrypted .tivo file" selected, but it would seem to me that the same logic that applies to the .tivo file would also need to explicitly be defined by the programmer to apply to the .mpg file as well (if so desired).

AFAICT, that's the way it does work for the most part, unless you are using VideoRedo. It seems to me that to do otherwise assumes that the user made a mistake and wasn't trying to rerun the process starting at an earlier point and thus didn't really want to overwrite that file despite checking the "Overwrite existing files" box.

The change I made only applies to the "decrypt" task. If you are running "qsfix" task the old logic of looking at .mpg file 1st still applies. This makes sense to me since purpose of decrypt task is to decrypt .TiVo file.

I don't mean to be difficult, but it still makes no sense to me. As I noted in my prior post, if you're using VideoRedo, then the .mpg file was created by qsfix. If I'm using tivodecode and want to start with the decrypted .mpg, I would have selected that file rather than the .tivo file.

I don't mean to be difficult, but it still makes no sense to me. As I noted in my prior post, if you're using VideoRedo, then the .mpg file was created by qsfix. If I'm using tivodecode and want to start with the decrypted .mpg, I would have selected that file rather than the .tivo file.

As I said before, you're assuming TD is installed so that qsfix will work with .tivo file which may not be the case. In any case, I don't see the problem here. If you want to qsfix .tivo file simply start with it and choose "decrypt" task and it will do what you want.

The option is at the bottom of the "File Settings" screen and so presumably it refers to all files created during processing. And that's the way it did work until I switched to VideoRedo.

That would explain things a bit since I also use VideoRedo. I haven't used KMTTG without it for quite some time.

Quote:

Most of the time, the reason you are redoing everything is because there was a problem with the end result. If you know an interim file is good, start there and re-run from that point. In addition, anyone using tivodecode will have the .mpg file created by the decrypt step. If you're using VideoRedo, the .mpg was created by qsfix so whyy are you running it through qsfix again.

I am often up late at night when I work on this, like right now. By the time I have some quiet time to myself, it is usually hours after I start the QSF transfers so I sometimes lose track.

Quote:

AFAICT, that's the way it does work for the most part, unless you are using VideoRedo. It seems to me that to do otherwise assumes that the user made a mistake and wasn't trying to rerun the process starting at an earlier point and thus didn't really want to overwrite that file despite checking the "Overwrite existing files" box.

As I said before, you're assuming TD is installed so that qsfix will work with .tivo file which may not be the case. In any case, I don't see the problem here. If you want to qsfix .tivo file simply start with it and choose "decrypt" task and it will do what you want.

Actually, it doesn't. What I want to do is feed the .tivo file directly to VRD adscan/adcut-encode. To this end, I have metadata, Ad Detect, Ad Cut and Encode selected. Neither decrypt nor QS fix is selected. I also have the relevant VRD options selected. Unfortunately, kmttg looks for the .mpg file and uses it if it exists. If it doesn't exist, it forces a qsfix to create one.

If you could just point me to the routine wherein it makes that decision, I am perfectly fine with adding to my local mods. I've already found the place in adscan.java to mod that I think will get me what I want.