Timecode resource

Timecode Troubleshooting

Published July 8, 2026

Article goal: Help live production teams troubleshoot common timecode problems quickly, without turning tech rehearsal into a courtroom drama.

Troubleshooting Common Timecode Issues

Timecode is supposed to make the show feel locked, clean, and expensive. Playback rolls, lights chase, video lands, lasers snap, automation behaves, and everyone pretends this was easy the whole time.

But when timecode gets weird, it gets weird in a very specific way. The cursor jumps. The console loses lock. Resolume teleports to another century. The chorus hits and everything stops following. Someone on comms says, “Are we getting code?” and then the room becomes a tiny crime scene.

The good news: most timecode problems are not mystical. They are usually routing, level, frame rate, offset, warping, buffer size, or one bad cable that has somehow survived twelve festivals and should have been thrown away during the Obama administration.

This guide is a practical field list for the problems that actually happen in live concert workflows.

First rule: prove the signal exists

Before you start blaming the console, the DAW, the media server, the lighting network, the house crew, the moon, or “that one adapter,” verify that you are actually receiving timecode.

LTC is audio. That means you can test it like audio.

A real LTC signal should sound like robots screaming into a fax machine. Beautiful? No. Useful? Extremely.

If the receiving device says “no timecode,” start with the simple questions:

Is playback actually playing?
Is the timecode track unmuted?
Is the timecode output routed to the correct physical output?
Is the cable patched to the correct input?
Is the receiving device listening to the correct input?
Is the frame rate correct?
Is the signal loud enough, but not clipping?

Do not skip the boring stuff. The boring stuff is where the bodies are buried.

The headphone stethoscope trick

If you are handed an XLR line and told, “That’s timecode,” you are allowed to verify. Politely. Professionally. With just enough side-eye to stay alive.

Carry a simple XLR to 1/8-inch cable or adapter setup and a cheap pair of normal headphones. Plug in carefully, keep the headphone level low, and listen for the signal.

You are asking one question:

Does this line actually sound like timecode?

If it sounds like robots screaming, great. If it sounds like click, tracks, pink noise, silence, local country radio, or someone’s talkback mic, then congratulations, you have found the problem before sacrificing three hours to the troubleshooting gods.

Important: do not blast your ears. LTC can be loud and deeply unpleasant. Treat it like a tiny angry animal.

Problem 1: Timecode cuts out right at the big chorus

This one is sneaky, and it happens more often than people want to admit.

The symptom: timecode seems fine during the intro and verse, then suddenly drops, glitches, or loses lock right when the chorus gets huge.

The cause may be that backing tracks, click, or other musical audio are accidentally routed through the same output as the timecode. When the arrangement gets dense, that musical audio contaminates the LTC line. The receiving device stops seeing clean code and starts seeing a cursed smoothie of timecode plus music.

Very rude. Very real.

Quick test

Ask playback to mute only the timecode track, then press play.

If you still hear music coming down the timecode line, that output is not isolated. You are not receiving a clean LTC feed. You are receiving a group project.

This can happen inside the DAW routing, the audio interface mixer, a monitor mix app, a matrix, or a digital patch layer. Playback may believe the timecode output is discrete, but the interface software might be secretly blending other channels into it. Little goblin behavior.

Fix

Make the timecode track output a dedicated physical output.
Check the DAW routing, not just the track name.
Check the audio interface mixer software.
Disable any “mix to all outputs” or monitor routing that includes the timecode output.
Confirm that click, tracks, guide, and talkback are not feeding the LTC line.
Run the mute test again after changes.

The timecode line should carry timecode and only timecode. It is not a friendship bracelet. It does not need everyone included.

Problem 2: Musicians hear quiet timecode in their ears

The symptom: the timecode system works, but someone on stage hears a faint digital chatter in their IEMs, playback lines, or monitor mix.

Usually, this means timecode is bleeding into another output. Sometimes it is routing. Sometimes it is analog crosstalk. Sometimes the audio interface has less channel isolation than the marketing brochure suggested. Shocking, I know.

This can happen when LTC is running very hot on an output that sits physically or electrically close to critical playback channels.

Quick test

Solo or monitor the affected musician line and listen during a section where timecode is running. Then mute only the timecode track.

If the little robot ghost disappears when the timecode track mutes, you have bleed or routing contamination.

Fix

Turn down the timecode track from the DAW.
Move the timecode output to a physical channel farther away from critical playback outputs, if the interface layout allows it.
Avoid placing LTC beside sensitive IEM or click channels when possible.
Check the interface mixer for hidden sends or monitor blends.
Use a better-isolated interface or dedicated output device when the rig allows.

