Open ericp1337 opened 2 months ago
This problem should be fixed in the upcoming v2.0 release, with FORCED_SUBTITLES_PRIORITY
being set to first
(which is the default setting). Can you test your file using this dev build of mkv-auto?
cd <mkv-auto-repo location>
rm mkv-auto.log
git pull
git checkout dev
git checkout 8cd4ab7
./mkv-auto.sh --build --copy --no-cache
It should be noted that there are quite a few changed compared to v1.0.3, so I would recommend that you check the release notes before testing the dev build. I have added a draft of v2.0 here.
For me it's getting stuck at "Incoming files detected in input folder, Waiting..."
Can you try to delete any folders named tmp
and .tmp
? Or if you have a custom TMP folder, delete that one as well. Make sure that the output folder is also empty.
That error is being printed when the get_mkv_info()
function fails to read the metadata, which in most cases is due to a file being copied. But in this case there might be some file permissions errors when Docker tries to access the same folders that the user previously has written to.
Yeah, I re-cloned the repo down into a new folder starting from scratch, re-built the docker image, and it's still stuck at that message. I also tried a completely different file and it still does the same thing.
I was hoping the most recent commits would also help fix it, but still no luck. 🙁
I have tried to replicate the issue you are having, but it seems to work fine both in Windows (added mkv-auto-dev.bat
in commit c73d33c
), WSL (both Linux native disk in /home/
and Windows disks in /mnt/d/
) as well as native Ubuntu Linux in a VM.
What OS are you running? If you are running Windows, are you using an older version of Docker Desktop? Are you using the WSL 2 based engine? If using WSL, are you using a type-2 distro? I know that older version of Docker Desktop had some trouble with volume mounting in Windows.
I'm just using an Ubuntu 24.04 VM. I just tried setting up a brand new VM and still stuck at that message.
I added some print statements in the get_mkv_info
function and noticed the first time it's run the command is successful, but then when it runs the second time after that the filename path seems to be messed up where it's just point to files/tmp
After that I removed my user.ini
file, so it uses the default settings and I noticed it worked after that. So, it seems like somewhere something is breaking with the settings I'm using. I've attached my settings file that's causing the issue, so you can try and figure out what setting I'm using that's causing the issue.
EDIT: It looks like using the following setting is what's causing the issue.
# FILE_TAG: If set to 'default' no existing tags will be removed/changed,
# replace 'default' with '-<your tag here>' to change it (like '-TAG')
FILE_TAG = default
You are right, I checked the remove_clutter_process()
function and in remove_clutter_process_worker()
the return data for updated filename was initialized as updated_filename = ''
. Normally this would be replaced by the filename without a tag, but when no changes needed to be made the worker simply returned an empty string. The fix was quite simple:
updated_filename = ''
to
updated_filename = input_file
Does the original issue (forced subtitles) now work in the latest dev build (ec64b1c)?
Yes, the forced subtitles seem to be handled correctly now in with the few movies I've tested it with on the latest dev build.
Thanks!
I just tested some files which contain forced subtitle tracks and it doesn't seem like they are handled correctly.
After the file has been fully processed it looks like the forced flag is being removed and sorted after the full subtitle track rather than maintaining the order from the original file. Ideally the forced subtitle track should be sorted before the full track.
Here's the original file:
The processed file:
Thanks