Bug Report: Issue with tacview stream

[red-one1]

Describe your issue

After upgrading to 0.9, now I get an error when connecting to a server:

7:39PM ERR error reading telemetry, retrying error="error reading updates: error reading ACMI stream: error parsing object update: error parsing object ID: strconv.ParseUint: parsing "====================0": invalid syntax"

Steps to Reproduce

Connect to server

Log File

No response

Logs

7:42PM INF resetting ACMI client state
7:42PM INF sending mission start message
7:42PM INF clearing all trackfiles due to mission (re)start
7:42PM INF clearing pending FADED trackfiles due to mission (re)start
7:42PM INF clearing FADED trackfile history due to mission (re)start
7:42PM ERR error reading telemetry, retrying error="error reading updates: error reading ACMI stream: error parsing object update: error parsing object ID: strconv.ParseUint: parsing "====================0": invalid syntax"

ACMI File

No response

Operating System

Linux

CPU

yes

RAM

yes

Other Software

No response

[dharmab]

Post your ACMI file and I can take a look

[dharmab]

Analysis

Error source

The ACMI stream format uses newline-delimited records where the first field on each line is a hexadecimal object ID. strconv.ParseUint("====================0", 16, 64) fails because = is not a valid hex digit.

Likely cause

The ACMI 2.x spec requires that any newline embedded in a property value be escaped — a raw \n byte inside a value is a spec violation. The global object (0) carries the mission Briefing property, set by the mission creator in the DCS mission editor. If Tacview is forwarding that text to clients with a raw newline rather than escaping it, that would be a Tacview bug.

If the briefing text contains a raw, un-escaped newline, SkyEye's line reader splits there. The text after the newline becomes its own "line" and is routed to the object-update parser, which tries to parse everything before the first comma as a hex object ID. The specific text ====================0 appearing in the error suggests the content after such a newline starts with = characters — consistent with formatting text in a mission briefing — followed by 0, which is the ACMI ID of the global properties object (the next record in the stream).

Why this appeared in v1.9.0

Prior to v1.9.0, a stalled ACMI stream connection would hang silently — a bug fixed in v1.9.0 (#665). With that fix, SkyEye now detects stalls and reconnects. Any parse failure also causes a reconnect. If the malformed line is present in the initial state dump (which a Briefing field would be), reconnecting re-reads the same data and the error loops — which is the behavior reported here. In v1.8.1 the connection would have simply stalled silently rather than producing this visible error.

Potential workaround

SkyEye could log a warning and skip unrecognized lines without dropping the connection, rather than treating every parse failure as fatal.

To confirm

Attaching the .acmi file (or a Tacview stream recording) would let us verify whether the briefing field contains an un-escaped newline.

---

🤖 Generated with Claude Code

[red-one1]

Here's the ACMI file that DCS recorded

[red-one1]

http://quickdrop.probabilitydegeneration.net/share/dqjsP

[dharmab]

http://quickdrop.probabilitydegeneration.net/share/dqjsP

This is giving a "link expired" error.

[red-one1]

Try this
http://quickdrop.probabilitydegeneration.net/share/MSTgP

[red-one1]

Confirmed the root cause and put together a fix.

This was not just a malformed Comments/Briefing field by itself. SkyEye was
reading the same ACMI stream from two goroutines: one background goroutine was
reading newline-delimited records, while handleLine() could also read extra
continuation lines directly from the same buffered reader when a line ended with
\.

When Tacview sends a multi-line global property like Comments, those reads can
interleave and splice the next record into the continuation block. That is how
we end up trying to parse something like ====================0 as an object
ID.

I changed the telemetry reader so only one goroutine consumes the ACMI stream,
and it now assembles a full logical ACMI record before handing it to the parser.
I also added regression tests using the same continuation pattern seen in the
sample ACMI.
#693

[dharmab]

Thanks for the patch! I'm working on a bugfix for Victor Romeo Sierra as well, after both are merged I can do some manual testing and then release a new version.

[dharmab]

Released in v1.9.1, thanks again for the report, investigation and fix!!