New problem with scheduled task involving my own script and CLI

Support for Windows users
Post Reply
svenm
Posts: 2
Joined: 20 Dec 2018, 08:18

New problem with scheduled task involving my own script and CLI

Post by svenm »

Hi, my scenario is that I have a network share with incoming videos, which I want to re-encode and rename while placing them in another network share. For this purpose I wrote a quick Console app in C# (instead of a batch file), and have this app run every 3 hours via Task Scheduler in Windows 10. This script finds files with certain file extensions in the input directory, runs them through Handbrake via its CLI (with encoded files being generated to the output directory), cleans up the input directory to delete successfully processed files and any leftovers, and finally runs FileBot CLI in the output directory to "clean up" the filenames and make them more palatable to Plex Server.

This has worked well for months, but several days ago the FileBot call, which is initiated via Process.Start(), has been failing with an exception.

Here's the information that seems relevant:
  • This is a standard C#/.NET Console app.
  • Handbrake and FileBot is being invoked via System.Diagnostics.Process class.
  • The command line for FileBot is: filebot.exe -rename "{TargetPath}" --format "{n} - {s00e00.lower()} - {t}" --lang en -non-strict
  • The exception is triggered upon call to Process.Start()
  • The call to Handbrake CLI is continuing to succeed.
  • If I launch the program exe manually (either from CMD or by simply double-clicking it, it works OK). It only fails when started by Task Scheduler.
  • Task Scheduler is set to trigger every 3 hours, to run whether user is logged in or not, and to run with highest privileges. It runs under my own login, which is a local administrator of the machine. Generally the machine in question wakes up to run the task, then goes back to sleep.
  • Exception: System.ComponentModel.Win32Exception (0x80004005): A specified logon session does not exist. It may already have been terminated
    at System.Diagnostics.Process.StartWithCreateProcess(ProcessStartInfo startInfo)
    at System.Diagnostics.Process.Start()
    ...
  • I've tried turning on UseShellExecute (even though this means I cannot collect the standard output and standard error from the FileBot processing run)...with no change in behavior
  • I've tried supplying user credentials to the Process.ProcessStartInfo (including loading user profile), even though Task Scheduler is already starting the exe under my user context...with no change in behavior.
  • I've tried instead starting cmd.exe with "/C" parameter, with the rest of the command line passed to it, and that caused cmd.exe to simply print a message that it could not start the program. This works in a console window, but not with the scheduled task.
  • Finally, I tried launching one of the two "real" filebot.exe's from inside AppData, even though I know this is not the correct way to launch vs. the execution alias (just "filebot.exe")...with no change in behavior.
I believe this has something to do with the fact that this is a UWP/Store app, and that the process trying to start it is in a non-Desktop context (a scheduled task that runs even if the user is not logged on). I don't know what has changed in the last few days, except my system did update to the October Update of Windows 10. I've searched StackOverflow and other forums to try to find workarounds for launching UWP/Store apps from a .NET app, and most workarounds seem to involve taking advantage of protocol handlers (I don't think FileBot has any registered handlers, though), or some pretty convoluted Win32 stuff via P/Invoke. Before I go down this rabbit hole any further I was hoping there's something simple I've missed.
User avatar
rednoah
The Source
Posts: 22923
Joined: 16 Nov 2011, 08:59
Location: Taipei
Contact:

Re: New problem with scheduled task involving my own script and CLI

Post by rednoah »

1.
System.ComponentModel.Win32Exception is a C# error which seems to cause things to fail long before any FileBot is executed. This could very well be an issue with how the Microsoft Store works, since the Store is responsible for copy-protection, there might be something going on behind the scenes that only works if the user session matches the user that has purchases the application.

I wouldn't waste time on this, it's not worth your time. I'll send a free license for the normal classic W32 application if you want:
viewtopic.php?f=8&t=9517


2.
svenm wrote: 20 Dec 2018, 23:13 Finally, I tried launching one of the two "real" filebot.exe's from inside AppData, even though I know this is not the correct way to launch vs. the execution alias (just "filebot.exe")...with no change in behavior.
You probably didn't get this far, but assuming the W32 executable is actually run, directly and not via Desktop Bridge, then it won't have a UWP context, and the internal license check will fail.
:idea: Please read the FAQ and How to Request Help.
svenm
Posts: 2
Joined: 20 Dec 2018, 08:18

Re: New problem with scheduled task involving my own script and CLI

Post by svenm »

Got it, will follow instructions to get the "classic" license.
Post Reply