It’s all about file permissions, if the engine has the rights to delete it it will work if it doesn’t have the rights it won’t be able to delete it (windows does report an error if a delete doesn’t work)
The log states that it did delete it, but it didn’t.
Where should that error be logged if windows does say what was the problem?
Like I said above, there will be no error logged since Windows doesn’t report errors if a delete fails. It just won’t delete.
The logs says “Deleting file xxxx”, it sends the command to delete it but if windows fails to delete it it doesn’t report back hence you don’t see any errors.
Alright, my bad, I missunderstood.
I’ll try and add costum commands to delete source file with cmd.
That probably won’t work either since the custom commands run with the same permission as the mcebuddy engine. I would suggest start by settings the permission to everyone for the destination folder/temp folder and then work from there slowly restricting it to see where the hiccup lies. Also ensure that filesystem encryption is turned off.
Yeeh, for the whole drive the permission is set to “everyone” > “full access”…
Temp Folder means working directory of mcebuddy?
The service is run as administrator.
This should make sure there is permisson to all these files.
Yes
The other thing could be some other process or program has locked the file preventing MCEBuddy from deleting it (quite a common thing if you search the forum like an antivirus or some monitoring program)
That would explain why sometimes it does work and sometimes not.
Indeed there was some process locking the file when I ran it last and it failed. Then I ran again checking in system monitor what is accessing the file. Of course then there wasn’t any access.
I am trying again now, and again and check if theres something.
I am on Windows Server 2016 with no antivirus. I have not got any monitoring, but my receiver accessing the path because it is recording the files to that path, but this should not lock any files…
Well just to let you know:
Adding
CustomCommandPath="C:\Windows\System32\cmd.exe"
CustomCommandParameters="/c del /f /q "%sourcefile%""
CustomCommandHangPeriod=100
CustomCommandCritical=true
CustomCommandUISession=false
CustomCommandShowWindow=false
to my profiles gets the jobs finished. So there is something wrong with the way MCEbuddy tries to delete / overwrite the source file.
Since adding this to the profiles.conf all files get processed and the original file is replaced with the processed one.
If one wants to archive their original files instead of deleteing them (and it is not working with MCEbuddy integrated processes) you can change the customcommandparameters according to your needs. For example move of copy sourcefile to specified path.
@Goose Do you have any idea what processes involed in the MCEbuddy processing chain could be promoted in priviledges (Right click > Compatibility > Run program as administrator) in order to make it possible to force delete files ?
It’s probably a race condition, something is accessing your file just as mcebuddy tries to delete it and it fails so when it tries to move your file from the temporary folder to the source fails it’s failing with the message “File already exists”.
I noticed that your destination filename is the same as the original filename Filename.ts and that explains why the move fails if the delete fails.
Try changing the name of your destination file and if it succeeds then you know some other process is accessing it at the same time MCEBuddy is trying to delete the original file.
Yes I know. But I have been watching the whole process the whole time with a tool to check what process is accessing the source file at exactly the time mcebuddy would try to delete the source and copy the new file to the destination. It’s mcebuddyservice, only that process, every single time. When having the custom commands before that copy process this lock does not happen.
The filename needs to be the same as the original so my receiver is taking it as the one that it has recorded itself. You understand?