# VideoReDo Problem



## mobilelawyer (Jan 3, 2006)

Have not seen this reported of late. I used the TiVo Desktop software to transfer titles to my PC, and I edit out the commercials using VideoReDo.

This has worked flawlessly for a month. Now, when I try to open a transferred .TiVo file, VideoReDo reports that it cannot open it. I have not changed or updated either the VideoReDo program or the TiVo desktop.

I upgraded to windows 8.1, but it has been working fine after that update. 

I am perplexed and have also posted this problem on the VideoReDo user forums.

Has anyone come across the problem, or, if you have, did you find a solution?


----------



## caddyroger (Mar 15, 2005)

One way I got around it was to use kmttg to down load the programs. It will change the tivo files to mpg file that videoredo can use


----------



## mr.unnatural (Feb 2, 2006)

Make sure you've got VideoReDo configured to work with .tivo files. You have to specify this during the intiial installation. It sounds like something may have happened to change this setting. I suspect there is a way to enable this in VRD once it's been installed, but I'd have to check. Try uninstalling VideoReDo and reinstalling it from scratch, making sure the option to work with .tivo files has been selected.


----------



## dlfl (Jul 6, 2006)

.tivo files definitely can be enabled from the VRD UI --- just poke around in the menu system.


----------



## mobilelawyer (Jan 3, 2006)

Problem hopefully resolved. I missed the post on the h.264 VRD forum. Many others have reported the same issue. I understand it has been resolved in a beta release, I will try to update the software when I get home.

The program has always worked perfectly with .TiVo files before. This sudden inability to open the files just recently popped up, and the VRD folks are aware of it.


----------



## Dan203 (Apr 17, 2000)

Yeah we had a glitch in our license system that caused a bunch of people's VRD to get disabled. We released a new build that fixes the problem.


----------



## unitron (Apr 28, 2006)

Dan203 said:


> Yeah we had a glitch in our license system that caused a bunch of people's VRD to get disabled. We released a new build that fixes the problem.


So the software that could previously do it was still capable of doing it, but suddenly became convinced that it was no longer allowed to do it?


----------



## Dan203 (Apr 17, 2000)

Basically we have a hacker check in our code that checks the server every now and then and compares the registration key against a list of known bad keys. If it comes back positive it basically disables the whole program and makes it so you can't even open a file. Something got screwed up on the server yesterday and all keys got flagged as bad. So anyone that tried to use VRD between like 2:30-8:30EST yesterday had their version disabled as if it were hacked. Unfortunately once it's in that state there is no way to fix it remotely so we had to release a new build to fix it. Once you install the new build you can uninstall it and revert to whatever version you were using previously, but the new build is needed to unlock the software and clear the false positive.


----------



## unitron (Apr 28, 2006)

Dan203 said:


> Basically we have a hacker check in our code that checks the server every now and then and compares the registration key against a list of known bad keys. If it comes back positive it basically disables the whole program and makes it so you can't even open a file. Something got screwed up on the server yesterday and all keys got flagged as bad. So anyone that tried to use VRD between like 2:30-8:30EST yesterday had their version disabled as if it were hacked. Unfortunately once it's in that state there is no way to fix it remotely so we had to release a new build to fix it. Once you install the new build you can uninstall it and revert to whatever version you were using previously, but the new build is needed to unlock the software and clear the false positive.


And by hacker you mean not so much someone who added stuff and customized it as someone who rigged it to work past the trial period without paying?


----------



## Dan203 (Apr 17, 2000)

Yes.


----------



## dlfl (Jul 6, 2006)

Dan203 said:


> Basically we have a hacker check in our code that checks the server every now and then and compares the registration key against a list of known bad keys. If it comes back positive it basically disables the whole program and makes it so you can't even open a file. Something got screwed up on the server yesterday and all keys got flagged as bad. So anyone that tried to use VRD between like 2:30-8:30EST yesterday had their version disabled as if it were hacked. Unfortunately once it's in that state there is no way to fix it remotely so we had to release a new build to fix it. Once you install the new build you can uninstall it and revert to whatever version you were using previously, but the new build is needed to unlock the software and clear the false positive.


Did the intern do this?


----------



## magicspell (Jan 10, 2013)

