qBittorrent official forums

When I was still messing with it, I wrote a batch to echo the "%F" passed in. It did get triggered and showed the full path...

Anyways, try as suggested by KitKat and see what happens. Hopefully, the exe will get triggered and the scipt works. If the script works, u can delete the pause lines and exit.

Ok, so the .exe thing was totally right.  The web-converter wasn't working right (it kept assigning a password, which always failed), but installing the app was the better way to go in the end anyway.  I've tried it with RARs & MKV, and both are performing as they should - with one little caveat.

%~1 is picking up the folder path from the %F in the command line - however it's pulling from the Completion drive (the NAS), and not from the download drive (R:\TorTemp).  This means that the file(s) need to complete their move to the NAS first, then extract/copy themselves back.  It's not a major problem in the grand scheme of life, but one of the fundamental reasons for my setup the way it is, is to get that borderline-instantaneous extraction - RAMdisk -> RAMdisk

I'm not sure what the function of %~dp1 is, as I don't believe its reached that step (it's seemingly always been successful on the first pairing).  And when I flipped the order of the two (putting %~dp1 ahead of %~1), it had the same net result - success on the first function.

Is there a way to designate %~1 as from the RAMdisk (downloading destination) and %~dp1 as (it is currently) from the completion-move destination?

I put %~dp1 to take care of the single file torrents as %F outputs the path+file name. Also, it would be easier to debug with more info from the output.

set ramdisk as complete and temp location for those torrents.

Unfortunately, that's not a viable solution, based on the first 1.5 pages of this thread.  Obviously having a RAMdisk as the completion move would be extremely poor for long term seeding, and if I have R:\ in my watched folder, that creates some strange and unique issues of its own.

If you were able to explain to me where %~1 and %~dp1 are pulling their values from, then I could possibly play around a little...  Or if it can be re-tasked with an additional command, say %~2, meaning the value in Save Incomplete Torrents In - but as I said before, I don't know/understand where those values are coming from.

The batch has no move command, only extraction and copy.
From what u said, it means that qbt follows what YOU set in options to move the stuff from temp to complete then launch external programs...
"This means that the file(s) need to complete their move(not done by batch) to the NAS first, then extract/copy (batch) themselves back."


update1: if u don't believe me, modify the batch to only play a movie, nothing else. The movie will be played after all the moving is done.
update2: http://ss64.com/nt/syntax-args.html

You're right, but not completely so.  When I was using Vuze, I had the Auto-Extract thing going, as well as Completion Move.  The Auto-Extract would occur before (or simultaneously with) the completion move - and since extracting files from RAM onto RAM is borderline instantaneous, this would finish before the NAS move was complete.  It was a beautiful system!  However, as Vuze got more and more bloaty, and I upgraded my network, the burst transfer would more-often-than-not complete to the NAS before the extract command had a chance to run.  One of several reasons I've moved to QT.

What I would like to do is have a "command" that will allow me to generate the %F information, without locking that into a drive letter.  Then I could build a script that looks like:
if "R:\TorTemp\%~1\*.r*" (Extraction) :toHold
if "R:\TorTemp\%~1\*.mkv" (Copy) :toHold
if "V:\Completed\%~1\*.r*" (Extraction) :toHold
if "V:\Completed\%~1\*.mkv" (Copy) :toHold
:toHold
Exit

So as you can see above, I'm just looking for %~1 to contain the torrent path, not the full drive path.  I've experimented with the %F, %R and %D arguments, and while %F & %R are functionally identical, %D ONLY contains the save-path (not the torrent data).  In a math world, it would be as easy as %F (minus) %D = desired result (the torrent folder "orphaned" from a drive path).  I have utterly no idea if that's possible in scripting language.

[quote="tekko"]
When I was still messing with it, I wrote a batch to echo the "%F" passed in. It did get triggered and showed the full path...
[/quote]
Cant actually replicate this lmao
I'd guess its because its a one-line argument
i think the bug is as i recall with other programs that allow this functionality is that after it reads the first line from the batch it fails to follow the newline and read the next thing.
I'd report this behaviour on github but i think its actually intended as it works fine when executing scripts in other languages.
/e: Nvm got it to work with a simple echo %~1 line.

[quote="Galana"]
Ok, so the .exe thing was totally right.  The web-converter wasn't working right (it kept assigning a password, which always failed), but installing the app was the better way to go in the end anyway.  I've tried it with RARs & MKV, and both are performing as they should
[/quote]
Glad to help

[quote="KitKat"]
[quote="tekko"]
When I was still messing with it, I wrote a batch to echo the "%F" passed in. It did get triggered and showed the full path...
[/quote]
Cant actually replicate this lmao
I'd guess its because its a one-line argument
i think the bug is as i recall with other programs that allow this functionality is that after it reads the first line from the batch it fails to follow the newline and read the next thing.
I'd report this behaviour on github but i think its actually intended as it works fine when executing scripts in other languages.
[/quote]

They were two single file torrents from driverpacks.net that launched the .bat.

[quote="Galana"]
You're right, but not completely so.  When I was using Vuze, I had the Auto-Extract thing going, as well as Completion Move.  The Auto-Extract would occur before (or simultaneously with) the completion move - and since extracting files from RAM onto RAM is borderline instantaneous, this would finish before the NAS move was complete.  It was a beautiful system! 
[/quote]

Happening at the same time = bad design. Things get corrupted.
Read the link I attached.

[quote="tekko"]
[quote="Galana"]
You're right, but not completely so.  When I was using Vuze, I had the Auto-Extract thing going, as well as Completion Move.  The Auto-Extract would occur before (or simultaneously with) the completion move - and since extracting files from RAM onto RAM is borderline instantaneous, this would finish before the NAS move was complete.  It was a beautiful system! 
[/quote]

Happening at the same time = bad design. Things get corrupted.
Read the link I attached.
[/quote]
Since libtorrent uses a delayed atomic move now (it COPIES then DELETES) instead of a straight move what hes doing is fairly safe for large-ish files, as the RAM drive will 999/1000 times finish its own operation before the slower SSD/HDD does.

*largish meaning over 50mb aka bigger than the drives write speed per second*

Its still a bit risky to do, but who are we to tell him how to live his life ;p.

[quote="KitKat"]
[quote="tekko"]
[quote="Galana"]
You're right, but not completely so.  When I was using Vuze, I had the Auto-Extract thing going, as well as Completion Move.  The Auto-Extract would occur before (or simultaneously with) the completion move - and since extracting files from RAM onto RAM is borderline instantaneous, this would finish before the NAS move was complete.  It was a beautiful system! 
[/quote]

Happening at the same time = bad design. Things get corrupted.
Read the link I attached.
[/quote]
Since libtorrent uses a delayed atomic move now (it COPIES then DELETES) instead of a straight move what hes doing is fairly safe for large-ish files, as the RAM drive will 999/1000 times finish its own operation before the slower SSD/HDD does.
[/quote]

I am talking in general, of course.
IMO, using the ramdisk this way is bad enough. If u happened to hold a unique part of the torrent and your system crashed. Kiss completion goodbye for everyone.

"Its still a bit risky to do, but who are we to tell him how to live his life ;p." << Agreed.

[quote="tekko"]
[quote="Galana"]
You're right, but not completely so.  When I was using Vuze, I had the Auto-Extract thing going, as well as Completion Move.  The Auto-Extract would occur before (or simultaneously with) the completion move - and since extracting files from RAM onto RAM is borderline instantaneous, this would finish before the NAS move was complete.  It was a beautiful system! 
[/quote]

Happening at the same time = bad design. Things get corrupted.
Read the link I attached.
[/quote]

There was built-in protection on this - Vuze had a "delay the deletion of source until after successful move" option.  So looking at a 500mb RAR, it would start to move (from RAM to NAS) and take several seconds to do so.  While that extraction process would initialize at "around" the same time (likely a few milliseconds later) - but regardless of the delay, it could be 2-3-4 seconds - the RAM -> RAM extraction itself took milliseconds...  So it always completed before the move finished.  But between burst transfer on the upgraded NAS, and Vuze bloat, it no longer works reliably on my system.  On my friends setup with a dramatically inferior NAS, this is still fine because there's no burst, and the transfer is so slow that Vuze can take its sweet time to execute the command.

[quote="KitKat"]
Since libtorrent uses a delayed atomic move now (it COPIES then DELETES) instead of a straight move what hes doing is fairly safe for large-ish files, as the RAM drive will 999/1000 times finish its own operation before the slower SSD/HDD does.
[/quote]

Ummm, yeah...  What KitKat said... 

I need to read to the bottom before responding

[quote="tekko"]
I am talking in general, of course.
IMO, using the ramdisk this way is bad enough. If u happened to hold a unique part of the torrent and your system crashed. Kiss completion goodbye for everyone.
[/quote]

It's extraordinarily unlikely that I would hold a unique part during the download process - which is why I (auto-)move it to the NAS upon completion.  Then the NAS-based Transmission can just seed it invisibly with a dedicated hard drive.  If that craters out, then sucks to be everyone else

------------------------------------

Were there any ideas on generating only the torrent string, and not the whole file path?

[quote="tekko"]
Happening at the same time = bad design. Things get corrupted.
Read the link I attached.
[/quote]

I was talking about this link:  http://ss64.com/nt/syntax-args.html

The two lines are completely unrelated.

After playing for a few hours yesterday, seeing what all those arguments *really* do (the %~n1 example is actually wrong, and the result was almost exactly what I was looking for except for a funny quirk), it seems I may have found a "perfect" solution:

if exist "R:\TorTemp\%~nx1\*.r*" ("R:\TorTemp\WinRAR\WinRAR.exe" x -ibck -inul "R:\TorTemp\%~nx1\*.r*" "R:\") &goto:toHold
if exist "R:\TorTemp\%~nx1\*.mkv" (copy /v "R:\TorTemp\%~nx1\*.mkv" "R:\") &goto:toHold
if exist "R:\TorTemp\%~nx1\*.mp4" (copy /v "R:\TorTemp\%~nx1\*.mp4" "R:\") &goto:toHold
if exist "R:\TorTemp\%~nx1" (copy /v "R:\TorTemp\%~nxx1" "R:\") &goto:toHold
ping -n 6 127.0.0.1>nul
if exist "V:\Completed\%~nx1\*.r*" ("R:\TorTemp\WinRAR\WinRAR.exe" x -ibck -inul "V:\Completed\%~nx1\*.r*" "R:\") &goto:toHold
if exist "V:\Completed\%~nx1\*.mkv" (copy /v "V:\Completed\%~nx1\*.mkv" "R:\") &goto:toHold
if exist "V:\Completed\%~nx1\*.mp4" (copy /v "V:\Completed\%~nx1\*.mp4" "R:\") &goto:toHold
if exist "V:\Completed\%~nx1" (copy /v "V:\Completed\%~nx1" "R:\") &goto:toHold
:toHold
pause
exit

Now, there is a downside - the script takes so long to trigger & load, that there is seemingly no way to actually have it source from the RAMdrive...  So in enabling the .mkv copying, it's functionally disabled the instantaneous RAR extraction...  Damned if you do, damned if you don't.

Does it work for single file torrents?

The %~n1 example is not wrong. There's a difference between file and folder.