Problems with DTS 70mm Playback

[Ryan Gallagher]

I forget the first title, but months ago Fotokem adopted the practice of not printing the timecode into the tail leader. Before that it was hit and miss from title to title (and sometimes only on certain reels of a feature). Regardless as you noted it was not a problem on The Brutalist and nothing since then and going forward will be an issue.

I would point to this if Jerry was experiencing dropouts with slightly mis-timed changeovers... but from the sounds of it the picture changeovers are fine, and DTS is just not picking up the following reel until the prior one's tail and timecode completely vanishes. Or perhaps more accurately, until the DTS reel file ends?

But if Jerry's system is preferring to play the tail timecode for some reason (is that a known XD20 behavior?), your printing insight might be the issue. And it's only "failing" from Jerry's perspective on the handful of reels that actually had timecode printed out on the tails?

I expect next time Jerry encounters this we would need an inspection report that indicates which tails have or don't have timecode (beyond the changeover point). Do they correspond to his playout and dropout changeovers?

If that turns out to be the real cause, other than figuring out why the player is preferring to play out DTS tails, a workaround could be just to block the LED of the outgoing reel as it reaches the tail and changeover... before the DTS file reel actually reaches it's termination. Kinda manually forcing it to switch to the other reel before the dts reel ends.

[Ryan Gallagher]

it's weird indeed.