Dan203 said:


> Basically we have a hacker check in our code that checks the server every now and then and compares the registration key against a list of known bad keys. If it comes back positive it basically disables the whole program and makes it so you can't even open a file. Something got screwed up on the server yesterday and all keys got flagged as bad. So anyone that tried to use VRD between like 2:30-8:30EST yesterday had their version disabled as if it were hacked. Unfortunately once it's in that state there is no way to fix it remotely so we had to release a new build to fix it. Once you install the new build you can uninstall it and revert to whatever version you were using previously, but the new build is needed to unlock the software and clear the false positive.


So, just to make sure I understand. If we didn't try to use VideoReDo over the last couple of days we DON'T need to install the new build as an interim fix?


----------



## Dan203 (Apr 17, 2000)

Yes. If you did not use VRD in the time frame where the server was messed up you'll be fine. You'll know immediately if you're affected because you wont be able to open any files.


----------



## aaronwt (Jan 31, 2002)

Dan203 said:


> Yes. If you did not use VRD in the time frame where the server was messed up you'll be fine. You'll know immediately if you're affected because you wont be able to open any files.


Great. I haven't used it in a while and I'm setting up a new PC with TiVo Desktop this weekend. So I need to install VideoReDo, KMTTG, and TiVo Desktop on the new machine.


----------



## lpwcomp (May 6, 2002)

I'm having a problem with VRD and .tivo files when it is invoked by the kmttg service. Works fine when invoked by the kmttg GUI or when used directly. The errors indicate that it cannot get the MAK. See the posts here and here for more details.

I am running Win 8.1 and have TD 2.8.3 installed.


----------



## Dan203 (Apr 17, 2000)

Can you open the same .tivo file in the VRD UI and save it to the same profile kmttg is trying to use? If so try opening the same file and queuing it to batch, then run the batch manager. Does that work?

If the batch manager works then this has to be a kmttg problem as the batch manager uses the same COM interface as kmttg to process files. If batch does not work let me know and I'll investigate further.


----------



## lpwcomp (May 6, 2002)

Dan203 said:


> Can you open the same .tivo file in the VRD UI and save it to the same profile kmttg is trying to use? If so try opening the same file and queuing it to batch, then run the batch manager. Does that work?
> 
> If the batch manager works then this has to be a kmttg problem as the batch manager uses the same COM interface as kmttg to process files. If batch does not work let me know and I'll investigate further.


The only time anything fails is when the kmttg _*service*_ invokes VRD to decrypt the .tivo file. I don't think it is either a VRD or a kmttg problem. Either Win 8 "security" is keeping it from accessing the MAK when it is invoked by the service or I have done something wrong, don't know what, and thus have no idea how to fix.

I was hoping someone here might have an idea.


----------



## Dan203 (Apr 17, 2000)

VideoReDo can not be invoked from a headless service. The VRD COM interface basically just launches a hidden version of the VRD UI off screen. So you must be logged in as a user and the service must be running as that same user for it to work properly.


----------



## ggieseke (May 30, 2008)

Another thing to consider is that TiVo Desktop encrypts the MAK in the registry under the user that installed it. Only that user on that PC can access it. The service would have to be running under the same creds, and even then I'm not sure it would work.


----------



## moyekj (Jan 24, 2006)

ggieseke said:


> Another thing to consider is that TiVo Desktop encrypts the MAK in the registry under the user that installed it. Only that user on that PC can access it. The service would have to be running under the same creds, and even then I'm not sure it would work.


 kmttg has been running VRD COM jobs from service mode for a long time. It does normally work as long as service as running as same user that runs VRD GUI. I also just confirmed on Win Vista & Win 7 that it still works in service mode using latest VRD TVSuite. So the issue lpwcomp is having is either Win 8 specific or some localized issue. I don't have Win 8 to test. lpwcomp did watch Task Manager and sees that cscript.exe when invoked from kmttg service to run VRD COM job does indeed run with User set properly and yet VRD still can't access the MAK apparently. I'll have to ask lpwcomp to try qsfix on a decrypted mpeg2 file instead to see if that works...


----------



## lpwcomp (May 6, 2002)

ggieseke said:


