This project has moved. For the latest updates, please go here.

can't prevent reconversion

Jan 29, 2016 at 4:09 PM
Edited Jan 29, 2016 at 5:58 PM
While trouble shooting a different problem, I set my monitor path to be:
\server\general-temp\
where I had copied a few shows and movies from my main HDHomeRun DVR recording folder.
My destination path, though, I kept the same as always:
\server\HDHomeRun\mcebuddy_finished\

So when I finally got the last problem fixed, mcebuddy converted the few shows and movies I had placed in that general-temp folder and placed the finished converted files in
\server\HDHomeRun\mcebuddy_finished\
where they still reside.

So now, I have changed my monitor path back to my main HDHomeRun record path:
\server\HDHomeRun\
with options to monitor subfolders, which include
\server\HDHomeRun\movies\
\server\HDHomeRun\mcebuddy_finished\
and several subfolders named for their TV show titles, like for example
\server\HDHomeRun\The X-Files\
EDIT: All the original copies of the test files that I had copied to the other monitor location for testing, are still in this folder structure, but I thought that would be okay, since mcebuddy is supposed to be able to ignore files it has already converted (by checking file names in the destination path).

I have checked the "skip reconversion" and "check history" boxes in the expert settings for the conversion task, and yet every time I click start, the first file mcebuddy adds to it's queue is one of the movies it has already converted. I thought maybe it was scanning the destination path accidentally (since the destination path is a subfolder of the monitor path) but it's not, the log shows that it picked up the original recording from the monitor path, EVEN THOUGH the movie is already converted (with the same name it will use again since I haven't changed the naming instructions) sitting in the destination path.

Any thoughts on why it's doing this? Did I accidentally set some switch or checkbox to force it to reconvert?
Jan 29, 2016 at 4:11 PM
Here's a log from a recent reconversion that I stopped a few seconds after it started:
ftp://files.mcebuddy2x.com/upload/kieranc_example_movie.log
Coordinator
Jan 29, 2016 at 7:01 PM
It's not the same name, it looks at the full path not just the filename. Don't check any boxes and it won't reconvert any converted files (original or converted) (as long as the FULL path is identical).

Jan 29, 2016 at 8:16 PM
OK, I'll try that when I get home this evening.
Why are the boxes there, if the default is to not reconvert?

Also, the full path of the destination file is identical, as I didn't change that. I only changed the monitor location.
Coordinator
Jan 29, 2016 at 8:48 PM
See the pop up help.

Jan 30, 2016 at 4:02 AM
Well, I un-checked "skip reconversion" and then started mcebuddy again, and it immediately added the same movies to the queue: movies it has already converted. Not just the same movie; it's the exact same file (just in a different folder). And also, the converted file is in the exact same destination folder and obviously named exactly what mcebuddy would name it again.
Something seems to be broken, or I'm missing some switch or check box somewhere.
Thanks for your continued help! :)
Jan 30, 2016 at 4:26 AM
OK it just occured to me what might be going on...
Here's my destination path:
\server\HDHomeRun\mcebuddy_finished
However, here's my custom rename pattern:
%ismovie%<Movies\%showname% (%airyear%),%issport%<Sports\%showname%\%showname% %recordyear%-%recordmonth%-%recordday% - %recordhour%%recordminute% - %episodename%,%ifseason%<TV Shows\%showname% (%premiereyear%)\Season %season%##\%showname% (%premiereyear%) - S%season%##E%episode%## - %episodename%,Special\%showname%\%showname% %recordyear%-%recordmonth%-%recordday% - %recordhour%%recordminute% - %episodename%>>>
So, these movies are actually ending up in
\server\HDHomeRun\mcebuddy_finished\Movies\
and the TV shows in
\server\HDHomeRun\mcebuddy_finished\TV Shows\

Could it be that mcebuddy is only looking as far as the root destination folder:
\server\HDHomeRun\mcebuddy_finished\
and therefore doesn't see the converted recordings in the subfolders?

If that's the case, is there a way I can tell it to check for previous jobs in subfolders? Or check the history? I would think checking the box "skip reconversion" and "check history" would be exactly what I want here, but apparently that's not the case...
Thanks...
Feb 3, 2016 at 5:27 AM
KieranC wrote:
Well, I un-checked "skip reconversion" and then started mcebuddy again, and it immediately added the same movies to the queue: movies it has already converted. Not just the same movie; it's the exact same file (just in a different folder). And also, the converted file is in the exact same destination folder and obviously named exactly what mcebuddy would name it again.
Something seems to be broken, or I'm missing some switch or check box somewhere.
Thanks for your continued help! :)
KieranC, did you miss the part where rboy1 said "(as long as the FULL path is identical)."

Don't move the file to a different folder.

