Problems with DTS 70mm Playback

[Marco Giustini]

Thanks - so you confirm that the behaviour I have in mind (following the Timecode status) is the expected one?

[Steve Guttag]

Check the wiring of the cable. If pin 9 of the reader has any short to ground/reference, the LED will light. So, anything to cause that line to go low, even a leaky optoisolator (if they're using them) would do it.

[Marco Giustini]

Speaking of 70mm, I’ve stumbled into a 70mm DTS head which would show a green LED even when no film is loaded.

is that a known behaviour? I remember that LED is driven by the player and basically matching the ‘time code’ light on the front panel.

A ‘always green’ head would mean the inability to diagnose time code issues.

is this an isolated case or maybe due to some specific HW version?

[Ryan Gallagher]

I didn't meant to sound harsh, Ryan. Learning on whether timecode was printed on the tails might be a data point - what I meant to say was that the system is supposed to work with or without timecode on the tails. As Mike confirmed, the DTS system will start accepting timecode from the following reel regardless. Even if no head or tail leaders were spliced, the system would have the time in between the TC reader and the gate to process the new TC and start playing the new reel. Considering that DTS has 4.5 seconds of "flywheeling" when TC is lost, that is really a non-issue.

We're all looking forward to Jerry's feedback now

Did not read it as harsh, no worries. In my head I just keep circling back to the fact Jerry is only experiencing this on “some” but not all 70mm prints, and that variation in printing practice combined with maybe an unusual XD20 only behavior (perhaps due to a non patched version), could be the compounding factors.

[Marco Giustini]

The "excessive timecode" relates more to Brad's input an memory that there were a handful of modern 70mm prints where Fotokem was doing unusual or inconsistent things with timecode on the tails. Perhaps there is some out of bounds behavior when a print is unusual like this that is specific to the XD20s, it would require Jerry reporting on the presence of non-presence of timecode all the way out through the tails on his testing print.

I didn't meant to sound harsh, Ryan. Learning on whether timecode was printed on the tails might be a data point - what I meant to say was that the system is supposed to work with or without timecode on the tails. As Mike confirmed, the DTS system will start accepting timecode from the following reel regardless. Even if no head or tail leaders were spliced, the system would have the time in between the TC reader and the gate to process the new TC and start playing the new reel. Considering that DTS has 4.5 seconds of "flywheeling" when TC is lost, that is really a non-issue.

We're all looking forward to Jerry's feedback now

[Michael Zarits]

Did I dream that even/odd pattern with older players or was that actually a thing?

I'd be interested in that as well.

[Ryan Gallagher]

I really don't think there is such thing as "excessive timecode" here, the system should be designed to operate change-overs WHILE the ending reel is still running.

The "excessive timecode" relates more to Brad's input an memory that there were a handful of modern 70mm prints where Fotokem was doing unusual or inconsistent things with timecode on the tails. Perhaps there is some out of bounds behavior when a print is unusual like this that is specific to the XD20s, it would require Jerry reporting on the presence of non-presence of timecode all the way out through the tails on his testing print. But I think getting confirmation of v2.2.06 first is the first step.

The XD20 was one of the best film-based products DTS made, it was always very reliable but it also could be complicated in configuration. How it’s configured can affect how it reacts to automation cues and what it will do or not do with loss of time code. Most cases it’s best to set Format automation for DTS-6D emulation.

This is a good line of inquiry too, My XD20 here installed factory defaulted to "DTS-6D emulation" in automation format->"operating mode"... but perhaps Jerry's is configured otherwise. If he is using it for 35mm there is a good chance he is using the automation features to control the fail-over format too. So doing a test without automation physically connected for 70mm and the default or alternative automation formats seems worth while too. Way back in the thread someone also wondered if the automation might have an impact too.

[Marco Giustini]

Thanks Mike - if I remember right you were part of DTS in the past.

Did I dream that even/odd pattern with older players or was that actually a thing?

Good point about the automation, I am unfamiliar myself with the new automation schemes introduced with the XD10 where the player would only be activated when the proper format is selected on the Sound Processor. It would be worth take a look at that, Jerry: how is your automation set on the XD20?

The Y-Cable was not pre-made by the factory so it's certainly worth double-checking that.

[Mike B. Smith]

The XD20 was one of the best film-based products DTS made, it was always very reliable but it also could be complicated in configuration. How it’s configured can affect how it reacts to automation cues and what it will do or not do with loss of time code. Most cases it’s best to set Format automation for DTS-6D emulation.
Sound change over with the DTS is independent from your normal change over which in most cases includes douser and switching Projector optical. It does not follow an Even Odd pattern but simply looks for the correct reel and serial number and confirms the audio track matches.
What I’m understanding is the same system works fine when configured for 35mm film playback, that should eliminate quite a few things however, my first thought would be to check the “Y” timecode cable, I have seen on rare occasion factory cables not being correct.
My other suggestion is to check the automation, disconnect the automation cable from the XD20, select DTS format on your audio processor, now perform the change over and see what happens, no format switching should occur on the audio processor but the DTS audio should switch to the incoming projector when the change over occurs.

[Ryan Gallagher]

I have specific interest in learning if the XD20 is ultimately to blame, as I have one sitting in front of me slated to maybe become our cold or hot spare processor in my booth.

[Marco Giustini]

I really don't think there is such thing as "excessive timecode" here, the system should be designed to operate change-overs WHILE the ending reel is still running.

However there aren't many XD20s, I have never seen one myself! So who knows, maybe this is something DTS would have fixed by software if they were still around!

In any case checking timecode with an oscilloscope is also a good idea. It should give more data points to this situation.

[Ryan Gallagher]

Thanks Marco, I guess I missed your comment about the same input suggestion. Sorry.

Agreed, checked the cable and how the DB9 is wired.

Only other thing would be to wipe the hard drive on the XD20 and do a clean install. Could be just a bunch of corrupt sectors on the drive.

Yeah I had suggested re-ingesting the soundtrack also, similar direction of inquiry. But Jerry did say he tested with two distinct XD20 processors... so HDD issues seem unlikely, unless he's just got an incorrect soundtrack file (also seems unlikely).

There is always the possibility that there was a bug in a firmware version. I see that Film-Tech has 2.2.06 for the XD10 and XD20. I'm curious if that is what is in use on this unit and if not, try updating to that. I seem to recall that Brad has worked out what the ideal firmware are the most solid.

I just downloaded it and check out the big improvement for the XD20:

image.png

So, if you are not on 2.2.06, I suspect that we've found the issue.

But we may all just be running in circles troubleshooting a KNOWN XD20 BUG, as Steve pointed out, we never actually got Jerry to confirm exactly which version he is on other than citing "latest" in his response. Considering how "spot on" that release note sounds to this particular behavior, I think circling back to that basic question is definitely worth while. It would also explain why XD10s seem to have no problem with these prints in question (in other booths), even perhaps on older versions.

And if he's on 2.2.06 already, I think the next logical tests would be to actually confirm the timecode cabling is correct (again), as has been suggested.

If everything is as intended with the cabling, try the LED block test with a helper in the booth to see if the timecode changeover can be forced to occur sooner without the dropout?

Distinguishing between excessive timecode on a tail after the file ends triggering the bug versus overlapping timecode on the same pin might be tricky, as the blockage card kinda tests both situations. If one wanted to get "real serious", one could add a breakout board before the processor to give you test points for a scope on the timecode pins and actually confirm that the signal does indeed change over to the other reader/pin and is not all coming in on a single pin (or shorted to both pins etc).

If that test works, perhaps there is still some buggy behavior with the XD20 in this area, being exacerbated by these unusual prints as Brad suggested, but keeping an eye out for tails with excessive timecode and just covering them with a stripe of artist tape or cue tape might be the low-tech solution? If they have an existing splice, just take the tail off and add a length any suitable leader without DTS in it's place? Or just bite the bullet and score an XD10, if it is an XD20 specific problem that cannot be solved without undesirable modifications to prints.

Jerry already said he is intending to test with an XD10 soon, so we may know soon if the problem vanished. If so, very likely it was not the cable or readers, and maybe DTS/Datasat have an issue with the XD20 playing past the first frame of picture, which comes to a head when printed reel timecode is longer than the reel file?

[Markus Lemm]

Thanks Marco, I guess I missed your comment about the same input suggestion. Sorry.

Agreed, checked the cable and how the DB9 is wired.

Only other thing would be to wipe the hard drive on the XD20 and do a clean install. Could be just a bunch of corrupt sectors on the drive.

[Marco Giustini]

Markus

All inputs are very welcome of course. However...

I am going to drop this here but I have this weird feeling that both heads are plugged to the same input! I don't even know if that would work but...

Let's suppose the timecode input is pulled high (or low) by the timecode board in the player and the reader is pulling it low (or high) to create the data stream, what you (we) suggest might be possible.

What doesn't work in my head is that if that was the case, then when P2 starts, BOTH timecode would become garbage and the player would report a TC: DROP - which it doesn't. (Michael also mentioned that while i was composing this message!)
But at this stage, I feel it's wise to take a look at that cable!

[Michael Zarits]

For my understanding a 'double' input from both readers on the same pin should render the signal unreadable but there is valid timecode until R02 17:50:08 which is already way into the tail leader of R2 with R3 already running for ~14 seconds since FFOA on the other projector at this point:

[6] [Sep 11 18:07:53] TC: Edit from R02 17:50:08 to R03 00:20:03 [29]

LFOA of R2 is already at 17:34:05 - This is the moment R3 timecode kicks in and would render the timecode unreadable but there is no event in the logs at all.