i3laze wrote:1. Particular transmission-2.93+-r96926a8337-x64 build has start time over 180 sec+ (during this time GUI is inaccessible): ...
This seems to be an issue affecting all released and unreleased Windows builds. Disabling port forwarding helps and it's on our TODO list to fix it properly.
i3laze wrote:2. Working Path for everything inside a script is C:\, and without full path specified script may be fired only when placed in C:\ directly.
I expect Working Path to be Transmission Config Folder, not C:\.
Why do you expect that? The working directory is not documented anywhere and so you shouldn't expect anything. On *NIX systems, it's currently set to /, so it's natural to set it to the root of the disk on Windows as well. The Transmission configuration directory is there for Transmission itself, what would be the point of setting it as working directory for users' scripts? Generally speaking,
without full path specified we don't know which script exactly you want to execute, so putting it into C:\ is not a good idea either (if it works now it doesn't mean it'll work tomorrow since, again, the behavior is not documented).
i3laze wrote:3. Log file says Calling script "oncomplete.cmd" successfully every time no matter file exists or not.
Is there anything after that line in the log file to suggest that the execution failed?
i3laze wrote:4. Although generic .exe does launch, I'm unable to fire a PowerShell script (I've converted one from Python) at all
. I've tried
all means:
powershell.exe does launch when placed inside .cmd, but
powershell.exe /file "fullpath" or
-file "fullpath" does not.
When you say "generic .exe does launch", does that mean it launches when specified directly as a completion script or from within the batch file specified as a completion script? What are you doing to verify that the script launches or not? Did you try a very basic script that e.g. prints a line to a file? Did you check %errorlevel% in the batch script after attempting to run powershell? Did you try redirecting powershell's standard output and error streams to a file to see if it prints an error or something? Also note that when running Transmission daemon as a service the execution environment is a bit different, e.g. there could be issues if the process you're launching is interactive (prompts for user input in the terminal, shows windows, etc.), or if it accesses drive letter-mapped network shares, or who knows what else.