INTERACT FORUM
More => Old Versions => JRiver Media Center 21 for Windows => Topic started by: mark_h on May 30, 2016, 04:30:24 am
-
This has been bugging me for years now I guess...
Quite often I need to convert format, usually to extract individual files from a CUE'd album or to convert high resolution files down to a format I can use. More often than not the conversion fails on one or more tracks forcing me to rerun on the tracks that fail, which then pass on the 2nd attempt. This will happen nearly every run...
Usually the files are on a NAS during the processing, via a mapped drive. No other MC functions over this mapped drive fail, however. And it happens whether I'm playing music or not during processing.
And usually the options are "Same Folder, Replace item in Library".
Every time I think to capture a log to report it, it works. Sod's Law.
And this attempt, I noticed two fails straight away so hit "reset log" in preparation to capture and then the next 30 tracks converted, making me wonder if the logfile size is somehow implicated...?
So, with a complete lack of evidence at this point, I just wanted to throw this out there in case others have noticed and can provide some more solid information while I try to capture my own data...
-
Do you have the converter set to keep original files or replace original files?
-
Could be same issue? I'm on internal SSD mostly though. If I encode one file at time there are no failed files.
http://yabb.jriver.com/interact/index.php?topic=105091.0
-
Do you have the converter set to keep original files or replace original files?
I use both, but it's the fails on replace that are the problem, because I then have to undelete the original files to try again...
-
Could be same issue? I'm on internal SSD mostly though. If I encode one file at time there are no failed files.
http://yabb.jriver.com/interact/index.php?topic=105091.0
Could well be... a fail on conversion...
-
My guess that your issue is due to multi thread contention on file accesses.
MC surely has a scheduler thread that decides the list of files to be converted, and the scheduler starts another individual converter thread(s) to do the conversion and write the new file. And after the conversion is done, either the scheduler thread, or the converter thread does the file rename, replace, or whatever you have selected.
So I am guessing that (say) the rename, replace, or whatever, function fails because either the scheduler thread or the converter thread still has a file lock open on the file in question.
The issue may be exacerbated on slower HDDs (particularly USB HDD and NAS) where either the device or the OS may extend the duration of file locks (lock caching) for performance reasons..
-
My guess that your issue is due to multi thread contention on file accesses.
MC surely has a scheduler thread that decides the list of files to be converted, and the scheduler starts another individual converter thread(s) to do the conversion and write the new file. And after the conversion is done, either the scheduler thread, or the converter thread does the file rename, replace, or whatever you have selected.
So I am guessing that (say) the rename, replace, or whatever, function fails because either the scheduler thread or the converter thread still has a file lock open on the file in question.
The issue may be exacerbated on slower HDDs (particularly USB HDD and NAS) where either the device or the OS may extend the duration of file locks (lock caching) for performance reasons..
Sounds like it could be tricky to fix... fingers crossed for some dev magic!
-
My guess that your issue is due to multi thread contention on file accesses.
MC surely has a scheduler thread that decides the list of files to be converted, and the scheduler starts another individual converter thread(s) to do the conversion and write the new file. And after the conversion is done, either the scheduler thread, or the converter thread does the file rename, replace, or whatever you have selected.
So I am guessing that (say) the rename, replace, or whatever, function fails because either the scheduler thread or the converter thread still has a file lock open on the file in question.
The issue may be exacerbated on slower HDDs (particularly USB HDD and NAS) where either the device or the OS may extend the duration of file locks (lock caching) for performance reasons..
I think this could be it. When this happens MC leaves temporary converted files behind which seem to be fine so I would seem that renaming process fails. I'm just using Foobar2000 to convert my files as it never fails. (I'm not on NAS)