6.1 Basic Troubleshooting and Technical Escalation

Key Takeaways

  • Protect current capture before troubleshooting; avoid changes that could destroy the only usable source.
  • Troubleshoot from symptom and signal path, changing one variable at a time and verifying after each change.
  • Escalate when the fix exceeds authority, risks the record, requires protected access, or does not restore verified capture promptly.
  • Technical incident notes should record observed facts, timing, actions, results, and authority without speculation.
Last updated: September 2026

Stabilize before changing

When a warning appears, first determine whether the record is still being captured somewhere. Preserve the working primary or backup, note the time, and use the established interruption protocol if completeness is threatened. Do not restart every device, unplug shared equipment, delete files, or change several settings at once. Broad changes erase diagnostic clues and may stop the only good path.

Describe the symptom, not an assumption: “Channel 3 has no recorded signal after 10:14” is useful; “the microphone is broken” may be wrong. Check whether the issue affects one source, one track, all tracks, monitoring only, playback only, storage, or the remote connection.

Trace the path

For one silent channel:

  1. Confirm the intended speaker and microphone.
  2. Check mute, power, battery, physical connection, and cable strain.
  3. Inspect the interface input and preamp meter.
  4. Confirm software device, input route, arm state, and track mute.
  5. Check file-write status and confidence return.
  6. Substitute one known-good compatible component if authorized.
  7. Record and replay a short test.

If every channel is silent, look for shared points: power, selected device, driver, software state, storage error, or master routing. If only headphones are silent while recorded meters and playback through another authorized output are good, the fault may be the monitor path. Never infer file quality from one indicator.

Common symptoms

SymptomLikely areas to inspect
Hum or buzzCable shielding, power relationship, damaged connector, nearby electrical source
ClippingPreamp/input level, source distance, overload before software
DropoutsCable, wireless link, USB/network load, driver, storage
Echo in hybrid sessionDuplicate return paths, open speakers and microphones, platform routing
Wrong speaker on trackPhysical patch, software route, label, seating change
File stops growingRecord state, storage capacity, permissions, application error

These are starting points, not diagnoses. Verify.

Escalation

Escalate to the designated courtroom technician, platform support, agency supervisor, or system administrator when:

  • the record is at risk and a simple approved action did not restore it;
  • the change requires administrator credentials or protected configuration;
  • installed equipment, network, server, or platform infrastructure is involved;
  • a safety, security, suspected tampering, or data-loss incident exists;
  • continuing tests would create greater disruption or uncertainty; or
  • the assignment protocol requires immediate reporting.

Provide concise information: job and room, time, exact symptom, affected sources, error text, verified working paths, actions already taken, backup status, and how to contact the presiding authority. Avoid hiding an error or flooding support with unsupported theories.

During a live failure

If the primary fails and the backup is confirmed, the authorized process may permit a transition. Announce or document the gap and restart point as directed. A backup that records only a room mix may preserve speech but lose isolation; disclose that limitation. If neither path is verified, promptly notify the presiding official. Participants may repeat or reconstruct only under that authority; the reporter should not silently fill words from memory.

Incident documentation

Record objective facts: warnings, timestamps, files, channels, observed duration, participant instructions, equipment changes, people notified, and verification results. Preserve logs and affected files. Do not edit records to make the incident disappear. A later review needs to distinguish what was captured, what was inferred, and what corrective action was authorized.

Simple versus unsafe troubleshooting

Simple work includes checking connections, selections, power, space, mute and arm states, and replacing a known-good approved cable. Unsafe or unauthorized work includes opening powered hardware, changing court network security, installing unknown drivers, formatting media, or experimenting with the master file. Competence includes knowing that boundary.

Exam application

For practice, classify faults by scope before selecting a fix. One silent microphone suggests its source path; every silent track suggests a shared device, driver, application, or power issue; good recorded files with silent headphones suggest monitoring. Then state the least risky check and the escalation threshold. If a fix needs administrator access or could interrupt the verified backup, stop experimenting. Precise facts—time, channel, error message, current capture, and attempted step—help support act quickly without forcing the reporter to pretend to know the root cause.

Half-split the signal chain

Testing every component in order wastes minutes a live proceeding does not have. Cut the chain in half instead, test the midpoint, and discard the half that proves good. A typical capture chain runs source, microphone, cable, preamp or interface input, driver, software input, armed track, written file, with a parallel monitor return.

Worked example: channel 3 is silent in the recording. Look at the interface's own hardware input meter first, because it sits near the middle of the chain. If that meter moves when the witness speaks, everything from microphone through preamp is functioning and the fault lies in the software route, device selection, arm state, track mute, or file write. If the hardware meter is dead, the fault lies upstream in the microphone, its mute switch, battery, cable, or connector. One observation eliminates roughly half the candidates.

Midpoint observationWhat it eliminates
Interface meter moves, track silentMicrophone and cable
Interface meter deadSoftware route and file path
File size still growing, headphones silentCapture itself; suspect the monitor path
Every track silent simultaneouslySingle-channel causes

Competence is an ethical duty

AAERT's Code of Professional Ethics expects members to understand the operation of their own software and hardware and to perform basic troubleshooting. That expectation sets both a floor and a ceiling. The floor: a reporter who cannot swap a cable, reselect an input device, or confirm that a file is still being written is not meeting a professional obligation. The ceiling: basic troubleshooting is not system administration, so credentialed configuration, court network changes, and installed-infrastructure repair belong to the designated technician.

Carry known-good spares

A small spare kit turns many faults into a thirty-second substitution: one tested balanced cable, an adapter set, a spare microphone of a type already in the setup, charged batteries, spare storage, and a fully independent backup recorder. A spare you have never actually recorded with is not known-good — test spares on the same schedule as primary equipment.

Test Your Knowledge

A primary recorder reports a storage error while an independent backup remains verified. What should the reporter do first?

A
B
C
D