In a pinch, LTC often does not need to be screaming hot. You can usually get away with sending the timecode track around -18 dBFS and still have a usable decode, depending on the receiving gear and signal path.

The vibe is “healthy signal,” not “punish the input.” If the receiving device locks happily at a lower level and the band stops hearing robot bees in their ears, that is a win.

Problem 3: Ableton stretched the timecode file

Ableton is great. Ableton also loves warping audio, because that is literally one of its superpowers.

That is awesome for loops. It is not awesome for LTC files.

The symptom: the timecode starts, stops, loses frames, jitters, or feels like it is constantly falling apart even though the routing seems correct.

The cause may be that Warp is turned on for the timecode audio file. If Ableton is stretching the LTC file to match the Set tempo, the waveform is no longer a clean timecode signal. Your receiving device is trying to decode a clock that has been yoga-stretched into sadness.

Quick test

Open the timecode clip in Ableton and check whether Warp is enabled.

Also check Ableton’s preferences for Auto-Warp Long Samples. If long files are being automatically warped when imported, timecode files can get caught in the crossfire.

Fix

Turn Warp off on the timecode clip.
Disable Auto-Warp Long Samples for live playback rigs that use long LTC files.
Re-import or regenerate the LTC file if it was already warped and saved in a questionable state.
Confirm the file plays at original speed, unaffected by the Set tempo.
Test the receiving device again and watch for stable frame movement.

Timecode does not want to groove. It wants to be a ruler. Let the tracks be musical. Let the LTC be boring.

Problem 4: Resolume jumps to wild random timecode values

This one is a special little video goblin.

The symptom: Resolume Arena sees SMPTE, but the timecode display randomly jumps to extreme, unrelated values. One second you are at the song intro, the next second Resolume thinks it is in hour 17 having a spiritual crisis.

If your routing, frame rate, and offset are correct, check the audio buffer size in Resolume’s Preferences.

A buffer size that is too low can cause audio glitches. For normal audio playback, that might sound like clicks or pops. For LTC, those glitches can become bad data, which can make the decoder misread the incoming time address.

Quick test

In Resolume, go to Preferences and check the audio buffer size. If it is set very low, raise it.

Fix

Increase the Resolume audio buffer size.
Try 1024 samples as a stable starting point.
Confirm the correct audio input device is selected.
Confirm the correct SMPTE input channels are selected.
Confirm the SMPTE frame rate matches the source.

For timecode chasing, a slightly larger buffer is often totally fine. You are not playing a virtual drum kit from a keyboard. You are decoding a clock. Stability beats ultra-low-latency chaos here.

Problem 5: The line is not actually timecode

Sometimes the problem is not frame rate. It is not offset. It is not drop frame. It is not the software.

Sometimes the line you were given is simply not the line you asked for.

This can happen at festivals, one-offs, corporate rooms, shared house patch systems, or any venue where the same five adapter cables have seen unspeakable things.

XLR cables go bad. Adapter cables go bad. Festival subsnakes get mislabeled. Someone patches one end and assumes the other end is still correct. The bad cable gets coiled back onto the pile for the next show like a haunted heirloom.

We love production. Production does not always love us back.

Quick test

Use the headphone stethoscope trick. Listen carefully and confirm that the line sounds like LTC.

Then verify the receiving device is seeing a real timecode address, not just audio activity.

Audio present does not always mean valid timecode. A meter bouncing is not the same as a decoder locking.

Fix

Swap the XLR cable.
Swap the adapter.
Bypass the house run if possible and test locally.
Ask playback to send a known timecode test file.
Confirm the receiving device locks at the playback position you expect.

And yes, you can trust the sound team. Mostly. But verify anyway, because even the best humans are defeated by one bad barrel connector every now and then.

Problem 6: The festival timecode run changes the code

This one is a dignity thief.

You hand off timecode at one end of the festival system. At the other end, you receive something that looks like timecode, but the frame rate, offset, or behavior is different.

The symptom: your device locks, but the address is wrong. Or the code is stable but in the wrong frame rate. Or the source starts at 01:00:00:00 and what you receive is clearly not that.

What happened?

Sometimes festival teams are not just passing your LTC through copper. They may be running it through a timecode regenerator, converter, show-control box, matrix, or distribution system. Those tools can be useful, but if they are set wrong, they can “help” your signal into being completely incorrect.

Classic overly clever festival energy. The intent is service. The result is a side quest.

Quick test

Ask one direct question:

“Is this a straight copper pass, or is the timecode being regenerated, converted, or processed anywhere?”

Then verify:

Incoming frame rate
Outgoing frame rate
Drop or non-drop
Offset
Whether the box is set to auto-detect or a fixed frame rate
Whether the output is regenerated from the input or running from an internal generator

