Possible to get hints via command line?

[ancient-skyscraper]

Hello, new member here! I've been using DCP-o-matic for a very short while to convert films we get in a non-DCP format (like mp4) to DCP for use in projection. We've got a manual workflow in place that works pretty well, but I would love to use dcpomatic2_cli to automate parts of the work.

The hints feature of the GUI is very helpful. We'll often get videos that result in a "Your audio level is very high (on L, R). You should reduce the gain of your audio content." hint, and we can adjust the gain to make it work better. When I tried using dcpomatic2_cli on a file that triggered this hint in the GUI, the command-line version happily processed the file without giving any warnings or hints. This leads me to believe that the software is not running the same checks when used from the command line that it would run when used via the GUI.

Is there currently a way to get hints like this on the command line? I've looked through the documentation and it does not give any indication that there is an option to enable or disable checking for issues (like high audio levels) that would generate hints.

I've looked a bit through the forum, and I saw this helpful note from carl on another thread:

There are many things that you can do in the GUI that you can't do in the CLI, and there's not really a way to look at settings in a project from the CLI.

Based on the above, I think it's likely that dcpomatic2_cli does *not* currently run hint analysis (or have an option to do so manually). If that is the case, would it be possible to request that as a feature?

I've got a little bit of programming experience, but sadly I've never worked with C. It looks like the hint analysis happens in a file at src/lib/hints.cc; do you know if it would be feasible for me to learn enough about C to try and break this out into a separate executable? I'm thinking something along the lines of giving this hypothetical command the same [FILM] input as the dcpomatic2_cli command, and the new command would somehow pass that on to the hints.cc code and get either a binary return ("good" or "some hints are applicable here") or, ideally, a text string containing the output of each hint that was triggered.

(Then, in my scripting, I could use dcpomatic2_create to create the project, then run my hypothetical hints-check command, and decide whether to go on to dcpomatic2_cli based on the results of the new command. In an ideal world, I would be able to read the hints that were generated in a project with issues and, for issues where it makes sense, modify the project's metadata.xml file to try fixing them.)

But I have no idea if a roll-my-own-command concept is even remotely feasible; it could be that the dependencies and such would just get outrageously complex. Any insight on this possible solution would be appreciated!

[carl]

Hi there,

I think it would make most sense to add it as an option to dcpomatic2_create - what do you think? So you'd do something like dcpomatic2_create ... --hints and it would make the project and also scan for hints. It shouldn't be so hard to do this at the end of the dcpomatic_create.cc file, but probably quite tricky if you don't know C/C++ so well.

I added a note to the bug/feature tracker.

Best,
Carl

[ancient-skyscraper]

Wow, I really appreciate your willingness to work on it!

It's completely your decision (I don't have any institutional knowledge on this project at all), but my intuition would have been to look for it as part of dcpomatic2_cli. In my mind, that tracks closest to the GUI workflow. (I think you get hints in the GUI only after you select Jobs > Make DCP---not when you initially create the project or add media files to it. This seems to be more similar to the dcpomatic2_cli command than the dcpomatic2_create command.)

You mentioned that, "It shouldn't be so hard to do this at the end of the dcpomatic_create.cc file," which implies it might be harder to implement as part of the dcpomatic2_cli command. If that's the case, I think having it as an option to dcpomatic2_create wouldn't be a huge tradeoff if it makes it easier to accomplish on the back end.

I'm very humbled you're willing to consider a change for my benefit! Thank you!

[carl]

I see what you mean about the GUI flow, but I wonder how we would give the user the "chance" to respond if we hint in dcpomatic2_cli.

You'd set up the metadata.xml, run dcpomatic2_create, then dcpomatic2_cli which might give some hints, and we'd somehow have to ask the user whether they wanted to make the DCP anyway. That feels a bit awkward on the command line.

However, I also wonder how you'd fix things if dcpomatic2_create gave an error... it's a tricky one.

Maybe a new tool is the right way!

[Carsten]

I mean - the 'hint's window ist just a text box. Couldn't the CLI version just output that text, then offer 'abort/ignore?

[carl]

I mean - the 'hint's window ist just a text box. Couldn't the CLI version just output that text, then offer 'abort/ignore?

