Check if titles exist before processing

[jonathan-yeagy]

I've noticed when running automkv on a batch of files, sometimes, some files will have a second audio track for director's commentary and some won't. It would be nice if instead of reporting errors, it could simply skip say it's skipping the file.

INFO Running edits [{"edit":"track:a2","set":{"flag-commentary":1,"name":"Director's Commentary"}}] on example_file.mkv The file is being analyzed. Error: No track corresponding to the edit specification 'a2' was found. The file has not been modified.

This didn't cause any actual errors, it would just help with debugging to label them as skipped tracks as to not confuse them as real errors.

[ndm13]

I can see how errors in the console would be considered unexpected when a file doesn't have the correct titles. Generally speaking, it is an error because you're asking the tool to do something it cannot do, but I certainly see a use case where one could say "for all files where this track exists, run this edit" and not want errors from mkvpropedit appearing where those tracks are missing.

We could pull in mkvinfo to check if a title exists before running the edit, but after looking into the flags and output it's probably easier (and faster) to parse the error message from mkvpropedit directly. This will require adding an option to the batch file spec to hide missing title errors (allow-missing: true default false or similar) and changing the output stream from inherit to piped or otherwise filtered.

I'll look into options. This should be easier to implement after the cleanup.

[ndm13]

Having done further research:

• mkvpropedit will fail if any of the tracks being edited are missing. It will not edit the other tracks if they are present. This can be considered a bug, but is more accurately undefined behavior.
• It should be possible to read errors in real time and rerun the command to perform a correction. Specifically, the --gui-mode flag will tag any warnings or errors with #GUI#*status* for easy parsing. That combined with piped output and stream reading should allow us to watch for errors and parse out the track causing the issues.

The less efficient approach to the first point that would allow the current "let it fail" behavior would be to run each set statement separately, which would take longer and be less efficient. I'm not a fan of this approach, although we're (currently) using it for chapters because extracting/merging is a more complicated process. This will also generate more file watch updates, which isn't a big concern in a single-watcher environment but would exponentially worsen #3.

[jonathan-yeagy]

I noticed more related to this bug when testing...

When running a batch where some files make edits to multiple tracks, it will only make changes to a file in which all tracks specified are present.

Example, I have the automkv.yml file below.

batch:                                  # Every file has a root batch element
  - watch:                              # Watch as many folders as you want
      folder: .                         # Folder name is static
      files: S\d{4}\E\d{2}\.mkv         # but file name is a RegExp
    edits:                              # Edits are per-track
      - edit: track:a2                  # Specify using mkvpropedit syntax
        set:                            # Set values to update
          flag-commentary: 1            # Booleans are 1/0 as per spec
          name: Commentary              # Strings don't need any special formatting
      - edit: track:a3                  # Specify using mkvpropedit syntax
        set:                            # Set values to update
          name: Music Only              # Strings don't need any special formatting

I have a queue of files that have 1, 2, or 3 audio tracks. I would like this to simply modifying skip track a3 if it doesn't exist, rather than skipping the entire file.