Problems with DTS 70mm Playback

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

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

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

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?

[Ryan Gallagher]

Specifically, because Jerry is "hearing" the dropout... it's either going longer than 2sec without a valid timecode (the buffer size), or it has a timecode (perhaps in the tail) but is running out of information in the reel file (and for whatever reason has not taken the subsequent reel and timecode when it logically should have).

[Marco Giustini]

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.

You can check the video level (the LED brightness level basically) by checking the voltage on two test points on the heads. For a better check, you can check the actual signal with an oscilloscope - it's a simple signal, you're just looking for a clear output basically.

I don't think that not having timecode on leaders could be our problem here. Even if timecode ended at the last frame and started at the first frame of the following reel, the XD20 would still have time to seek and play while the FFOA reached the gate.

What if the affected print simply had bad timecode at the beginning of some reels? Again, this is 2025 and film knowledge is fading away. What if the affected prints were just badly printed and DTS timecode is unreadable/missing from the beginning of the affected reels? Or simply not contrasted enough and Jerry's heads are a bit weak.

One more thing: in my experience with DTS I have encountered a few heads which simply refused to work reliably, no matter how much I tried to adjust them, even guided by DTS tech support. On both systems where I experienced those issues, a replacement or repair/exchange head had always fixed reading issues. In both cases the head went from Rev F. to Rev H. PCB revision can be seen without disassembling the heads, but the 9-pin connector needs to be unplugged to peek inside.

it's either going longer than 2sec without a valid timecode (the buffer size)

Buffer size should be 4.5s AFAIK - unless you run out of data on the file (i.e. at the end of the reel)

[Tj Hopland]

What I was wondering is if its locking onto the incoming code but for some mechanical reason it momentarily becomes invalid but it still has the outgoing code so it gets a little confused and maybe tries to switch back but then the incoming becomes valid again. In the confusion its runs out the buffer or doesn't have the time to do its live editing that it normally does between the reels so it drops out? That's why I'm focused on making sure there is nothing mechanically causing it. There is a decent amount of film and a bunch of rollers between that heavy reel and the first sprocket so it doesn't take much to upset things especially at first when you are going from zero to full speed fairly quickly.

[Marco Giustini]

A mechanical check won't hurt.

But to me it sounds like it's not accepting the timecode from the following reel UNTIL the timecode from the preceding reel has completely run out.

Jerry,
I forgot: if you attach a set of logs and indicate a date and a movie title, we can see what happened. There is a log file which shows exactly all the timecode edits etc. I don't know if it also shows P1 and P2, that would be great. But it does shows dropouts so it would help a lot.

I cannot remember if it's the Diagnostic logs or the Logs - if you can extract both and attach them here, that would be helpful