both unencrypted and encrypted SMPTE created with 2.13.108 verify and validate okay...
Now let's see...
KDM ingests properly and is assigned to encrypted SMPTE - unfortunately, that was always the case when encrypted SMPTEs failed previously. In order to test it, I would have to actually play the file, but the crowd currently watching 'Aquaman' won't like that. Although, after previewing it last night, I'd say that a 10s slide 'SMPTE-Test' has more entertaining value than that flic...
Only joking. DCP-o-matic used to create its XML files with no internal indentation (aka "pretty printing"). I changed it so that it now indents 2 spaces in for each new tag.
It seems unlikely, but my only guess is that the Sony software is reading CPLs, reformatting them (adding indentation) then checking the signatures after that... so if you don't use the same indentation scheme as their code the signatures will not match.
There may be some subtlety to this that I am missing...
It's weird that the error when trying to play non-such-compliant-DCPs is given as 'no playback time window', as if the KDM was the issue. But maybe that is just the Sony way of saying that the signing relation between KDM and CPL is broken.
I will also try to generate DCPs with 2.13.108 and KDMs with e.g. 2.12.x.
- Carsten
Last edited by Carsten on Fri Jan 25, 2019 12:26 am, edited 2 times in total.
I could try to read a CPL off the Sony through FTP to see if something like that happened to them. I was always curious to know wether CPLs are stored unaltered or modified.
Hmm, I just created SMPTE DCPs with 2.13.83 and 2.13.109, but when opening the metadata files with a text editor, I don't see a difference. Am I missing something? Maybe my OS X text editor is doing something strange...need to check with Windows text edit or <more>...
edit: more is more...
I will draw some other CPLs off our Sony through ftp which do not verify okay and check wether they all show that same 'style'.