> Another thing to consider is that TiVo Desktop encrypts the MAK in the registry under the user that installed it. Only that user on that PC can access it. The service would have to be running under the same creds, and even then I'm not sure it would work.


The thing is, it only fails when VRD is invoked from the service, and it is only the decrypt that fails. Every other part of VRD runs OK, even qsfix as long as I don't try to use VRD to decrypt. Of course, I also have to d/l in ps format but simply changing to ps doesn't enable VRD decrypt to work. It gets a different error code in the kmttg auto.log (4 instead of 3) but the error in the VRD log still indicates a MAK problem.


----------



## dlfl (Jul 6, 2006)

lpwcomp said:


> The thing is, it only fails when VRD is invoked from the service, and it is only the decrypt that fails. Every other part of VRD runs OK, even qsfix as long as I don't try to use VRD to decrypt. ........


If you're using VRD TVSuite 4 (H.264), have you tried QSF using a custom Output Profile (one which you have defined rather than built in to VRD)?
I suspect you may see account-related problems there too.


----------



## lpwcomp (May 6, 2002)

dlfl said:


> If you're using VRD TVSuite 4 (H.264), have you tried QSF using a custom Output Profile (one which you have defined rather than built in to VRD)?
> I suspect you may see account-related problems there too.


If you're talking about when using VRD by itself, there is no problem. If you're talking about when invoked by kmttg, either manually or by the server, I don't see any way to specify the qsfix output profile. I also see no problem with a VRD encode using a user defined profile, no matter how VRD is invoked.


----------



## Dan203 (Apr 17, 2000)

You would use FileOpenBatch to open the file in QSF mode, then use FileSaveProfile to save to a profile. (FileSaveProfile is not in the docs, the first param is the output file path and the second is the name of the profile)


----------



## lpwcomp (May 6, 2002)

Dan203 said:


> You would use FileOpenBatch to open the file in QSF mode, then use FileSaveProfile to save to a profile. (FileSaveProfile is not in the docs, the first param is the output file path and the second is the name of the profile)


I modified the kmttg qsfix.vbs to use a profile I created and dlfl is correct. It works fine when I run it from kmttg GUI but fails with "PROFILENOTFOUND" in the service.


----------



## Dan203 (Apr 17, 2000)

That's a permission problem. The custom profiles are stored in the My Documents section and services may not have access to them.

There is an override function to load a profiles list from wherever you want that might help. First off the structure of the XML needs to match what's in the DefaultProfiles.xml in the VideoReDo install folder. (the OutputProfilesEx.xml in My Documents uses references to the default list, this needs to be a standalone list) Next it needs to be placed in a location that is accessible to the service. Then in the script you need to call SetUserProfilesPath with the path to the XML file.


----------



## dlfl (Jul 6, 2006)

Dan203 said:


> That's a permission problem. The custom profiles are stored in the My Documents section and services may not have access to them.
> 
> There is an override function to load a profiles list from wherever you want that might help. First off the structure of the XML needs to match what's in the DefaultProfiles.xml in the VideoReDo install folder. (the OutputProfilesEx.xml in My Documents uses references to the default list, this needs to be a standalone list) Next it needs to be placed in a location that is accessible to the service. Then in the script you need to call SetUserProfilesPath with the path to the XML file.


I posted my suspicions above based on what happens if you attempt to use Win7 task scheduler to run VAP-launched VRD processing using custom Output Profiles and you tell the scheduler to run it even if you aren't logged in to the user account (i.e., the scheduler task runs in the system account). The override function doesn't provide an attractive solution for automation in VAP. Things would be easier (although perhaps still not ideal for automation programs such as VAP and kmttg) if the override function could point to a reachable location where a copy of OutputProfilesEx.xml has been placed.


----------



## moyekj (Jan 24, 2006)

FYI, those permissions problems running in service mode are fixed by setting the service to run as same user that runs the GUI. At least for XP, Vista and Win 7 running latest VRD TVSuite from service mode works fine. Perhaps Win 8 has changed something to break services even more by restricting file access even if username matches, but I don't have Win 8 to test with. (Why Microsoft makes services so painful I have no idea...)


----------



## dlfl (Jul 6, 2006)

moyekj said:


