Radio bot logs in with the right presence but never appears in the Discord voice channel (live) #37

New Issue

2026-10-04T22:42:36-04:00

logan commented

2026-10-04 22:42:36 -04:00

Reported by the owner on live (prod fabdf58, #216/#218/#219/#220): the radio bot comes online in Discord with the correct presence ("Listening to ") but never shows up in the voice channel.

What the code says (origin/main, drb-edge-node/app/internal/discord_radio.py): _set_presence is called only in _ensure_voice, after channel.connect() has returned (and PulseAudio is ready) or when vc.is_connected() is already true (lines ~275-303). So a correct presence means the edge's discord.py believes the voice connection succeeded. The lease, desired-state and token-pickup path worked.

Hypothesis, not verified: this looks like a voice-layer failure (handshake or session dropping right after connect) rather than C2 placement. discord.py[voice] is unpinned in requirements.txt, so the image gets whatever version was current at build time. Discord's voice-protocol requirements (E2EE/DAVE) are one candidate. Check the edge log for voice connect failed, and what discord.py version is in the running image.

Diagnosis aid: server-26 PR #224 makes c2-core log every node-reported stream state transition with the node's error text and reason code. Once it is deployed, docker logs c2-core | grep "Discord stream" shows whether the node reports connected, a flapping connecting -> error [connect_failed], or nothing at all.

Not fixed. Filed from the server-26#213/#221 follow-up session.

Reported by the owner on live (prod `fabdf58`, #216/#218/#219/#220): the radio bot comes online in Discord with the correct presence ("Listening to <system>") but never shows up in the voice channel. **What the code says (origin/main, `drb-edge-node/app/internal/discord_radio.py`):** `_set_presence` is called only in `_ensure_voice`, after `channel.connect()` has returned (and PulseAudio is ready) or when `vc.is_connected()` is already true (lines ~275-303). So a correct presence means the edge's discord.py **believes** the voice connection succeeded. The lease, desired-state and token-pickup path worked. **Hypothesis, not verified:** this looks like a voice-layer failure (handshake or session dropping right after connect) rather than C2 placement. `discord.py[voice]` is unpinned in `requirements.txt`, so the image gets whatever version was current at build time. Discord's voice-protocol requirements (E2EE/DAVE) are one candidate. Check the edge log for `voice connect failed`, and what discord.py version is in the running image. **Diagnosis aid:** server-26 PR #224 makes c2-core log every node-reported stream state transition with the node's error text and reason code. Once it is deployed, `docker logs c2-core | grep "Discord stream"` shows whether the node reports `connected`, a flapping `connecting -> error [connect_failed]`, or nothing at all. Not fixed. Filed from the server-26#213/#221 follow-up session.

logan commented

2026-10-04 22:48:59 -04:00

Review note on the DAVE hypothesis, checked against PyPI today:

discord.py 2.7.0 (2026-02-27) is the first release whose [voice] extra pulls davey (DAVE). Current is 2.7.1 (2026-03-03).
davey 0.1.6 ships cp314 manylinux wheels for aarch64 and x86_64, so the python:3.14-slim edge image resolves it without a Rust build.

So "unpinned" is not by itself a cause: any edge image built after 2026-02-27 already has DAVE. It is only a cause if the running image was built before then. Check pip show discord.py davey inside the running edge-node container before chasing DAVE.

Also: presence was set once and never cleared on origin/main, so a correct presence only proves a join succeeded at some point, not that the bot is in voice now. node-26 PR #38 (fix/discord-voice-join) addresses that plus permission/channel-full pre-checks, which fit this symptom better.

Review note on the DAVE hypothesis, checked against PyPI today: - discord.py 2.7.0 (2026-02-27) is the first release whose `[voice]` extra pulls `davey` (DAVE). Current is 2.7.1 (2026-03-03). - `davey` 0.1.6 ships cp314 manylinux wheels for aarch64 and x86_64, so the `python:3.14-slim` edge image resolves it without a Rust build. So "unpinned" is not by itself a cause: any edge image built after 2026-02-27 already has DAVE. It is only a cause if the running image was built before then. Check `pip show discord.py davey` inside the running edge-node container before chasing DAVE. Also: presence was set once and never cleared on origin/main, so a correct presence only proves a join succeeded at some point, not that the bot is in voice now. node-26 PR #38 (`fix/discord-voice-join`) addresses that plus permission/channel-full pre-checks, which fit this symptom better.

logan added the area/discord

labels 2026-10-05 02:05:13 -04:00

logan commented

2026-10-27 19:27:07 -04:00