Ie:
C:\somefolder\movie.avi
Do recording.
Move source file to:
C:\somenewfolder\movie.avi
MCEBuddy will reconvert.

So the only way it won't reconvert, is if the movie STAYS c:\somefolder\movie.avi, and no path changes or filename changes.

My apologies if I misunderstood.
Coordinator
Feb 4, 2016 at 5:55 AM
HankHeavens wrote:
KieranC wrote:
Well, I un-checked "skip reconversion" and then started mcebuddy again, and it immediately added the same movies to the queue: movies it has already converted. Not just the same movie; it's the exact same file (just in a different folder). And also, the converted file is in the exact same destination folder and obviously named exactly what mcebuddy would name it again.
Something seems to be broken, or I'm missing some switch or check box somewhere.
Thanks for your continued help! :)
KieranC, did you miss the part where rboy1 said "(as long as the FULL path is identical)."

Don't move the file to a different folder.

Ie:
C:\somefolder\movie.avi
Do recording.
Move source file to:
C:\somenewfolder\movie.avi
MCEBuddy will reconvert.

So the only way it won't reconvert, is if the movie STAYS c:\somefolder\movie.avi, and no path changes or filename changes.

My apologies if I misunderstood.
You got it! That's the only reliable way to do this.
Feb 4, 2016 at 4:25 PM
Edited Feb 4, 2016 at 4:27 PM
I didn't move anything. The only thing I changed is the folder that MCEBuddy is monitoring. Here's a simplified sequence of events:
1) hdhomerun records movie1.mpg to
x:\hdhomerun\movies\

2) I copy movie1.mpg from
x:\hdhomerun\movies\
to
x:\test\

3) I setup mcebuddy to monitor
x:\test\
and save conversions to
x:\hdhomerun\mcebuddy_finished\

4) mcebuddy sees movie1.mpg in
x:\test\
and converts it and saves it as
x:\hdhomerun\mcebuddy_finished\movie1(year).mpg

5) I modify the settings for mcebuddy by changing ONLY the monitor folder, to
x:\hdhomerun\movies\
where the origninal recording file movie1.mpg resides.

6) mcebuddy starts to reconvert movie1.mpg, despite the fact that the converted file exists in the exact same path that mcebuddy will attempt to write to, namely:
x:\hdhomerun\mcebuddy_finished\movie1(year).mpg

So the destination path and file are there, exactly the same as how mcebuddy will write the new reconversion.

Are you telling me this is the expected / normal behavior?

I would think that if a file exists with the exact path&name that mcebuddy is trying to write to, then mcebuddy would decide that this task is a reconversion and not do it. Am I mistaken?

Thanks...
Feb 4, 2016 at 10:35 PM
OK, I see from another thread (the retaining metadata for hdhomerun thread) that you've stated there too, that this is the normal behavior.
When you kept stating that it needed to be the same path I thought you meant the path to the destination file & name, not the source filepath/name.

So going back to the checkboxes for "skip reconversion" and "check history" ... why don't those work for me in this case? I have read and re-read the pop-up help, and from the description it sounds like those options are exactly what I want, however they don't seem to do anything for me.

Thanks....
Coordinator
Feb 5, 2016 at 4:58 AM
Yes that's expected behavior. See my earlier statement, MCEBuddy will not reconvert the original or converted destination file. It is not converting the destination file. It overwriting it. Two separate things, a big difference between converting the destination file and overwriting it.

There's an option in expert settings to not convert if the destination file exists. Check that option if you want that.

It's a very powerful program, just spend some time exploring all the options.

Feb 5, 2016 at 5:20 AM
I know it's a very powerful program, don't get me wrong I am a big fan. I've been using the program for almost 3 years, and paid for early access 2 years ago.

I'm just trying to understand some of the features that I've not had to use before.
I know it's not converting the destination file, I know it's trying to overwrite it. It's trying to reconvert the source file even though the destination file exists already.

As I stated in my first post, I tried the expert option to "skip reconversion" and it didn't work. You seemed to imply in your first answer above that it was not intended for my situation, but it sounds to me like it should work in my situation. I mean, the destination file definitely exists. But mcebuddy doesn't seem to be checking for the destination file.

Thanks...
Feb 5, 2016 at 5:21 AM
rboy1 wrote:
You got it! That's the only reliable way to do this.
You could md5/hash the file, then path wouldn't matter. MD5 of a large file would take more time and more memory, though.
Feb 5, 2016 at 5:24 AM
HankHeavens wrote:
rboy1 wrote:
You got it! That's the only reliable way to do this.
You could md5/hash the file, then path wouldn't matter. MD5 of a large file would take more time and more memory, though.
Thanks, I think... I have no idea what that means. :) LOL
Coordinator
Feb 5, 2016 at 2:19 PM
See the conversion task expert settings since this is related to the output file.
Monitor task settings have relevance to the input file