The fact that 35mm DTS works seems to clear the player and the wiring from the equation
The fact that the same print (are we sure it's the same print and disks?)works on the XD10 seems to clear the print and the content

My guts feeling suggests an issue with how the disks were mastered as speculated above (odd/even reels etc). If that is the case, the software is not allowing the changeover but when eventually timecode stops from P1, then the player will start reading the timecode from P2. Maybe the other cinema had a revised version of the print/disks?

A fault with the 70mm heads seem unlikely as other 70mm prints do work well.

This does not happen at specific changeovers, does it? it happens with specific prints on ALL changeovers on those prints?

With both projectors idle and a DTS 70mm print in it, start P1, does the green LED light up immediately and does the XD20 start playing almost immediately? Now stop P1, wait a minute, do the same test on P2, is the behaviour identical?
With one or the other projector running, cover up the DTS LED light with a piece of paper. The TIMECODE light should turn off and playback should continue for about 4 seconds, then it should stop. Remove the paper from the LED and the playback should start again pretty quickly, 1-2 seconds I'd say. Repeat this tests as much as you want and on both projectors: do you notice anything weird? Is the behaviour consistent between the two projectors?
I'm trying to ascertain whether one or both heads might be a bit weak maybe: a weak head might show issues if the print is not properly made.

That also raises a point... if the "discs" are already in the player from a previous engagement... DELETE that title and re-ingest from the USB/Discs key next time the print arrives, just to rule out some weird alternate DTS reel layout for a specific title?

[Ryan Gallagher]

I will have to look into my notes regarding if certain reel-changes always were affected.

The drop-outs I have seen result in the following on the DTS player. The end of the currently running reel continue until the time-code ends on the tail on the display. Then after a short disruption it starts to read the next reel.

How can certain 70mm prints continue to run flawless on the system (including all 35mm DTS). While others display drop-out on our system but not at another cinema using the same print?

I'm inclined to agree it is something in your booth, these prints are run by countless theatres, and you have a nearby example of one running them without issue.

Trying an XD10 is a valid instinct, but it is literally the same software install as the XD20, the 20 just enables the LCD and a couple of other features. So i'm not expecting you to get different results on an XD10, but worth a shot.

One thing I would consider once you are testing with an XD10 is to plug a VGA monitor in and get to the console where you can see the live system event messages, perhaps that will be illuminating. Unfortunately with the XD20 the system monitor output is overtaken to provide CSS during operation. But maybe there is a way to login a shell to monitor the same, though I don't think DTS was in the habit of sharing those credentials.

I would still do a continuity or tone check on the Y cable pin-outs... making sure to check for shorts that read on multiple pins etc. I know they were just rebuilt, but worth testing.

If you are friendly with that other venue, you could maybe "borrow" their pair of readers just to completely rule out something being amiss with your readers, but if your timecode lights on the readers are behaving as expected (which you said they are) it feels unlikely the readers are the culprit.

Having access to a print that reveals the issue seems challenging. Maybe a studio would agree to let you keep one longer while you work through this issue?

Aside, do you still run Nitrate prints there? If not I'd ditch those fire trap rollers (the two blue ones)... they make more contact with prints than is advised for anything but nitrate. But perhaps you are archive/museum or university attached and actually get to run nitrate!

[Marco Giustini]

it's weird indeed.

The fact that 35mm DTS works seems to clear the player and the wiring from the equation
The fact that the same print (are we sure it's the same print and disks?)works on the XD10 seems to clear the print and the content

My guts feeling suggests an issue with how the disks were mastered as speculated above (odd/even reels etc). If that is the case, the software is not allowing the changeover but when eventually timecode stops from P1, then the player will start reading the timecode from P2. Maybe the other cinema had a revised version of the print/disks?

A fault with the 70mm heads seem unlikely as other 70mm prints do work well.

This does not happen at specific changeovers, does it? it happens with specific prints on ALL changeovers on those prints?

With both projectors idle and a DTS 70mm print in it, start P1, does the green LED light up immediately and does the XD20 start playing almost immediately? Now stop P1, wait a minute, do the same test on P2, is the behaviour identical?
With one or the other projector running, cover up the DTS LED light with a piece of paper. The TIMECODE light should turn off and playback should continue for about 4 seconds, then it should stop. Remove the paper from the LED and the playback should start again pretty quickly, 1-2 seconds I'd say. Repeat this tests as much as you want and on both projectors: do you notice anything weird? Is the behaviour consistent between the two projectors?
I'm trying to ascertain whether one or both heads might be a bit weak maybe: a weak head might show issues if the print is not properly made.

[Jerry G. Axelsson]

I will have to look into my notes regarding if certain reel-changes always were affected.

The drop-outs I have seen result in the following on the DTS player. The end of the currently running reel continue until the time-code ends on the tail on the display. Then after a short disruption it starts to read the next reel.

How can certain 70mm prints continue to run flawless on the system (including all 35mm DTS). While others display drop-out on our system but not at another cinema using the same print?

[Marco Giustini]

because 6 and 6Ds spin up the CD motors of all drives when reaching the last minute to ensure fast access when switching to the next reel that my be on the second disc.)

Interesting, my experience with a 6 and 6D is that the CDs are always running - it was a major issue when I tested slightly different Toshiba drives in a 6D as the player was unable to keep them awake and when it was time to read from the other drive, the drive had to spin up the disk which caused a dropout.

From Jerry's description, the issue follows the print so something must be wrong with the way it's printed.

Jerry, the light on the reader comes from the player - and it's a single line for both readers if memory serves. So if you see a solid light it only means that the player is happy with the data received by the head but won't tell you WHICH head is being used.

It would be helpful to know what happens on the XD20 display where you can see the Reel being played and, most importantly, the real-time timecode. If you could take a recording of the display with the audio on so we can hear the dowsers being activated, it should be possible to ascertain "what-happens-when".

I would still take a look at the Timecode cable to make sure that it's been wired correctly - no disrespect for your technician

[Michael Zarits]

Jerry, with Tenet does it happen on all changeovers or just on changeovers between certain reels?

[Michael Zarits]

I'm pretty sure a changover with a "step down" in reel number must be possible as well. I don't have the title of movie in mind but there is a disc that has altenrative edits in a few reels assigned like:
R1 = R13T5
R2 = R12T5
R3 = R3T5
R4 = R11T5
R5 = R5T5 ...

Whatever theory is right, the DTS processor must "changeover" with the real changeover at the moment the timecode of the next reel is coming in. Tails are not required to stop at a certain point neither the timecode on the print nor the end of file*. As soon as the new TC from the next reel is present it has to switch over to the new reel/file, not just by waiting for the tail TC to run out or reaching the end of the previous file.

*(Well, the actual "changeover point" at the end of a file must be within the last minute of a file because 6 and 6Ds spin up the CD motors of all drives when reaching the last minute to ensure fast access when switching to the next reel that my be on the second disc.)

On the other hand my DTS disc of JOKER has the files assigned by the phsyical reel numbers and Jerry has problems with that feature as well...

[Jerry G. Axelsson]

Thank you everybody which has offered help and suggestions.

Here is a photo of the projector with the reader mounted for 70mm DTS. When running 35mm DTS we swap the reader on the same place.

Some other details worth of notice.

We also ran a 70mm print of OPPENHEIMER which ran perfectly without drop-outs.

The timecode off-set is correct for 70mm. The 35mm setting is correct as well. Format off-set is chosen on the XD-20 when we have a 35mm or a 70mm show.

The 70mm DTS readers read with a stable timecode. No apparent glitches which are visible on the reader.

Both the 70mm DTS prints of JOKER and TENET ran fine in another change-over operation with copies of our timecode readers using an DTS XD-10 on a DP70.
So the fact that the prints has time-code a bit out on the tail leader did not cause issues on this other location using the same prints.

Some 35mm prints also have time-code which continues out on the tail leader. Does not cause a problem as far as I have seen...

Only one of our readers was taken apart for making additional readers. After this breakdown and assembly, we have adjusted the reader mecanically and electronically with correct voltage.

The chang-over issue persists back and forth with the machines no matter which machine we start with.

We have tried with another XD-20. No improvment, same issue. We made a new DTS reader cable just before the summer (shielded cable) no extra ground attached. The new reader cable did not solve the matter. Was done by a professional cinema installer. No difference!

35mm DTS runs fine without issues. We even ran a show without the optical soundgead threaded to make sure we would hear all possible drop-outs and not be fooled by A/SR back-up.
Worked fine without issues.

Here is a photo of the fixture of the projector. In hindsight, perhaps a bit overcomplicated threading path.

I will look into running TENET again with an XD-10.

Does this give anyone more ideas of were the problem could be?

Our XD-20 has the latest software installed.

thumbnail_IMG_3400.jpg

[Marco Giustini]

Michael,
I might be making this up but I have this memory - however I cannot find evidence in the DTS6 manuals so who knows
I remember it was explained as a way to prevent unintentional changeover if someone was unthreading a projector with a "non-sequential" reel in it. But now the EVEN/ODD theory also comes to mind so it might be what I read.

So changeover from 2 to 3 is expected but not from 3 to 2.

Reel 4 is assigned as Reel 13, so the order is Odd/Even/Odd/Odd/Odd/Even...

Could it be that this behaviour is incorrect on the print and that's why Jerry is experiencing the issue? After all I'd imagine there is not much expertise left for film prints nowadays. If our EVEN/ODD theory is valid, the XD20 would wait for the previous timecode to stop, THEN it would start accepting timecode from the following reel: the 1-2 seconds of gap Jerry is reporting.

Yet, it doesn't explain why things work with an XD-10.

[Michael Zarits]

very interesting.
[...] that is, if you're playing R4, a valid changeover can only happen if projector 2 is receiving R5 timecode. [...]

Marco are you sure about that? Because sometimes they assign a different "reel number" to a timecode that does not match the physical reel number, e.g. R13 as Reel 1 when there is different distributior logo or a censored version of a reel etc. So the assigned reels numbers are not in order anymore. The processor does not know that in this case the order would be R13, R2, R3,... Instead it would expect R14 after R13.

My assumption is: A changeover is only valid if an even reel number follows an odd reel number and vice versa. I did not investigate into that but in addition it also could be that a changeover is also only valid within the last minute of a reel/file (this "last minute"-action is also used for the last reel when it switches to nonsync instead of SR when the timecode ends at the end of the show). On the other hand I came across a few discs that use alternative reel numbers for a certain reel that breaks the even/odd order which is also the case for TENET! (at least for the DTS in my library). Reel 4 is assigned as Reel 13, so the order is Odd/Even/Odd/Odd/Odd/Even...

Jerry, for Tenet is it the case that it only happens when changing over from R3 to R4 and R4 to R5?

Would be interesting to bring some light into that odd/even reel number assignment.

[Brad Miller]

I forget the first title, but months ago Fotokem adopted the practice of not printing the timecode into the tail leader. Before that it was hit and miss from title to title (and sometimes only on certain reels of a feature). Regardless as you noted it was not a problem on The Brutalist and nothing since then and going forward will be an issue.

[Tj Hopland]

I'm wondering if that machine overall has some difference in its roll up where its just not as fast to stabilize as it needs to be? Swapping the readers between the machines is a reasonable thought but the 70 track is so wide compared to the scan its not likely to be a tracking issue. Have you checked the video levels? Maybe that one is low (or high) and that makes it take a little longer to lock in?

Also whats your mounting location and film path? I remember on my first DP70 DTS install on top of a cat 700 was about the worst results especially bypassing the top sprocket. We came up with a film path that caught one of the mag stabilizer rollers and that seemed to help a bit but it still seemed prone to have film stability issues both off the platter and some reels. Eventually we ended up stuffing the reader inside the projector and got it between the sprockets and caught a stabilizer and the tension arm. With that setup it didn't matter what the reel or platter was doing they just stayed locked in. There was nothing worse than seeing the timecode light blinking with a full house and I'm taking about the olden days before recliners when you really had some seats to put butts in.

[Ryan Gallagher]

We do all the changes here on 24" reels, so both directions (but with an XD10).

A couple other lines of inquiry:

Is this a “new” problem that appeared after you sent out a reader to be copied?

Your description does not sound like you have tried swapping the readers across the machines yet. Might be worth a try to narrow it down, but the fact some 70mm prints work fine would suggest the issue is perhaps elsewhere. If it is easier just flip the ends of the Y cable across readers, effectively the same test.

Print condition is also a consideration, but your average of having this problem on so many points elsewhere too I would think.

The XD20 manual reads like it should be taking the changeovers at the first picture frame regardless, as Marco stated, with no preference to projector (and obviously not playout all the way to end of tail timecode). Do you have timecode status light on the incoming reader at the time the changeover should occur?

Does that LED on the reader follow the AP20 timecode LED indicator and both drop out? etc.

I think the instincts here of the Y cable and wiring being most likely to blame is a good one. But perhaps there is a problematic connection on one of the readers causing similar outcomes.


And yes triple checking your TC Reader Offset for 70mm between the aperture and the reader would be good, remember there is a formula to convert that into the number you put on the XD10/20, if you just put the raw frame count you'll be off, but sync would hopefully reveal that problem. From the manual:

TC Offset.png

Also obviously the trap for people in a hurry is to forget to switch between 35mm and 70mm modes on the XD10/20. (There is also a special venue and smpte modes to avoid as well, unless using them). But hopefully this would reveal first as sync issues rather than change-over issues.

We have a loop of a 70mm DTS print we use to test the readers after configuring for 70mm. It can't test changeover conditions per say... but it might reveal if one reader is having trouble activating promptly with picture and timecode data? For amusement, our victory dance occurs when we hear the cow moo in Dr. Doolittle. ;-)

[Marco Giustini]

but that would mean a BEEP at each P2->P1 reel change? I never really tested that type of changeover though, my changeovers were only one per movie, from P1 to P2 in the middle of the feature.

One final thought, surely unnecessary: Jerry, you're running the latest software, are you?