diff options
| author | Luke Hoersten <[email protected]> | 2026-06-20 12:11:54 -0500 |
|---|---|---|
| committer | Luke Hoersten <[email protected]> | 2026-06-20 12:11:54 -0500 |
| commit | 439dadb24c4e07eb11f1aa9804cf7a973518e539 (patch) | |
| tree | 000492fb7928d1ae0c7e42769080f8c5043fd9f6 /TESTING.md | |
| parent | a7fbd013f2bfabcb7a18a7878a959c24ed838110 (diff) | |
scrypted: log node_buf in stream window — confirms script-side buffering
Adds two values to the unified stream log line:
node_buf=NKB≈Mms
node_buf bytes is sock.writableLength — bytes that socket.write()
accepted from us but the kernel send buffer hasn't pulled yet, so
they sit in Node's internal queue. These have NOT been sent over the
wire; the firmware can't have them.
Dividing by the current send rate (bytes/sec computed from the same
window's bytesSent) gives the buffer depth in milliseconds: how many
seconds of already-extracted-from-ffmpeg frames are stalled at the
script. When g2g shows 7s steady state and node_buf shows e.g.
5000-6000KB ≈ 6500ms, the conclusion is obvious — the buffering
isn't in the firmware or on the wire, it's in Scrypted's Node
process.
No behavior change; pure diagnostic.
Diffstat (limited to 'TESTING.md')
0 files changed, 0 insertions, 0 deletions
