Hash error

[ro...@cbdigital.tv]

Hi Opendcpers,

I am no guru with DCP but I have previously had success so I may have been a little overconfident.

I created a DCP for a 126 min program. 25 fps and 1080. I know its not really compliant but my previous effort was the same and had no trouble.

The error reported by Doremi was assett hash file differs from remote hash file. It opens in a DCP player OK and I am having trouble identifying exactly what the problem is caused by.

One thing I noticed was that the operator/projectionist at the cinema copied my directory to a local drive rather than ingest from my LaCie.

any tips or pointers would be deeply appreciated as world premiere day is fast approaching :)

cheers

Roen

[Yuri Mamaev]

Hi,

Just get the log files from Doremi and send them to me directly, so I’ll be able to review the issue from Doremi side.

It mostly looks like file got not OK during copy (somewhere). The fastest way to remotely solve the issue will be checking hashes at home (that they’re the same, comparing one from PKL and generated), than creating torrent file, checking both ends and torrent client will download bad blocks only, what really helps.

It’s not recommended practice to have one big MXF file, but acceptable.

Best regards,
Yuri Mamaev

11 июня 2014 г., в 14:09, ro...@cbdigital.tv написал(а):

> --
> You received this message because you are subscribed to the Google Groups "opendcp" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to opendcp+u...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

[Manuel AC]

The copying is the problem. If the copy is not bit-perfect, the hash changes.
You can use dcp_inspect in your own copy to check that the hash is correct.
If your disk is NTFS or Linux, and 2tb or less, Doremi can ingest directly.

Manuel AC

[Stephen van Vuuren]

> It’s not recommended practice to have one big MXF file, but acceptable.

It today's age, I think this statement is out of date. I made exactly one DCP with reels several years ago and switched to single MXFs after. I've never had an issue related to this 200+ DCP's later with films up to 2 hours including several 3D features.

Personally, I think it's just because people comfortable with a film based "reel" metaphor designed this stuff but at the end of the day it's computer technology and these files are not particularly large by modern standards.

I've yet to see a convincing technical argument that it's more reliable. In fact, simple math here points to more files, more chances for something to go wrong.

I do have someone asking about a 4 hour documentary, so I might split that one into two, but I will test the single file just as I'm curious.

FYI - I use Beyond Compare's binary comparison feature for copying DCPs onto drives and it's served very well. Copy and byte-check is one pass - obviously slower but runs fine in Linux (Ubuntu on my end).

stephen van vuuren
336.202.4777

http://www.insaturnsrings.com/
http://www.sv2dcp.com/
http://www.sv2studios.com/

A film is – or should be – more like music than like fiction. It should be a progression of moods and feelings. The theme, what’s behind the emotion, the meaning, all that comes later.
–Stanley Kubrick

[conqu...@gmail.com]

I had a hash error when copying an otherwise successful DCP off of an ntfs drive onto a  Doremi. dcp_inspect confirmed this afterwards. I don't think the file was copied onto the drive I used to ingest. I'm super curious what the results of the log will reveal.

[ro...@cbdigital.tv]

well things are strange arent they?
I made a new DCP for fear that I had crated some error somewhere and my client took it to the cinema and . . . . . . . it failed! He asked for error logs but they said they couldnt give them to us until later. Then about twenty minutes after he left he got a call to say that a senior tech had arrived and everything was fine! Including the first DCP we delivered. I have asked for an explanation so that we can avoid this in the future but so far they havent been able to offer any.

Thanks for all the attention to my issue. I have learned a bit and will make DCPs with greater confidence.

cheers
Roen

[Eric Sebalsky]

just to chime in here and give another example: i had a very similar error:

a DCP that plays fine in software and also on servers when ingested via a NTFS drive, gives HASH error on doremi when ingested from an EXT3 CRU-volume.

it is actually a known bug (google it) that some CRU drives (and readers) CORRUPT only the sound MXF (linear uncompressed PCM) and therefor the HASH check fails. it only occurs in combination with the PARAGON EXTFS plugin for mac. using paragon's NTFS plugin however just works like a charm, also with CRUs.

thought it would be good to know! so personally i never ran into trouble with NTFS and i released my movie worldwide as a 25p DCP so i will just stick to it and format also the CRUs that way. note: an external HDD or memory stick DOES WORK with the EXT3 plugin. it is just an issue in combination with CRU containers (actually with the reading device and driver of the server).