Running as scheduled task

[Cypheros]

You want to have a wait time after processing or during processing?

If you want to slow the TS-Doctor down, you can use the GUI to change the priority class of the TS-Doctor.

[Reddwarf]

You want to have a wait time after processing or during processing?

If you want to low the TS-Doctor down, you can use the GUI to change the priority class of the TS-Doctor.

I'v tried that, but it still chokes the computer with heavy disk access, so a 10-30 mS sleep between each frame would help greatly, as it does in Comskip.

[Hominidae]

Came to think of one thing and did some more testing. .29 actually works but the service that calls the batch that again calls TSDoctor MUST be allowed to interact with the desktop!

....sorry for being a windoze noop...how do you apply that kind of setting to a service?
Are you running the service in session 1, while/where the user is logged in?

[Reddwarf]

Came to think of one thing and did some more testing. .29 actually works but the service that calls the batch that again calls TSDoctor MUST be allowed to interact with the desktop!

....sorry for being a windoze noop...how do you apply that kind of setting to a service?
Are you running the service in session 1, while/where the user is logged in?

You'll have to run Services.msc, right click on the actual service and choose Properties, then select the "Log On" tab. If you click the "This account" button you can specify which service the user runs as.

[Mam]

Running Services as ordenary Users usually ends in a total mess (as long, as the service is not designed this way, and since TS Doc is more an interactive desktop application (even 32 bit only), this should break things very likely).

This is because shells like the explorer usually already aquire certain system rights and inherit them to the launched application. Service manager does not do this, its up to the service himself to request that right to become active.

Unix users usually look at the file permission, maybe even a bit deeper into extended permissions and know what the application can do with these permissions. In Windoze its different, a user must have a certain right (for instance "Backup priviledge"), but this alone does not do or grant anything. The launched program also must request to use this right ( like "during my runtime I want to open a file or more with backup rights" (again unix-guys, this does not mean that it is a backup program, just that it wants to read ANY and EVERY file without looking at file permissions at all)) at startup.

Desktop programs usually dont request all rights needed, because some are already inherited as mentioned above.

So, to be on the safe side, ask the dear programmer here to ensure that EVERY needed right is reclaimed at startup time of TS Doc (and dont blame him now, if it is not (yet). remember, its unlikely and normaly not needed).
But its a hard and tedious job, because you dont see any differences instantly, and some rights are really.. hmm, how to say?, "STRANGE" to determine (for instance "Bypass traverse checking") because usually ANYBODY has them, but a service run as a user has not.

I would recommend to run your service with the account of the local system and allow "interaction with the desktop" instead. This usually gives less troubles because services are started differnently this way (not completly like desktop, but at least with "sane" rights inherited)

[Reddwarf]

I think you have misunderstood a bit. It is running as a privileged user (and the user who owns the files in question) that works, WITH "Interact with desktop" allowed. Running as the local system does not work.

It is still a bit strange, the file is created in any case, but TSDoctor just will not end if run as the local system account.

[Mam]

I think you have misunderstood a bit. It is running as a privileged user (and the user who owns the files in question) that works, WITH "Interact with desktop" allowed. Running as the local system does not work.

It is still a bit strange, the file is created in any case, but TSDoctor just will not end if run as the local system account.

Nope, I've understood perfectly, you just did not understand me :-)

There is NO WAY for you to "GIVE ALL NEEDED PRIVILEDGES" to a program or a user. This is a mandantory needed thing, but not a completly sufficient one.
Windooze works a bit different, the program also needs to actively request a priv (the request is then granted if the user owns that particular priv).
So if you grant a priv to a user, it does NOTHING unless the program also asks for it.

And Services have to ask for MORE PRIVS than a standard desktop application, so it is unlikely, that TS Doc already asks for all the needed things.

One strange effect of this can be that the app "hangs" somewhere because a needed priv is not asked for but the program tries a command that needs tis priv.
Either the request is denied by windows (error return), or, in some cases, the app is halted and put into endless sleep. this can happen easily if the app tries to shutdown and one of the cleanup tasks fails due to the lack of a priv. In this case the mutex is never released and the app looks to "hang".

(there is nothing wrong with the code, just a priv has "forgotten" to be reclaimed at startup)

[Reddwarf]

I understood you perfectly, but I still think we are talking across. It seems that what you last described is what is happening when TSDoctor does not terminate, but it does NOT happen when the recording service (which calls the batch that runs TSDoctor) is run as a privileged user that owns the files in question.

[Mam]

I understood you perfectly, but I still think we are talking across. It seems that what you last described is what is happening when TSDoctor does not terminate, but it does NOT happen when the recording service (which calls the batch that runs TSDoctor) is run as a privileged user that owns the files in question.

what i last described was just a guess what MIGHT happen due to a missing priv. But it will be hard to proove for the programmer because there is almost no way to debug a service in its native runtime enviroment (It might work with remote debbugging, but I never tried it).

Your recording service and the batch afterwards make things even more complicated. Both of them surely ask for SOME privs (those that are needed by them) which are granted and activated and INHERITED.
Therefor TSDoc gets a completely different runtime environment as started by a user or run as a native service.
So its almost impossible to guess for the author, WHAT is still missing.
To be on the safe side, he would have request ALL that are needed for TS_doc (but even this is quite a challenge, surely he does not know which one, this takes a very haaaard and deeep search into the programmer's manuals).

[Cypheros]

You want to have a wait time after processing or during processing?

If you want to low the TS-Doctor down, you can use the GUI to change the priority class of the TS-Doctor.

I'v tried that, but it still chokes the computer with heavy disk access, so a 10-30 mS sleep between each frame would help greatly, as it does in Comskip.

OK, set application priority to IDLE and the disk I/O performance of the TS-Doctor will be reduced too. New Beta 1.2.31 is online.

[Reddwarf]

Thanks, setting IDLE priority seems to have helped. In some cases I will have two or more instances of TSDoctor running at the same time, would that create a problem?

[Cypheros]

Yes, because some temporary files could use the same filenames (logs, batch, file merging,etc.).

Sorry, never thought about a multi instance scenario.

[Mam]

Also, many programs running at IDLE priority would obviously block each other. If a programm is doing something, its obviously NOT IDLE anymore.
Of course, it will work somehow and even finish someday, but its not predictable at all.

(in general, IDLE should be used with care, and should be limited to programs that dont use many ressources (like screensavers or so). TSDoc is surely NOT the best candidate for this because it is a real disk hog).

Also, keep in mind that IDLE is the worst thing you can do to a VM! The virtual manager needs the IDLE state to switch back to the host system or to other vms.

[Reddwarf]

Also, many programs running at IDLE priority would obviously block each other. If a programm is doing something, its obviously NOT IDLE anymore.
Of course, it will work somehow and even finish someday, but its not predictable at all.

(in general, IDLE should be used with care, and should be limited to programs that dont use many ressources (like screensavers or so). TSDoc is surely NOT the best candidate for this because it is a real disk hog).

Also, keep in mind that IDLE is the worst thing you can do to a VM! The virtual manager needs the IDLE state to switch back to the host system or to other vms.

In spite of that it is working fine now 

[Reddwarf]

I'm sorry to say that the latest beta does not terminate the way I run it, but 1.2.29 does work ok.