View Bug Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001362||DCP-o-matic||Bugs||public||2018-09-06 13:12||2018-10-17 20:10|
|Platform||Mac||OS||Mac OS||OS Version||10.12.6|
|Summary||0001362: "UL Dictionary: unknown UL" stderr from dcpomatic2_create|
When creating DCP-o-matic projects from MXF video files using
UL Dictionary: unknown UL: 060e2b34.04010101.0d010201.01010900
This output appears for all MXF files I've run
The same files did not produce any stderr output on DCP-o-matic 1.83.0 running on Ubuntu.
Aside from this, the files seem to be fine - FFMPEG reports no problems with them when transcoding, no artefacts are visible in VLC, some files I have successfully made DCPs from using DCP-o-matic 1.83.0 in the past.
What does this output mean and is it anything to worry about?
(DCP-o-matic 2.12.8 on Mac OS Sierra 10.12.6)
|Tags||No tags attached.|
|Estimated weeks required|
|Estimated work required||Unknown|
That's strange; I can't reproduce that here. Are you just doing
dcpomatic2_create --content-ratio 185 some_file.mxf -o metadata.xml
or something similar?
Only difference from that is that I'm also using the
Here's an example command line:
'/Applications/DCP-o-matic 2.app/Contents/MacOS/dcpomatic2_create' -n 'True North' -c SHR --content-ratio 185 -o '/Volumes/archive 3/temp/159004' '/Volumes/archive 3/assets/True North/Source video 2/True_North_270917_SURROUND.mxf'
Shall I send you one of the offending MXF files?
PS Think most if not all of the MXF files I have are Avid DNxHD codec.
Ah, they're not DCP MXFs... in that case I think the errors are nothing to worry about. DoM tries to load your MXFs as DCP MXFs first so that it can treat them differently. When that fails (giving the errors you see) it will pass the content to FFmpeg.
We should try to quell those console errors.
Ah that's interesting, and makes sense.
To make sure nothing untowards slips through, my system currently throws an error if DCP-o-matic emits any stdout/stderr output.
I imagine it might be a pain to suppress the output as, at the point it is emitted, it's not known whether it's "genuine" errors or not (as whether the MXF file is from a DCP or not is not yet known). This is just me taking a guess, I have no real knowledge here.
But if that is the case and quelling the console output is difficult, it would be helpful if there was some other output to contextualise the errors. e.g. first emit a line "Checking if MXF is from DCP" and then after "MXF is not from DCP". Then the output in between could be identified as relating to the MXF examination process and safely ignored. Does that make sense?
If it's OK with you, I'm sending you an MXF file that causes this output in case that's useful.
Fixed in f12587df699a72655230ac737ece31a5436a5a5e which will be in 2.13.49.
Let me know if a backport to 2.12.x would be useful.
|2018-09-06 13:12||overlookmotel||New Bug|
|2018-09-06 13:41||carl||Assigned To||=> carl|
|2018-09-06 13:41||carl||Status||new => feedback|
|2018-09-06 13:41||carl||Note Added: 0002657|
|2018-09-06 16:09||overlookmotel||Note Added: 0002658|
|2018-09-06 16:09||overlookmotel||Status||feedback => assigned|
|2018-09-06 16:22||overlookmotel||Note Added: 0002659|
|2018-09-06 16:26||carl||Note Added: 0002660|
|2018-09-06 16:37||overlookmotel||Note Added: 0002661|
|2018-09-07 13:07||carl||Status||assigned => resolved|
|2018-09-07 13:07||carl||Resolution||open => fixed|
|2018-09-07 13:07||carl||Note Added: 0002662|
|2018-10-17 20:10||carl||Status||resolved => closed|