File Missing Bug?

Software: MochaPro 4.1.0

OS: CentOS 6.4

It seems that whenever I try doing a remove I get this error when scrubbing after it’s done:

Failed to read file: /path/to/file/results/Remove_Test_Footage1012.dpx. The file may be missing, corrupted, or in an unsupported format.

Mocha then starts using all the available RAM until I close it.

If it matters, my source footage is an EXR sequence rendered from Nuke 7.0v10 with Piz Wavelet compression.




This sounds like its not rendering all the frames. Do you have hardware rendering turned on in your preferences? Is this somehow being interpreted as interlaced footage?

Can you let me know and I will be able to diagnose this further?

Hmm… I can’t seem to find the Hardware Rendering option in the preferences. Did you mean the “Matte rendering - Disable offscreen buffers”?

There were dpx files but they looked malformed… Nuke couldn’t open them and gave an error “Unhandled DPX number of bits 32”. Could Mocha be trying to create 32bit per pixel DPX images? My understanding is that 16bit pp is the maximum allowed by the DPX standard (ANSI/SMPTE 268M-2003)

I’ve checked the “Disabled offscreen buffers” restarted Mocha Pro and switched to Tif as the output but I still get the same error but now with tif as the file extension.

The new tif files can now be loaded into Nuke and look as expected (32bit float)… But when I scrub in the timeline in Mocha Pro I get errors for all the files except for the last 3 (in a 26 frame sequence).

If it makes any difference, I keep getting this error in the terminal where I’m running MochaPro:

QObject::connect: Cannot queue arguments of type ‘Prm::ParameterChange&’
(Make sure ‘Prm::ParameterChange&’ is registered using qRegisterMetaType().)

Yes, offscreen buffers is the new name for hardware rendering, sorry. Anyway! I think this may be related to a DPX bug we’re working on fixing. Are your renders in your results folder still rendering as DPXs even when you set it to TIFFs? The DPX error we are seeing has more to do with how the file is written than the bit depth. Can you email me a sample file?

No the files are rendering as tiffs. And i can open them up fine in nuke. When I try and open the DPX files in nuke I get an error stating that there are undefined channels.


I’ve emailed you a dropbox link with the mocha file, tiff file, dpx file and the nuke file that I used to create the footage to bring into Mocha and test with.

I have also got problems writing usable .dpx-files. I have tried opening them in both Nuke and Fusion, but neither can read the file. Tiff-render seems OK, but Mocha sometimes can not read those files either, with the same error as the thread-starter gets; “<span style=“color: rgb(31, 31, 31); font-family: ‘Source Sans Pro’, Helvetica, sans-serif; font-size: 15px; font-weight: 600; line-height: 21.4285488128662px;”>The file may be missing, corrupted, or in an unsupported format.” - </span>Whenever I try to scrub the timeline after removing an element.

I had the same problem in Mocha 2.6, så I think it’s ablut time it got fixed…


Hi Severin,

Did you send them to me or Martin? I am having trouble finding your email. and I’ll respond there and cc some members of our team so that we can get to the bottom of this.

I didn’t send you an e-mail, so that’s why you can’t find it.
I just responded to this thread as I stumbled upon it while searching for a solution to the problem.
I can send you one of the broken .dpx files if you need?

Please do. Thank you. That will help. I think I know what the problem is (it’s in the way we read DPX headers), if so, we should have a fix soon. I just want to confirm.

I sent you an e-mail now, with a link to a broken dpx-file.

Yes, I think this is a known bug, we are trying to fix this for our next major point release.

I am still getting corrupted files, Mocha Pro Version 4.1.2 build 9658.

Still having this issue reading .dpx files into Mocha. Same build as severin-mathiesen: 4.1.2 build 9658.

Console shows the following message:

mochapro[8001]: modalSession has been exited prematurely - check for a reentrant call to endModalSession:
Any sign of a fix...?

Are they 10 bit or 16bit DPX? It may be that the bit depth is the problem. Can you try 16 bit?


Looks like 12 bit DPX. Is that not a supported file format?

It should be, but things like 8 bit and 16 bit do better. Can you try a 16 bit?


16 bit DPX worked fine.

Interesting. Will make sure to request that of clients!