I am now at a loss.
Its not possible to ingest the DCP into the cinema's system by any means possible.
For testing purposes I have created two short versions of the DCP in SMPTE and INTEROP and sent to them.
But they had no luck to ingest those short files.
I've downloaded the packages that you've send and after checking it in DOM Player it truned out the XML files (the CPL, PKL and ASSETMAP) are malformed (in both versions).
After repacking the SMPTE DCP on my version of DOM it shows no errors. It's strange cause I don't see any major differences between both files. Here is the comparison of Composition Playlist between original and repacked DCP: https://www.diffchecker.com/wuM4d935
Thanks guys for having a look.
Goku, yeah from the diff you made it looks like there is no major difference explaining the problem.
Carl, they have used the usual tools - in this case 7-zip.
Carsten, the files have been downloaded at their site from the same link I provided here and internally they unpacked and copied it to their Dolby library. From there then I think they are ftp-ing to the projector systems.
We did not get a more specific error message, other than the file could not be verified / refused to play.
I wish I could give you a better error message, but we also did not want to interfere too much with the cinema's business, as they have been very kind and generous to let us make all these testings. And nowadays their technician is not always at the place available, so I had nobody to ask some more specific questions.
What I did then is to start all over from scratch.
On my other workstation I've an older DOM version (2.14.x) with that I used to create INTEROP DCPs which played flawlessly in many cinemas over the last years. So I used that as a reference point.
I converted my DNxHD MXF master into a ProRes MOV with no audio and prepared the 5.1 24bit audio as a separate WAV. I don't think that this really matters for the conversion, but I was desperate.
Then I created a new DCP project on my newer DOM (2.16.18) with those assets. I also made sure to remove everything from the metadata I had inserted before (like Studio = flyoli & LOOM / Facility = LAUFBILDkommission) but added the Territory (= AT) and Rating (= NR), so also the ISCDF naming would be similar to what used to work.
Then I let DOM 2.16.18 create the INTEROP DCP with 100 Mbit.
Create a copy onto the other workstation.
Create a new DCP project in DOM 2.14 and import the DCP assets. Create another INTEROP DCP from that.
Put both versions onto a 1TB USB stick and drove to the cinema. The DCP from DOM 2.14 got ingested and verified without an error. The DCP from DOM 2.16.18 was still importing when we left.
Tomorrow morning we will come back to the cinema for a screening - hopefully both versions will work. If not then we will have to investigate what's the difference and what went wrong.
Carl, is there anything special I should provide you with in the case it turns out we can't play the files from 2.16.18? So you can replicate?
Last edited by freezer on Thu Aug 11, 2022 8:32 am, edited 1 time in total.
I guess there must have been an issue with character translation during transfer or ingest. Often happens with FTP in ASCII mode. It is typical that only the XML files then fail.
This will not happen when storage media is used for the transfer. Except when e.g. a weak ext2/ext3 writing software/driver is used (we have seen loads of issues with Paragon). I usually ZIP DCPs, put them on a Drop-Box, unpack them with 7-ZIP on a cinema PC, then ingest through SMB or FTP (binary mode) to the cinema servers. Never had an issue in 10 years.
Whatever - it certainly is not a DCP-o-matic issue, and also not an Interop vs. SMPTE issue.
For DCPs larger than 4GB, one should use 7-ZIP for unpacking, as it handles large files/64Bit ZIP files properly. This is often a problem for shorts, as they usually grow larger than 4GB. We routinely download DCP trailers from different sites, hundreds per year, and never have issues - but I have rarely seen a trailer larger than 4GB - not even 4k, 3D/48fps, or ATMOS. Yes, they do exist, but the few mastering/service companies assembling these packages know what they do and use proper ZIP tools that deal correctly with 64Bit archives.
I guess you were just 'unlucky' in this case. I will still try to ingest these two DCPs on our two systems. What they could have tried is to download the test DCPs to a computer and unpack them to a plain vanilla USB-Stick, and ingest locally on the server, avoiding the FTP transfer. Also, another download sometimes helps, although in this case, 7-ZIP error checking should have caught any transfer issue.
Okay - RAR in a ZIP Archive. Another potential source of error when they unpack. Not necessary. One folder per DCP -> ZIP.
Still, I can't find any issue with these two DCPs, it must be a 'secondary' problem - transmission, packing/unpacking, transfer, ingest, etc. The filemail location carries intact files. Or, in other words, it's not your fault.
The first attempt was the full feature in a ZIP file, packed by WinRAR 6. Unpacked at their PC with 7-zip and ingested onto the server.
The second attempt was the pure DCP, on a USB stick and ingested onto their system.
First they tried the stick directly into the projector system, then on the server.
The two test files are in a RAR container, but get zipped by the filemail system, if you try to download both at once by clicking on "Download All".
When downloading them one by one by clicking on the file names below, they don't get zipped by the filemail server.
So maybe that could be a problem introduced for the testfiles.
Still, I can't believe that the RARs would extract then without throwing an error if one uses the WinRAR tool.
EDIT 1: I just downloaded both test files at once (ZIP) through a browser and WinRAR throws an CRC error.
Then downloaded each file after another through a browser and WinRAR throws a CRC error for both RARs.
Finally I downloaded both files via the filemail desktop app and both RARs open flawlessly.
So there must be the browser download flawed somehow...
EDIT 2:
And it gets even stranger: I have now re-downloaded the files through the browser and now both open flawlessly. Regardless if I load them individually or both at once in the ZIP container.
