Feature Request: Daemon/Watch Mode for Automatic File Processing

[yslpn]

Problem

Currently requires manual execution. Users with download automation (Sonarr/Radarr, torrents) need to run commands manually or set up external cron jobs.

Proposed Solution

Add a daemon mode to Docker container that:

• Monitors a directory for new .mkv files
• Automatically converts detected Profile 7 files
• Waits for files to finish downloading before processing

Example

services:
  dovi_convert:
    image: cryptochrome/dovi_convert:latest
    environment:
      - WATCH_MODE=true
      - WATCH_DIR=/data/incoming
      - SCAN_INTERVAL=60
    volumes:
      - /path/to/media:/data
    restart: unless-stopped

Use Case

Drop files into watched folder → automatic conversion → ready for playback. Perfect for home media server automation.

[cryptochrome]

Hey, thanks for the suggestion. I like it and just put it on the roadmap.

I have a question: What would you expect to happen when a file should not be converted (like Complex FEL)? Should I just leave it untouched, or move it elsewhere? Log messages? Also, you mentioned torrenting. Is the goal to keep seeding (e. g. retain the original file with its original filename)?

If you have any ideas around this, please share :) I am not too familiar with Sonarr/Radarr workflows.

[dzuelke]

IMO this can fairly easily be built on top of https://github.com/watchexec/watchexec

[dzuelke]

Also note that there are a lot of subtle pitfalls in general.

For instance, a downloader may continuously write to a file, and such a "watch mode" somehow needs to definitively know when that write operation is done before it starts processing.

Also, dovi_convert currently writes to the converted file to the same directory, which would in turn produce an event since a file has changed (watchexec has --on-busy-update=ignore to counter that, but then newly added "real" files also get ignored).

Finally, there needs to be some kind of queueing mechanism, so that additional changes while a conversion is running do not trigger parallel runs (watchexec has --on-busy-update=queue to counter that).

[yslpn]

I have a question: What would you expect to happen when a file should not be converted (like Complex FEL)? Should I just leave it untouched, or move it elsewhere?

Untouched.

Log messages?

The default path or the user can set a custom one.

Also, you mentioned torrenting. Is the goal to keep seeding (e. g. retain the original file with its original filename)?

Good question. I hadn't thought about that. Ideally, the user should have several options: keep the original file to distribute further, or delete the original.

[cryptochrome]

Quite a few dependencies to think about. I will likely have to introduce some kind of config file where users can change preferences, like skipping or processing simple/complex FEL, retaining filenames for seeding, etc. - So there is some complexity around this.

I like the idea though, and will probably keep it simple for a first version of it. It will require some time.

Thanks for bringing it up. It's a good feature request, and I will add it in the future.

[dzuelke]

I honestly think that this is a little out of scope for this project - the logic, edge cases, etc, will probably require more code than all the conversion stuff, but I think dovi_convert could have a wrapper for watchexec out of the box that does this.

Let's assume the user has a download manager that is able to move files after download/extraction (JDownloader, for instance, can't do this out of the box, but it's possible with scripts) so that file creations are atomic and dovi_convert can be sure it doesn't start processing a file that is still being written.

Then dovi_convert could have a "watch" command, which requires watchexec on the system (but watchexec works on Linux, MacOS and Windows, so it's a great candidate for this).

When you do e.g. dovi_convert watch --delete -r Downloads/ -o MyLibrary/, dovi_convert internally calls:

• watchexec (docs: https://github.com/watchexec/watchexec/blob/main/crates/cli/README.md)
• -w Downloads/ (or -W Downloads/ if -r is not given)
• --on-busy-update=queue (to avoid parallel runs)
• -e mkv
• --postpone (to wait for an event to actually happen before the first run)
• --fs-events=create (to only receive file creation events)
• --emit-events-to=json-stdio (docs: https://github.com/watchexec/watchexec/blob/main/doc/watchexec.1.md)
• dovi_convert convert --watchexec --temp /tmp/a/dir/watchexec/is/not/watching --delete -o MyLibrary/ --move-all

Now, any time watchexec notices a change in Downloads/, it calls dovi_convert --watchexecwhich then:

1. reads the watchexec JSON data lines from STDIN (without --debounce it'll just be a single event each time AFAIK);
2. processes each event (they already all are "file creation" events due to --fs-events=create);
3. converts the file if it is a candidate;
4. moves the file if it is already P8.

Anything that cannot be converted without confirmation will simply stay in the given directory this way, but dovi_convert watch could of course accept --include-simple etc.

Also see #32 for a related discussion on commands and options.

[dzuelke]

Happy to help prototype this if you think it's a viable approach, FWIW.

[cryptochrome]

Thanks. Good ideas! But as you mentioned, a bit out of scope - for now, at least. I will build this eventually, somehow, once the web UI project starts (will likely be part of it). So probably looking at version 9.x.