This is topic Doremi WebGUI KDM time problem in forum Digital Cinema Forum at Film-Tech Forum ARCHIVE.


To visit this topic, use this URL:
https://ft-forum.com/ft/cgi-bin/ubb/ultimatebb.cgi?ubb=get_topic;f=16;t=002491

---

Posted by Dave Macaulay (Member # 813) on 11-19-2015, 08:26 PM:
 
The Doremi WebGUI - the only interface for the IMS1000 and IMS2000 and optional for the DCP-2000 or ShowVault - has an odd bug relating to KDM start/finish times.
KDMs are always issued with times in UTC (formerly known as Greenwich Mean Time). Distributors keep the local time for each server and issue KDMs to open at appropriate local times but the KDM must have the start/finish times in UTC.
The WebGUI fails to convert KDM times to local time. Inspecting a KDM in content manager shows the times in UTC. The lock icons display the status of a clip (locked=red, open=green, short time left=orange) by UTC as if it was local time.
For example if your KDM opens at 5pm here in Eastern Standard time, the UTC time is 5 hours later. Trying to play a 7:00pm show, the icon is still red and inspecting the KDM shows it opening at 10pm.
This is only affecting the WebGUI displayed data. The server "guts" knows the KDM is open and playing a playlist with the red-icon clip will work perfectly.
On a DCP-2000 or ShowVault, if you look at a local display terminal the icon will be green. If you connect with VNC, green. If you open the WebGUI page, red. (You don't have the ability to have a local display or use VNC with an IMS1000 or IMS2000)

So beware: if Deluxe (or whoever) says your key is OK and should be open but you see a red icon and later start time inspecting the KDM in content manager on the WebGUI - try playing it...

Doremi is aware of this and will fix it "in a future WebGUI release".

This bug is in v1.1.7 (current). I haven't checked earlier versions.

This caused some aggravation and many calls/emails with Deluxe for yesterday's one-show Mockingjay premiere event (sneak?) with KDMs issued opening at 5pm. If we had just set the playlist and schedule up, it would have played OK... but seeing the red icon was very disturbing: a lost show with a full house of Mockingjay fans is not a pleasant prospect.
 

---

Posted by Ioannis Syrogiannis (Member # 3235) on 11-20-2015, 01:18 AM:
 
That is a catch.
Thanks for sharing!

The thing is that the "try to play it" test is good enough in the time window that the KDM is valid. So, if you don't know about the bug before-hand, anxiety rises. Especially with the narrow time windows those KDMs for special screenings are issued.

A quick look at the KDM could show what is going on, if you don't believe what you see on the KDM's properties, but often enough, UTC times are followed by a plus or minus symbol and a timezone difference in hours, in order to display local time inside the .xml file. That had its share of misunderstandings in the past, also.
 

---

Posted by Lars Goldschlager (Member # 8716) on 02-15-2016, 01:52 PM:
 
Thanks for the information Mr. Macaulay. I was just helping a projectionist that had ran into this bug and was perplexed.

I take the chance to ask whether producing the KDMs using an UTC time zone is a industry standard practice, and why/how it came about.

Right now we're still servicing KDMs mostly for our own country only, but as more movies we lab are being sent internationally my normal procedure is to produce KDMs in the time zone where the screen is located.
 

---

Posted by Dave Macaulay (Member # 813) on 02-15-2016, 03:12 PM:
 
The KDMs we get from Deluxe are all in UTC, I thought that was a requirement. Definitely all servers I know use UTC on the secure clock, and you can't change that to a new timezone with only 6 minutes a year adjustment allowed.
Deluxe knows the time zone for all sites and adjusts the KDM UTC times so keys to open correct local time. I spent quite some time on the phone with Deluxe trying to figure out this webgui situation and learned a bit about how they operate.
Looking at a typical kdm I see
<ContentKeysNotValidBefore>2015-06-12T04:00:00+00:00</ContentKeysNotValidBefore>
and I think probably the +00:00 could be changed to whatever the local time zone UTC offset is. I don't look at a lot of KDMs but I can't recall seing anything except 00:00.
 

---

Posted by Jim Cassedy (Member # 4115) on 02-15-2016, 05:12 PM:
 
David-
I sort of ran into this same issue about a week ago, when I was called in at
the last minute to do a REVENANT screening at a location where the Doremi
had been shut down and not used for almost 3 months.

According to KDM e-mail from Deluxe, my 'key' was good at 5pm local time.
---------------------------------------------------

---------------------------------------------------

The actual KDM XML file looked like this:
----------------------------------------------------------------------------

----------------------------------------------------------------------------

On the Doremi, it came up like THIS:


However, while trying to figure this out, I found that on one of the 'set up'
pages in the Doremi,there was "UTC Offset" input of 480minutes, or 8hrs.
(Which still makes no sense, since 0000UTC(-480min)= 1600 local, not 1700)

Long story short- - I went in early the day of the screening and the KDM
became active at exactly 1700PST, as stated in the Deluxe e-mail, even
though I still haven't figured out the math.

The server was a DCP-2000. No ShowVault. I don't have my notebook
here today, but I believe the software was all up to date.
 

---

Posted by Dave Macaulay (Member # 813) on 02-15-2016, 05:54 PM:
 
This is all good. Unlocks at 17:00 Feb 8th PST; plus 8h = 01:00 Feb 9th UTC as in the KDM.
 

---

Posted by Carsten Kurz (Member # 5396) on 02-15-2016, 07:15 PM:
 

quote: Lars Goldschlager

---

I take the chance to ask whether producing the KDMs using an UTC time zone is a industry standard practice, and why/how it came about.

Right now we're still servicing KDMs mostly for our own country only, but as more movies we lab are being sent internationally my normal procedure is to produce KDMs in the time zone where the screen is located.

---