Festival unable to ingest DCP

[bcoleman]

Hi All,

Film festival is reporting they cannot ingest a DCP I made in DCP-o-matic 2.16.71. I checked the DCP in DCP-o-matic player as I always do, and all looked good. I sent the DCP via uncompressed MASV.io file share as usual as well.

I am running mac os 12.7.1

Here is the message I received from the festival:

"I was able to upload the 110GB file onto a NTFS External Hard Drive, unzip the files and our server recognized the file but would not ingest. I purged all the MAC file names, still wouldn’t take. The last thing I will try is to put the film on a FAT32 drive to see if that will handshake better with our Dolby server, but can’t do that until tomorrow"

Client has since switched to bluray for this screening due to time constraints, so I will not get to understand what happened beyond the above message. I would really like to understand what could have happened though for the future if anyone has any ideas!

With appreciation,
Brad

[carl]

It sounds like you've used this workflow successfully before (MASV.io etc.)?

Was the DCP 24 frames per second?

[bcoleman]

I have indeed, thanks Carl.

DCP was 24 frames per second

Also attaching DCP-O-matic player info, if that helps at all

Screenshot 2024-09-11 at 11.55.47 PM.jpg

[IoannisSyrogiannis]

The info shared is too vague. With no error message, it could be anything.
For all that was shared (and given that it's a festival), it might as well be that the server has no free storage space for the entire package...

One thing is evident, that the person writing back to you does not know that FAT32 file systems may not have files bigger than 4GBs, so (unless the DCP has a whole bunch of really short reels) it's impossible to fit those 110GBs in such a drive.
If they meant exFAT, I doubt that even IMS3000 can read out of that. I know for a fact that all the previous Dolby servers can not.

The SMPTE Bv2.1 errors should not have anything to do with a server's incapability to ingest.
If you get only those errors when you download what you uploaded, if I were you, I would question the download (1), copy to external hard drive (2), ingest (3), troubleshooting expertise of the operator (4).
I could bloat the thread with cases that support what I write, but that would be beyond the scope of the thread itself.

[Carsten]

I can only guess that something went wrong during the transfer/copy process.

[rl1983]

I'll bet its an issue with the zip archive.

I'll suggest again for everyone NOT to zip your DCPs when you are submitting them. It's not a benefit to anyone, and 3/4 of them always come in corrupt.

Yes, 7Zip apparently can zip DCPs up where they don't end up corrupt, but not everyone knows that. We generally require filmmakers do not zip their films when sending them in and for the most part, I think that's been pretty successful.

[Carsten]

Using 7ZIP on the receiving side is probably the solution here.

[IoannisSyrogiannis]

[...]
I'll suggest again for everyone NOT to zip your DCPs when you are submitting them. It's not a benefit to anyone, and 3/4 of them always come in corrupt.
[...]

I will agree with the first part of this. I will also add two notes on that.
If one has the (horrible) idea of sending a DCP through Gdrive, either the whole DCP will download zipped, or the smaller parts will download zipped and the bigger will download with a _001 or similar suffix on the mxf files. A suffix that nothing warns you about and you might end up breaking your head, trying to figure out why a file (or more) seems to be missing. The folder hierarchy might be messed as well.
On the other hand, on transfers via non-proven services, or misconfigured (FTP), could end up corrupting the .xml (or text-based in general) files of a DCP. In numerous such cases (mostly during festivals, but not only), I ended up asking for the sending party to zip the CPL, PKL, etc. and send the package attached to an email.
Compression is not the enemy, per se.

[Carsten]

Using a Mac to create a ZIP larger than 4GB with the built-in archive function, and trying to uncompress it in windows is a classic failure scenario. As far as I know, only later versions of 7-ZIP can deal with these large ZIP files properly.

UnZIPping a full length DCP once it has been downloaded will take quite some time on it's own.

However, when using Google drive, it certainly is better to upload a DCP as a ZIP, as the download of a monolithic ZIP file is safer than a discrete folder download. It's certainly possible to use Google drive for large DCP transfers, but it's a pain in the ass when a browser is used for download. For a few years, I had to download Bollywood movies, 2 parts, each with multiple reels for audio and video, last minute from a Google drive file-by-file. Once I knew how to do it, it worked, but I needed to stay very focussed and always ran a DCP-o-matic verification afterwards.



- Carsten

[mhm]

If you are comfortable with the command line, I can highly recommend rclone for downloading recursively (eg DCPs) from Google Drive and other services.