philiptn / mkv-auto

A tool that aims to remove unnecessary clutter from Matroska (.mkv) files by removing and/or converting any audio or subtitle tracks from the source video.
GNU Lesser General Public License v2.1
51 stars 0 forks source link

Forced Subtitles #27

Open ericp1337 opened 2 months ago

ericp1337 commented 2 months ago

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:

Screenshot 2024-08-25 at 9 04 02 AM

The processed file:

Screenshot 2024-08-25 at 9 04 08 AM

Thanks

philiptn commented 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.

ericp1337 commented 2 months ago

For me it's getting stuck at "Incoming files detected in input folder, Waiting..."

Screenshot 2024-08-27 at 6 34 07 PM
philiptn commented 2 months ago

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.

ericp1337 commented 2 months ago

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. 🙁

philiptn commented 2 months ago

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.

ericp1337 commented 2 months ago

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

Screenshot 2024-08-30 at 7 39 47 PM

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.

user.txt

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
philiptn commented 2 months ago

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)?

ericp1337 commented 2 months ago

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.

Screenshot 2024-09-02 at 8 56 21 PM

Thanks!