It certainly could... it seems a bit odd somehow to make that tool interactive, but I guess it would only be if you passed --hints or whatever.

[ancient-skyscraper]

I really appreciate all of the discussion on this! With the repeated caveat that I want to remain very humble (I don't have the full context of the architecture, etc.), I thought I would add in a couple of thoughts.

I mean - the 'hint's window ist just a text box. Couldn't the CLI version just output that text, then offer 'abort/ignore?

Another approach that could be considered: What if dcpomatic2_cli with the --hints flag just aborts without asking if any hints are found? This would avoid any need to make the CLI command interactive. If hints are found, the program could assume the user wants attempt to fix them before making the DCP (ideally, the command would exit with an exit status that makes sense). If the user has decided that they would rather not (or cannot) fix what was found, they could run dcpomatic2_cli again, but without the --hints flag. It could give a bit of guidance in the output if this happens: "Processing has been aborted because you asked for hints and at least one was found. To make this DCP, resolve the hint(s) above or run the command without the --hints flag."

This approach reduces the development effort required (I think), and it could make using the command easier. I would imagine that a common use-case for dcpomatic2_cli is scripting, and that having the prompt would make using it in a script a bit more challenging. I haven't done a huge amount of scripting, but I've often checked the exit status of a command to see if it worked or not in order to proceed as appropriate. I am sure there is a way to work with interactive programs (i.e., get a script to read STDOUT from dcpomatic2_cli and react to an "abort/ignore" prompt), but it would definitely make it a bit more complicated.

I don't know if scripting is the exclusive use-case for dcpomatic2_cli, but I would hate to see too much effort going into making it interactive when there's such a fantastic interface (the GUI) that: (a) already exists, and (b) is much better suited for interacting with the user in a meaningful way. This last point is just my two cents, though; take it for what it's worth.

However, I also wonder how you'd fix things if dcpomatic2_create gave an error... it's a tricky one.

That's a really good point that I didn't think of before you mentioned it---if you did get a hint/warning from dcpomatic2_create, would you have to delete the project folder, files, etc., and start over? It seems like dcpomatic2_create might not be the best place for a --hints option.

[Carsten]

There are hint's that are just hints - with no need to fix them. Yes, you could omit the -hints flag if you still want to create the DCP, but that would cause issues when scripting.

[carl]

There are hint's that are just hints - with no need to fix them. Yes, you could omit the -hints flag if you still want to create the DCP, but that would cause issues when scripting.

How do you mean? You mean an interactive --hints option is better for scripting than a non-interactive one?

[ancient-skyscraper]

There are hint's that are just hints - with no need to fix them. Yes, you could omit the -hints flag if you still want to create the DCP, but that would cause issues when scripting.

I can definitely understand what you are saying---I looked through src/lib/hints.cc and was able to identify a little over thirty possible hints that the software can emit (I might have missed a few). A lot of these hints are not really show-stoppers, and I can certainly see where some users would prefer to disregard them. For example, one of this hints says "Your DCP has fewer than 6 audio channels. This may cause problems on some projectors. . . ." I might happen to know for a fact that the projector I am using has no problem with DCPs with <6 audio channels and would want to ignore that hint.

That said, I have not encountered issues in my experience writing a script around a CLI tool that returns control to the shell when it cannot execute its task (in the case of dcpomatic2_cli --hints, when it cannot create a DCP from the given content without generating at least one advisory hint).

I would love to write script to run dcpomatic2_cli --hints on my project and, if it comes back with an exit status that indicates hints were found, have my script take a closer look at the output. If the only hint is the one from above about less-than-six audio channels, then my script would know that no unexpected issues were found. Then, it could run dcpomatic2_cli (without the flag) to essentially "ignore" that one hint that doesn't apply to my situation.

However, if the output from dcpomatic2_cli --hints also included something like "Your audio level is very high (on %1). . . ." in addition to the hint from above that I already expect (and is not relevant in my situation), then my script knows something is amiss. It could try to fix it (if I've coded a possible solution to that hint that can be attempted automatically), or my script could notify the end user of an unexpected issue that it cannot resolve.

I guess at the end of the day, I think it is easier to script against CLI tools that are *not* interactive than to try and get the script to answer prompts that are really geared more for a human user. But that's just been my experience... other people's experience with scripting might be much different!