Please excuse faulty markdown in above. i'm not sure why it came out like that.

Well; all the problems you have uncovered have been nasty bugs in DCP-o-matic, which are now (hopefully) fixed, so I think that is positive :)

Are you just wanting to have this EndPosition written to metadata.xml so you can read it back with external tools?

To make a patch the place you probably want to look is src/lib/content.cc in the method as_xml. This is where any piece of content is expressed as XML.

Hi Carl.

Yes, that's exactly what I'm trying to do. I'm programmatically altering metadata.xml to add further content to the timeline prior to encoding. What's tricky is accurately calculating what the Position of that additional content should be. So being able to read EndPosition from metadata.xml would solve that problem.

Some use cases:

• Adding a frame/second of black at end of DCP (my current use case)
• Adding a logo end board to end of all DCPs, without having to manually add it in the GUI
• Scripting the creation of a DOM project to compile a bunch of different files (e.g. a compilation of short films)
• Other wacky stuff which is easier to do programmatically than through the GUI - e.g. crop a particular section of an input DCP, without affecting the rest

However, I think your suggestion in 0001700 - an addition to the CLI API - is a better solution than what I've proposed here. As you say, it's unnecessary to clutter metadata.xml with an extra EndPosition attribute.

That would satisfy all the above use cases, and be a neater solution.

I've opened a new issue 0001702 for this. Please feel free to close this issue.

OK, great. It may be interesting to think about other solutions; maybe extending dcpomatic2_create, or perhaps thinking about some Python bindings so that you can script this kind of thing in python.

Unless I'm misunderstanding, for me at least, dcpomatic2_create wouldn't fit my use case. I want to find out the length of DCP after user has opened the project in the GUI, set some trim, perhaps added audio tracks with maybe a different length to the original content, perhaps changed the frame rate of the output DCP from the default etc. So dcpomatic2_cli --dump is a better place for it as it can be run on a project after it's been manually altered.

Or did I miss your point?

Re: Python bindings... I'm sure this would be useful for some who use Python. Personally I'm strictly a NodeJS guy, so adding python to the mix would complicate matters. The advantage of a CLI is it's something of a lingua franca - Python, NodeJS, Rust, Bash, or practically anything else can run commands in a shell and parse stdout/stderr output.

One thing I'd like which could be easier via language bindings is to communicate with the DCP-o-matic while it's encoding e.g. sending signals to pause/resume or abort (cleanly). But possibly there are other ways to skin that particular cat. And anyway, I'm straying well off topic now...

Ah, I think I get what you mean about dcpomatic2_create now. You're asking if that command should be able to do more, like build a project from multiple source files?

To be honest, I think the amount of different options you'd need to add to the CLI in order to allow the user to do everything that's possible by editing metadata.xml might become pretty ludicrous.

For example, alterations of the project XML that I make via script include:

• Setting naming of DCP
• Adding multiple pieces of content
• Changing CPL to use for DCP content
• Positioning content in timeline
• Setting trim
• Setting crop + scale
• Setting audio gain
• Manipulating audio channel mapping
• Turning subtitles on/off
• Adjusting subtitle size/position/effects parameters

There are a lot of options!

For me at least, I'm quite happy with editing the XML. The schema of the XML is really clear and, again, XML is a lingua franca. I'm sure this wasn't how you intended DCP-o-matic to be used, but it's certainly not difficult to do it. The only real problem I've run into is this business of calculating end position of content.

Out of interest, are you aware of anyone else using DCP-o-matic programmatically? I assume most use the GUI, and I imagine the Batch Converter app satisfies the primary case for automation for most people.

PS For anyone wanting to do complicated things by hand, editing XML is often much easier than wrangling the kind of lengthy command lines you have with e.g. FFMPEG. I have to read the manual practically every time I use FFMPEG filters, for example.