Feature request: include audio_channels in stream_stats pushed to Dispatcharr

[firestaerter3]

Summary

When Streamflow probes streams and writes stream_stats to Dispatcharr, the payload currently contains:

{
  "resolution": "1920x1080",
  "source_fps": 25.0,
  "video_codec": "h264",
  "audio_codec": "ac3",
  "ffmpeg_output_bitrate": 6887
}

The audio_channels field (and optionally channel_layout) is not included. ffprobe already collects this data during the probe — it just isn't being forwarded to Dispatcharr.

Why it matters

Downstream consumers of stream_stats (e.g. Emby plugins that read from the Dispatcharr API) need the audio channel count to make correct client-compatibility decisions.

Concrete example: An Emby plugin reading stream_stats for a channel with audio_codec: "ac3" has no way to know it's 5.1 (6ch) vs stereo (2ch). Without this, Emby cannot correctly evaluate whether the client (e.g. iOS or Apple TV) can handle the audio natively or needs it transcoded to AAC. The result is silent audio playback on Apple devices for AC3 5.1 channels.

HDHomeRun tuners work correctly in the same setup because Emby probes those streams directly and discovers channels: 6 from ffprobe.

Requested change

Add audio_channels (integer) to the stream_stats payload written to Dispatcharr:

{
  "resolution": "1920x1080",
  "source_fps": 25.0,
  "video_codec": "h264",
  "audio_codec": "ac3",
  "audio_channels": 6,
  "ffmpeg_output_bitrate": 6887
}

Optionally also include channel_layout (e.g. "5.1(side)", "stereo") if that's available from your ffprobe output.

ffprobe already returns this in the streams[].channels field when analyzing audio tracks, so it should be straightforward to add to the payload.

Workaround in use

Without this field, downstream plugins have to fall back to codec-based heuristics (AC3/EAC3 → assume 6ch, MP2 → assume 2ch). This works for the common case but fails for edge cases like stereo AC3 or non-standard layouts.