Announcement

**Marcel Birgelen** · 03-02-2022, 06:22 AM

Not much experience with Qube over here, but to me this looks like a Y2K22 problem... The timestamp in the error looks like a perfectly fine RFC3339 timestamp to me...

Are you running the most recent software?

**Juan Jose Garcia Calvo** · 03-02-2022, 08:50 AM

Yes, we are running the latest software available (this server is not supported some years ago…

About being a Y2K022 problem, it’s the first time we see it even if we projected other 2022 made trailers and films…

But you are right: it seems that the date/time string shown in the error message seems to be ok…

it’s a mistery…

**Marcel Birgelen** · 03-02-2022, 03:39 PM

Some systems that store the date field of the RFC3339 timestamp as a signed 32-bit integer, ran into problems on January 1st this year, as it causes an overflow. Maybe this is the first CPL with Issue Date in 2022 you're actually playing?

**Harold Hallikainen** · 03-02-2022, 04:25 PM

I thought Y2k22 mostly affected Microsoft Exchange servers antimalware software. It's interesting that they save the date as a signed 32 bit integer, but it is not a Unix timestamp. Instead, the 2 most significant digits of the decimal value indicate the last 2 digits of the year. That limited it to 21. The 32 bit signed unix time stamp overflows in 2032. Many systems have changed to a signed 64 bit timestamp.

Would a Qube server have the Y2k22 issue?

Harold

**Juan Jose Garcia Calvo** · 03-02-2022, 04:53 PM

Hello.
we recently played films with 2022 date in the CPL name…but…

Qube is an embedded windows7 system. If I it’s an issue with the 2022 date… Any idea if it can be solved?

I’m very worried.

**Marcel Birgelen** · 03-03-2022, 03:27 AM

I don't think the problem is in the CPL name, but rather in an attribute in the CPL itself. The CPL contains an attribute called IssueDate. Maybe you should check that one on the ones you successfully played, maybe they're still dated somewhere in 2021.

Originally posted by Harold Hallikainen View Post

I thought Y2k22 mostly affected Microsoft Exchange servers antimalware software. It's interesting that they save the date as a signed 32 bit integer, but it is not a Unix timestamp. Instead, the 2 most significant digits of the decimal value indicate the last 2 digits of the year. That limited it to 21. The 32 bit signed unix time stamp overflows in 2032. Many systems have changed to a signed 64 bit timestamp.

Would a Qube server have the Y2k22 issue?

Harold

I guess many developers simply have no real clue about datatypes. The thing compiled and it worked... done/done. Even with unit testing, you can only test so many scenarios...
If you look at this Wikipedia article, you'll see there are plenty of potential timebombs out there... Doing time right, seems to be hard.

**Carsten Kurz** · 03-03-2022, 03:56 AM

Originally posted by Juan Jose Garcia Calvo View Post

Hello.
we recently played films with 2022 date in the CPL name…but…

Qube is an embedded windows7 system. If I it’s an issue with the 2022 date… Any idea if it can be solved?

I’m very worried.

The system may be unsupported - but maybe someone from Qube will still answer a question towards it.

How do you get your trailers?

I would probably get a bunch of different old and new trailers, try to ingest and play them, and as it happens, try to find the relevant difference between them. Also, the trailer you mentioned is an interop trailer. What does this server do with SMPTE trailers, as we are now seeing more and more of them.

**Juan Jose Garcia Calvo** · 03-03-2022, 06:37 AM

Originally posted by Carsten Kurz View Post

The system may be unsupported - but maybe someone from Qube will still answer a question towards it.

How do you get your trailers?

I would probably get a bunch of different old and new trailers, try to ingest and play them, and as it happens, try to find the relevant difference between them. Also, the trailer you mentioned is an interop trailer. What does this server do with SMPTE trailers, as we are now seeing more and more of them.

I sent yesterday a whatsapp message to the guy we know in QUBE. He read it, but still no answer.

Most of the trailer arrive through SmartJog. Others arrived with fisical feature DCPs.

15 days ago I was in a hurry and I used DCP'o Matic to make an IPO trailer DCP from a downloaded 1080P trailer (youtube) and it was played with no problem at all. This trailer must have a 2022 date, isn't it?

I will test a bunch of trailers to see if there are more trailers with problems, and then study them.
The QUBE plays both IOP ans SMPTE features without problems.

Regards!

**Juan Jose Garcia Calvo** · 03-03-2022, 06:38 AM

Originally posted by Marcel Birgelen View Post

I don't think the problem is in the CPL name, but rather in an attribute in the CPL itself. The CPL contains an attribute called IssueDate. Maybe you should check that one on the ones you successfully played, maybe they're still dated somewhere in 2021.

I guess many developers simply have no real clue about datatypes. The thing compiled and it worked... done/done. Even with unit testing, you can only test so many scenarios...
If you look at this Wikipedia article, you'll see there are plenty of potential timebombs out there... Doing time right, seems to be hard.

I will try to see where is this attribute in the last 2022 films we played.

Regards

**Carsten Kurz** · 03-03-2022, 07:02 AM

I understand you got this error when you loaded an SPL that contained this trailer? Can you play JUST this trailer as a test - so not in an SPL, but just the CPL? Our Sony and our Barco allow to play both SPLs and CPLs - I guess the Qube does, too. Maybe that SPL contained content (e.g. SMPTE), that triggered an extra validation of all content in the SPL. The behaviour of the different servers can be very complex when it comes to content validation.

As it is an unencrypted trailer - are you able to upload it somewhere so we can have a look at it? The problem MAY be within the CPL file, but it could as well just the CPL being indicated in the error, while the actual problem could be in one of the other DCP files, assets or metadata. So, looking just at the CPL file could be misleading.

**Juan Jose Garcia Calvo** · 03-03-2022, 07:24 AM

Qube works with “shows”.
a “show” is a playlist you make over a timeline drawing and dropping elements on it (trailers, features, cues like open/close douser, lamp on/off, change sound format, etc…)
The player section only accepts a show, not CPLs…
I can create a “show” with only this trailer and check it.

I will upload this trailer tomorrow and send you a link ?.

regards!!

**Carsten Kurz** · 03-03-2022, 07:45 AM

**Juan Jose Garcia Calvo** · 03-04-2022, 02:31 AM

Hello.

PROBLEM SOLVED.

There was NO problem with Y2K22

Yesterday I received answer from QUBE people. They told me that the problem is that the problematic trailer don't meet the RFC3339 datetime format in the "IssueDate" field. This datetime stamp must include the country offset, that's, e.g.:

<IssueDate>2021-11-29T20:38:41+05:30</IssueDate>

whiile the "bad" trailer only have this:

<IssueDate>2022-01-27T16:20:01</IssueDate>

I talk to the LAB and they told me this trailer was made from the post-production machine and I saw the software was BLACKMAGIC DAVINCI RESOLVE STUDIO, it must be a pluggin and it seems it don't meet the full DCI standard (if RFC3339 datetime format is part of the DCI standard, of course). I think the LAB is going to contact with this software developers to inform about this.

The LAB sent me a new trailer. Take a look on these screenshoots:

"BAD" trailer:
IMG_3809.JPG

"NEW" Trailer:
IMG_3808.JPG

I will check it in a few hours, but I think it has all the sense

Karsten: I think there is no need to send you the bad trailer, but if you still want it, let me know, or I can send only the low weight archives in this case.

Thanks to all of you!!!

Regards from Spain!

**Marcel Birgelen** · 03-04-2022, 07:58 AM

Actually, I think the Qube people are wrong. The RFC3339 spec allows for dates without country offset, those should be handled as "Zulu" time or UTC. So I guess they skipped that part of the standard.

I've exported some DCPs with Davinci Resolve myself and did not run into those problems yet, maybe there is a discrepancy between versions.

Announcement

ERROR on QXPD: --UNSUPPORTED RFC3339 date time string '2022-01-27T16:20:01'--

ERROR on QXPD: --UNSUPPORTED RFC3339 date time string '2022-01-27T16:20:01'--

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment

Comment