> FYI, those permissions problems running in service mode are fixed by setting the service to run as same user that runs the GUI. At least for XP, Vista and Win 7 running latest VRD TVSuite from service mode works fine. Perhaps Win 8 has changed something to break services even more by restricting file access even if username matches, but I don't have Win 8 to test with. (Why Microsoft makes services so painful I have no idea...)


I agree on your MS comment, although there is no actual mystery as to why they do it -- to protect you!  (It tends to protect you from getting anything done, of course.)

If you set kmttg up as a service running as user account A, then user A logs off, does the service continue running OK without permission issues, e.g., while User B logs in and does things? Note that "switching user" is not the same as logging off. If you switch from User A to User B, User A is still logged in.

Scheduled tasks are a different thing from Services of course, but even if the task is setup to run on the User A account, the VRD custom profiles will not be reachable if you configure the scheduled task to run when User A is not logged in.


----------



## moyekj (Jan 24, 2006)

dlfl said:


> I agree on your MS comment, although there is no actual mystery as to why they do it -- to protect you!  (It tends to protect you from getting anything done, of course.)
> 
> If you set kmttg up as a service running as user account A, then user A logs off, does the service continue running OK without permission issues, e.g., while User B logs in and does things? Note that "switching user" is not the same as logging off. If you switch from User A to User B, User A is still logged in.
> 
> Scheduled tasks are a different thing from Services of course, but even if the task is setup to run on the User A account, the VRD custom profiles will not be reachable if you configure the scheduled task to run when User A is not logged in.


 I don't know the answer to your question. Most of my testing is on home machines where I tend to be always logged in and running the service, and the machines I'm using only have 1 main user login anyway. If that doesn't work then that may explain the problem lpwcomp is running into if he is logging out and running the service.


----------



## Dan203 (Apr 17, 2000)

dlfl said:


> Things would be easier (although perhaps still not ideal for automation programs such as VAP and kmttg) if the override function could point to a reachable location where a copy of OutputProfilesEx.xml has been placed.


I added the function for a broadcast customer who needed to completely override the location of the profiles. The internal system uses the DefaultProfiles.XML to load most profiles, then uses OutputProfiles.xml just for new profiles and changes to default profiles. It's sort of a hybrid system designed to let multiple users of the same machine to have different profile preferences and to allow custom profiles to survive an uninstall/reinstall. Internally that's done via two steps, loading DefaultProfiles.xml and then calling a special function to merge OutputProfilesEx.xml. The current COM functionality basically just wipes the list and loads the user supplied path as if it were DefaultProfiles.xml. the merging functionality is not exposed via COM. I "might" be able to expose that via a secondary function, but it would still require the user to maintain a copy of their lists in two locations. A better option might be to simply allow the user to specify where OutputProfilesEx.xml is stored so they can move it to a more service friendly location.


----------



## HerronScott (Jan 1, 2002)

moyekj said:


> FYI, those permissions problems running in service mode are fixed by setting the service to run as same user that runs the GUI. At least for XP, Vista and Win 7 running latest VRD TVSuite from service mode works fine. Perhaps Win 8 has changed something to break services even more by restricting file access even if username matches, but I don't have Win 8 to test with. (Why Microsoft makes services so painful I have no idea...)


Shouldn't be any different unless elevated rights are required (which does not seem to be the case here). This is pretty obvious why this is the case from a security standpoint. The program is running within the security context that it's launched whether that's interactive, scheduled task or service. Not sure what you mean about services being painful though as they make perfect sense to me. 

Scott


----------



## moyekj (Jan 24, 2006)

HerronScott said:


> Shouldn't be any different unless elevated rights are required (which does not seem to be the case here). This is pretty obvious why this is the case from a security standpoint. The program is running within the security context that it's launched whether that's interactive, scheduled task or service. Not sure what you mean about services being painful though as they make perfect sense to me.
> 
> Scott


 I'm comparing "services" on Windows to background jobs or daemons on unix. Running background jobs and/or daemons on unix is so much easier and more intuitive to me compared to Windows which has stringent requirements just to launch the jobs. You can't just take any executable and launch it as a service in Windows, there are special requirements needed to be able to launch as a service. That's mostly what I was referring to.


----------



## HerronScott (Jan 1, 2002)

Ah understand now!

Scott


----------