If a regenerator is involved, ask whether the frame rate is set to Auto or manually fixed. A fixed setting can quietly convert your clean incoming show code into something your rig does not expect.

Fix

Set the regenerator or converter to auto-detect when appropriate.
Manually match the exact frame rate if auto is not reliable.
Verify drop vs non-drop.
Bypass the regenerator if all you need is a physical line.
Test at both ends with the same known start time.

This is where you get your sense of dignity back. Not by arguing, but by proving what entered the system and what came out of it.

Problem 7: The frame rate is wrong

The symptom: the system locks, but cues drift, video does not line up, or devices disagree about where they are.

Frame rate mismatches are sneaky because the rig may look “mostly fine” at first. Then the longer the song runs, the more cursed it becomes.

Common mismatches include:

30 fps source, receiver set to 29.97
29.97 source, receiver set to 30
29.97 drop source, receiver set to 29.97 non-drop
25 fps content workflow, receiver set to 30

Quick test

Check the frame rate at every point in the chain:

Playback session
LTC file or generator
Converter or regenerator
Console or media server input
Any timecode distribution hardware

Do not accept “it is basically 30.” Timecode does not care about vibes.

Fix

Pick the correct frame rate based on the show’s content and video world, then make every device agree.

Use 30 fps for many true 60 fps live production workflows.
Use 29.97 when the video or broadcast world is based on 59.94.
Use 25 fps for 50 fps or European broadcast-style workflows.
Use 24 fps when the content pipeline is truly cinema-style 24 fps.

Write it down. Frame rate, drop/non-drop, and offset should be on the show’s timecode map, not buried in someone’s memory next to catering preferences.

Problem 8: Drop frame and non-drop frame got mixed

The symptom: everything seems close, but timing is weird over longer sections, especially in 29.97 workflows.

Drop frame does not drop actual video frames. It skips certain frame numbers so 29.97 timecode stays closer to real elapsed clock time. That matters in broadcast. Most concert show-control rigs use non-drop unless broadcast or recording has a reason to require otherwise.

Quick test

Ask the source team exactly what they are sending:

29.97 drop frame
29.97 non-drop
30 non-drop

If the answer is “uhhh,” pause the meeting and solve that before programming the entire show into a swamp.

Fix

Match drop/non-drop on every device.
Use non-drop for most concert lighting and show-control workflows unless broadcast requires drop.
Document the decision in the show file and playback notes.

Drop frame is not evil. It just needs adult supervision.

Problem 9: The computer is “improving” your audio

The symptom: timecode from a computer output will not lock, or it jumps to different values even though the file seems correct.

Some operating system audio settings can process the output. “Audio enhancements” are lovely for laptop speakers and extremely suspicious for LTC. Timecode wants a clean waveform, not a laptop deciding to add secret sauce.

Quick test

If you are playing LTC from a Windows machine, check the output device settings and look for audio enhancements, spatial audio, loudness processing, or anything that claims to improve the sound.

Fix

Disable audio enhancements on the output device.
Use a dedicated audio interface instead of a built-in headphone jack when possible.
Avoid system-wide EQ, limiting, normalization, or spatial audio.
Send the LTC through a clean, direct output path.

Timecode is not music. Do not master it. Do not vibe it. Do not put a little sparkle on the top end. Let the angry square wave live its truth.

Problem 10: The signal is too quiet, too loud, or distorted

The symptom: the receiving device locks sometimes, loses lock randomly, or only reads timecode when the level is in a very specific place.

LTC is audio, so level matters. Too quiet and the decoder may not see it reliably. Too loud and the signal can clip or distort. Either way, the receiving device gets confused.

Quick test

Watch the input meter, if the receiver has one. If you have software or hardware that shows the waveform, use it. A healthy LTC waveform should look stable and consistent, not smashed into the ceiling or barely above the noise floor.

Fix

Turn down the DAW output if the signal is clipping.
Turn up the output or preamp if the signal is too low.
Avoid compressors, gates, limiters, EQ, and automatic gain control.
Use balanced lines when the run is long or electrically noisy.
Test at the receiving end, not only at playback.

If you are in a pickle, lowering the DAW timecode track to around -18 dBFS can often clean up bleed and still leave enough signal for many receivers. The correct final level depends on the receiving gear, but “clean and stable” beats “loud and crunchy” every time.

Problem 11: The DAW output routing is lying to you

The symptom: the DAW track is routed correctly, but the physical output is still wrong.

This is where interface mixer software enters the chat.

Many audio interfaces have their own routing layer separate from the DAW. That mixer can send playback channels to multiple outputs, blend outputs, mirror mixes, or apply monitor routing that the DAW does not show you.

Quick test

Open the audio interface control software and inspect the physical output that carries timecode.

Look for:

