KDMs not recognized on some DCP2000 ?

[Carsten]

@Dan - would be completely stupid, but then, I have seen all things happening, and, honestly, staff compliance varies wildly...

Did you send the KDM ZIPped? Are you sure they unzipped them before they put them onto the stick? Now, the interesting question is indeed - when both DCP-o-matic and dcp-tools KDMs are on the same stick - will IngestManager come up after inserting that stick, and if, will BOTH KDMs be shown for ingest, or just the one created with DCP-Tools...?

I know this is often a pain in the ass to control remotely through email or a phone call.

But the fact that ingest manager doesn't even come up with the stick content does not immediately point into DCP-o-matic's direction.

Recently, I see KDMs being sent by email often in ZIPped form, and plain xml as a second attachment.

- Carsten

[Barak Epstein]

mine are not being ZIpped so i dont think thats my issue. do you think my guy at Cannes might have the software mismatch issue? (I'm trying not to insult him by asking if he knows how to use a thumb drive)

[Carsten]

I don't know, since I never dealt with a Doremi <2.4.x myself, but in theory, it is possible that a Doremi running 1.2.1 or 2.2 does not recognize a current Modified Transitional 1 KDM, as they are so old. One would think, however, that these systems would have trouble with many more KDMs.
There is an older 'Interop only' KDM formulation that is so outdated (and explicitly advised by ISDCF to not be used anymore), that Carl never bothered to support it in DCP-o-matic. Again, I can only guess here.
The fact that we have two independent issues of KDMs no working on Doremis could hint towards a problem with DCP-o-matic, but, we haven't seen anything like that before, and if these KDMs work on your local Doremis, I don't think that's what causes this.

I do know that KDMs for dual projection systems can be a bit complicated, although I know that Carl recently solved at least one of these constellations.

Sorry, I am a bit clueless here. There is nothing specific to a 'french' KDM. Any unusual things around that DCP/KDM? Strange chars, graves, acutes accents, in title, file names? I know, not probable with you being located in Texas, but...

- Carsten

[Carsten]

I also notice that KDM_DOM_Montargis4 has DOS line-endings (as one would expect if you made it on a Windows system). But AFAICS there's no way that should cause any problem...

SHOULD, yes, but after what we experienced recently with the Sony validation...

[Carsten]

I also notice that KDM_DOM_Montargis4 has DOS line-endings (as one would expect if you made it on a Windows system). But AFAICS there's no way that should cause any problem...

SHOULD, yes, but after what we experienced recently with the Sony validation...

Bildschirmfoto 2019-03-21 um 13.45.04.png

[barber]

Hello everyone,

I just ran into the same issue with another theatre. This time, the Doremi DCP2000 did detect the stick and showed the other KDMs that were on it, but DOM's KDMs did not appear.
You will find attached the two packs of KDMs.
There is one similarity between the two cases that I forgot to mention : the "invisible" DOM's KDMs both contain accents ("é") in their filename. Whereas the DCP-Tools ones don't. I was not concerned about this since I had already sent several KDMs with accents... but it may be the trick here.
I asked the operator to test again after renaming the DOM's KDMs. I really hope he will try it.

(and yes this operator and the previous one had unzipped the archives before. It's not such an absurd precaution indeed, I already met some theatre staff who were very confused about zip files...)

Best,
Dan

[Carsten]

The é is probably the reason, Carl would have to think over this. I remember at some time that he constrained the char set allowed for naming DCP/asset/metadata files, but maybe something slipped through. Renaming file names alone may not solve the issue, as the bad char (or replacement) could be contained in the file content itself, and if you edit them, the DCP will formally be broken. As the DCP-Tools KDM and the DCP itself seems to work, though, this could be a problem with the DCP-o-matic-KDM only.

At what stage did you add the Astrée_-_Chambéry strings? Did DCP-o-matic put them through, or did you rename the files later?

- Carsten

[barber]

"Astrée" and "Chambéry" are the name and city of the theatre, I entered them in DCP-o-matic KDM Creator when creating an entry for the cinema ("Astrée - Chambéry"). I just let DOM's default KDM naming.
Maybe DOM should replace these special characters when generating KDMs.

[Carsten]

Yes, probably. I have seen something around that happening already last night on the development status bar, so it seems Carl has already taken action.

- Carsten

[Carsten]

The fix to exclude dangerous characters from KDMs is now in 2.13.133. For previous versions - just try to avoid them

Funny there was a similar issue yesterday on the german projectionists forum (though not strictly DCP-o-matic related):

On a Sony Server, DCPs contained in folders containing non-standard chars are not recognized by the server for ingest. Although the server recognizes the non-standard char (in this case german Umlaute ÄÖÜ...) and even displays it properly, the DCP contained in that folder can not be seen and ingested.

While DCP-o-matic does not create such folders, they may be created by renaming the folder manually later, or by moving a complete DCP-o-matic project folder created with special chars and containing an otherwise fully compliant DCP to an ingest drive. Because DCP-o-matic project folders may contain all chars allowed by the operating/file system DCP-o-matic is running in.

As e.g.:

E:\Chambéry\Guantanamera_FTR-2-Temp_F-166_ES-FR_20_2K_20180825_PIN_IOP_OV\

The Sony would recognize and display the Chambéry\ folder correctly, but it would appear empty, both on a local ingest drive and network paths.



- Carsten