Here's what I would like to do:
I would like to be able to manually select a number of PAR2 files (it would end up being one within each set), and run a script that would execute those files (which would load QuickPAR and have it start authenticating the set) one at a time. Basically, I want the first one to run, and when QuickPAR is finished processing it (regardless of whether it needs repair or not), the next one would load, so on and so forth. This would leave as many QuickPAR windows open as were sets selected.
The reason for this script is that QuickPAR does not handle concurrent sets very well. It takes longer to run two sets simultaneously then it does to run them serially. But doing this by hand is a time-intensive process that requires you stay and watch and load the next set as needed. I would like a way to automate this process.
However, even if QuickPAR returned result codes (which I'm not sure it does), I'm not sure XY is capable of reading them. That would suggest that the best way to handle this might be to watch for the CPU load to drop below a certain threshold - which I don't think XY can do either.
So, I wanted to get other people's opinions on this. Would the best way to do this be to write an XY script that would hand off the list of selected file names (with paths) to an AutoHotkey script?
Or is there a better way?
Help with creating a script to interact with QuickPAR
-
Stefan
- Posts: 1360
- Joined: 18 Nov 2008 21:47
- Location: Europe
Re: Help with creating a script to interact with QuickPAR
Can't you use RUN (click) with the wait option?Mesh wrote:, I want the first one to run, and when QuickPAR is finished processing it, the next one would load, so on and so forth.
while() {
run <command QuickPAR $item> [, <working dir>][, <wait 1>]
}
<wait>
Defines whether or not XY shall wait for the shelled process launched to be over to continue script execution :
* 0 : [Default] Do not wait
* 1 : Wait before continuing script execution
-
Mesh
- Posts: 956
- Joined: 24 Mar 2008 21:22
Re: Help with creating a script to interact with QuickPAR
No, because QuickPAR doesn't exit when it's finished - it stays open. The only way to know when it's done, as far as I can tell is to monitor system resources.
For the time being, I wrote a script that passes the list to an AHK script, and the AHK script monitors the CPU load and controls QuickPAR that way. I'm still tweaking it to get it right, though.
-
Stefan
- Posts: 1360
- Joined: 18 Nov 2008 21:47
- Location: Europe
Re: Help with creating a script to interact with QuickPAR
Ah, O.K.Mesh wrote:No, because QuickPAR doesn't exit when it's finished - it stays open. The only way to know when it's done, as far as I can tell is to monitor system resources.Stefan wrote:Can't you use RUN (click) with the wait option?
AHK is also fine, but i think i had tried first to close the process on my own with an tool like 'pv' or 'process'
see http://www.softpanorama.org/Unixificati ... ml#PrcView
while() {
run <command QuickPAR $item> [, <working dir>][, <wait 1>]
wait 2000;
run Process.exe -q QuickPAR ;
//pv.exe --close QuickPAR
}
There are also WinXP own tools like TsKill and TaskKill, but i don't know if they also
can CLOSE an process rather then killing them. (and i just had known this other tools before XP was there)
http://commandwindows.com/taskkill.htm
But maybe U just enjoy just scripting
-
Mesh
- Posts: 956
- Joined: 24 Mar 2008 21:22
Re: Help with creating a script to interact with QuickPAR
Stefan wrote:
Ah, O.K.
AHK is also fine, but i think i had tried first to close the process on my own with an tool like 'pv' or 'process'
Well, I actually don't want QuickPAR to close when done. I want to see the results, and choose whether to repair them or not. I don't mind having a dozen QuickPAR windows open - they just can't all start at the same time, otherwise it will take a month before they finish.
In any case, my scripts are complete and working fine, now. If anyone's interested, just give a shout and I'll post them for you.
XYplorer Beta Club