Playback channels assigned to the timecode output
Mix buses feeding multiple outputs
Monitor mixes copied to all outputs
Loopback channels
Hidden software returns

Fix

Make the LTC output discrete.
Remove all non-timecode sources from that output.
Save the interface routing preset with a clear name.
Reload the preset after reboot and confirm it actually stuck.

DAW routing is only half the story. The interface mixer is the secret second show file.

Problem 12: MTC is present, but the receiving app still will not chase

When using MIDI Timecode, the problem is often not the timecode itself. It is the route.

The symptom: the DAW says it is sending MTC, but grandMA3 onPC, a show-control app, or another receiver does not move.

Quick test

Confirm the full MIDI path:

Is the DAW actually generating MTC?
Is MTC routed to the correct virtual MIDI output?
Is the receiving app listening to the matching MIDI input?
Is another app already grabbing the port?
Is the MIDI route one-way when you thought it was two-way?

Fix

Use a clean MIDI routing layer instead of a spaghetti pile of virtual ports.

This is where Duckport MIDI is extremely useful. It gives show computers a cleaner way to route MIDI between playback, consoles, controllers, and timecode tools without turning the rig into “which port named MIDI 2 is the real one?”

For example, if REAPER is generating MTC and grandMA3 onPC needs to receive it, Duckport MIDI can sit in the middle as the readable routing layer. Less mystery. More lock.

Problem 13: You need to diagnose LTC, not just hope it works

Sometimes the most frustrating timecode problem is not knowing where the problem is.

Is playback sending LTC? Is the line clean? Is the waveform clipped? Is the frame rate wrong? Is the receiver being dramatic? Is the audio interface betraying you?

This is exactly where DuckTC fits into the workflow. DuckTC can receive LTC from an audio interface, convert it to MTC, and show useful signal-health information like waveform and oscilloscope-style views.

That means you are not just staring at a console waiting for it to chase. You can actually see whether the incoming LTC looks healthy.

Use DuckTC when:

You need to convert LTC to MTC for PC-based systems.
You want to verify that LTC is really arriving.
You need waveform visibility for troubleshooting.
You are building a headless timecode playback or conversion machine.
You want less show-day guessing and more actual evidence.

Hope is cute. Signal visibility is better.

A fast troubleshooting order that usually works

When timecode breaks, do not troubleshoot randomly. Use an order. Random troubleshooting is how tech rehearsals become folklore.

Verify source playback. Is the DAW or generator running?
Verify the actual line. Listen carefully or decode it with a tool.
Check routing. DAW output, interface mixer, patch, adapters, receiving input.
Check contamination. Mute timecode and see whether music still appears on the line.
Check level. Not too quiet, not clipping, no processing.
Check frame rate. Source, converters, receivers, media servers, consoles.
Check drop vs non-drop. Especially in 29.97 workflows.
Check offsets. Make sure the received address is the address you expect.
Check software-specific gremlins. Ableton Warp, Resolume buffer size, Windows audio enhancements.
Bypass things. Remove festival regenerators, mystery adapters, and extra converters until the problem disappears.

The goal is to make the problem smaller. Every bypass is a flashlight.

The show-day checklist

Before doors, confirm this:

The timecode source is known.
The frame rate is documented.
Drop or non-drop is documented.
Song offsets are documented.
The receiving devices show the expected address.
LTC is isolated from click, tracks, guide, and talkback.
The LTC line is not routed to PA, ears, stream, or broadcast mix.
The level is healthy and not clipping.
Ableton Warp is off for LTC files.
Resolume buffer size is stable, with 1024 as a perfectly reasonable starting point.
Any festival timecode distribution is verified as straight pass-through or correctly configured regeneration.
There is a manual fallback if timecode dies mid-show.

That last one matters. A good timecoded show should still have a survival mode. The audience does not know your LTC line failed. They know whether the stage suddenly looks like a rehearsal room.

The big takeaway

Timecode troubleshooting is mostly about proving what is actually happening.

Is the source sending clean code? Is the line isolated? Is the signal healthy? Is anything secretly processing it? Is the frame rate correct? Is a converter changing it? Is the software stretching, glitching, or misreading it?

Do not guess. Verify.

Mute the timecode track and listen for leaked music. Turn Warp off. Raise the Resolume buffer. Lower an overly hot LTC track. Move the timecode channel away from critical playback outputs. Ask whether the festival line is copper or a regenerated signal. Carry the weird little headphone adapter. Use tools that show you the waveform instead of making you stare into the void.

Timecode is just a clock. But on show day, that clock is holding hands with lighting, video, lasers, playback, automation, and everyone’s blood pressure.

Keep it clean. Keep it documented. Keep the robots screaming only where they belong.