Problems with DTS 70mm Playback

[Ryan Gallagher]

Yeah TJ, Someone with more exact DTS implementation knowledge would have to weigh in, but my understanding was the players would switch to a 2nd valid timecode as soon as it was present (or at the FFOA picture start), but that may not be true for reasons of avoiding accidents while threading and advancing to the countdown. DTS readers can after all be mounted in all kinds of weird places with varying offsets. It may be that on most prints without timecode much past the changeover it simply switches seamlessly as the first reader drops offline.

But if there is timecode out there way past the changeover... it may stay on that reel/reader, and perhaps in a couple unusual printings that timecode actually goes beyond the DTS reel file termination, and the hiccup Jerry is experiencing is it staying on a valid reel timecode but with no more reel file information to play? And once that timecode vanishes it then picks up on the subsequent reel?

This would make me think all changeover venues should experience it though. Perhaps Jerry is just paying more attention than most? Or it is a particular quirk of XD20s? Of the modern printings we have only played NxNW and Searchers here. Close Encounters upcoming... but according to Brad this variable tail timecode was before those.

Your instinct that maybe it's not quite up to speed or something at the FFOA could also be relevant, causing it to stay on the prior reel, combined with extensive timecode on certain tails that may go beyond a reel file end point?

What number are you framing on in the countdowns Jerry? (aka how fast or slow is your motor ramp up?) How do your feed reels and clutch tension behave when you first motor on? Is there a lot of overspin or bounce initially before things settle down?

[Tj Hopland]

Not printing on the tails is an interesting tidbit. So if it was on the tail there was perhaps a longer period where it had 2 'valid' codes coming in? So if something wasn't right about the incoming it would maybe see it still had the outgoing and start buffering that again rather than working on the incoming stream? But if it wasn't there then maybe it doesn't get distracted?

Is the signal level check and adjustment procedure in the manuals? Or was that a top secret process? If thats not right I could see it then being sensitive to things like sharpness or density in the printing.

Another thought is do you have a way to measure and compare the speed of your projectors including the ramp up? I no longer remember what the window was or if it changed with different models or software but I do remember having one site that had issues and we eventually figured out the speed was a little off and it was often just on the edge of what the player could handle. It apparently does get into the happy range at some point I'm just wondering if there is something thats going on causing it to take longer to get happy than the other machine.

Maybe the one machine has some belt or clutch slippage assuming stock setup so it takes just a bit longer or maybe hits the minimum speed but then momentarily sags again before locking in? If its a dual motor have those rubber sleeve things been replaced that couple the motor pulley to the main drive shaft? How are the belt(s)? If they are a little stiff and not running daily like they used to maybe they got kinda a set to them and are a little lumpy? With single motor do they both have one or both belts? The dual belts especially as the belts get old and stiff adds a decent amount of drag and that's if the clutch bearings are still happy. Motor caps still within spec and matching between the machines? If its a VFD are they both the same models and programmed the same?

[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.