PostCustomCommand with Mapped Drive/UNC Path

Feb 16, 2014 at 3:13 PM
I have a PostCustomCommand that is setup to access files on a shared network location. However, when I try to access files within the batch file via the PostCustomCommand it says that the path cannot be found. If I run the batch file interactively as Admin it works fine, but not when run through PostCustomCommand. I am currently running 3.2.15 Beta and I have tried using the PostCustomCommandUISession as True and False, and either way the batch file fails because it cannot find the file path. I have tried using both mapped drives and via UNC path and neither way works. The shared location uses anonymous authentication so no user credentials are required.

I have tried using the MCEBuddy "Network Connection User Credentials' functionality just to see if I can get it to access anything on the network share, and that does seem to work. Could this functionality be extended to the CustomCommand functionality to utilize this feature as well? Is there something else that I could implement to make this work?
Feb 16, 2014 at 5:14 PM
Post you conversion log.

Also keep in mind post custom command works through a service context and mapped drives don't work there.

Use a UNC and enter the credentials for the UNC under Settings -> Expert settings

For now you will also need to manually add one file from the UNC to activate the credentials. Next release I'll ensure mcebuddy connects the network path when it starts using the general network credentials

Feb 17, 2014 at 1:51 PM
I just realized since MCEBuddy doesn't know which UNC your custom command i referring to, there is no way for it to authenticate/establish a connect to your custom command UNC.
Again like I said, since mapped drives don't work in service space, you need to use UNC in your custom commands.

So here is the simple solution. Create a Monitor task pointing to the UNC path used in your custom command and enter the Authentications details for the UNC path/machine. Set the File Types filter to *.xyz (no such files exist I'm assuming) so it won't pick up any files.

This will force mcebuddy to connect to the UNC and authenticate with the supplied credentials and thus when your custom command runs the UNC is ready to work since it has been authenticated already when MCEBuddy starts the monitor tasks.

Marked as answer by rboy1 on 2/17/2014 at 6:51 AM
Feb 19, 2014 at 12:54 AM
Thanks for the super fast response! I did what you asked for with the configuration and it is still not working and throwing the same error, but I can see from the logs that it is trying to get the dummy monitoring task that you recommended. I tried to include the conversion log, but it is very large and won't include the entire log. How would you recommend that I get the logs posted?
Feb 19, 2014 at 1:52 AM
zip and upload to dropbox or mediafire and post hte link here

Feb 19, 2014 at 2:15 AM
Thanks for direction.

Here's the link to the conversion log:

Here's the link to the mcebuddy log:

Let me know if you need anything else.

Thanks again!
Feb 19, 2014 at 4:04 PM
These logs are helpful. So a couple of points to note here which are causing the issue:

1. You log file shows that you have 2 network paths defined in your configuration file:

2014-02-18T19:31:57 MCEBuddy.Engine.QueueManager --> Attempting to connect to network share \\\freenas\Media\TV Shows\At Midnight
2014-02-18T19:31:57 MCEBuddy.Engine.QueueManager --> Attempting to connect to network share \\\freenas\Media\TV Shows\
Both network paths are pointing to the same server and it is being authenticated twice (once in your monitor task and once in your conversion task). You should NOT authenticate the same network location twice, once is enought, so your monitor task is redundant.
2. Your network share path \\\freenas\Media\TV Shows\ is incorrect. Network share paths don't end in slash '\'. That's why the second authentication is failing. I will put a check for this in the next build
3. You are using PostCustomCommandUISession = True in your Custom command parameters. Why? I hope you're read the documentation carefully. This causes MCEBuddy to use the active logged in users's session to run the command. That has SERIOUS implications, like network driver mapped by MCEBuddy in SERVICE Session are no longer available in USER session. This is ONLY to be used if you are running a program that needs access to DirectX/hardware API's.
Point 3 is likely why your custom command unable to access the network share.

Marked as answer by hafnera on 2/19/2014 at 6:40 PM
Feb 20, 2014 at 1:40 AM
That resolved the issue and the script completed without errors! Thank you for your assistance in resolving this. It is much appreciated.