#Issue with /vc

1 messages · Page 1 of 1 (latest)

woven niche
#

getting these errors when tracking openclaw logs live when in a /vc with openclaw.
Log file: /tmp/openclaw/openclaw-2026-02-26.log
15:05:46 warn [EventQueue] Slow listener detected: InteractionEventListener took 1966ms for event INTERACTION_CREATE
15:05:57 warn discord/voice {"subsystem":"discord/voice"} discord voice: receive error: Failed to decrypt: DecryptionFailed(UnencryptedWhenPassthroughDisabled)
15:05:57 warn discord/voice {"subsystem":"discord/voice"} discord voice: DAVE decrypt failures detected; voice receive may be unstable (upstream: discordjs/discord.js#11419)
15:05:57 debug cron {"module":"cron","storePath":"/Users/name/.openclaw/cron/jobs.json"} {"nextAt":1772175600000,"delayMs":60000,"clamped":true} cron: timer armed

solid ibexBOT
#

Those three lines are basically three separate things:

1) Slow listener detected … InteractionEventListener took 1966ms

That warning comes from the Discord client/event-queue layer (not “voice” specifically). It means handling a slash-command interaction took ~2s.

  • Usually harmless unless you’re seeing “This interaction failed” in Discord.
  • If it does fail sometimes, it typically means the gateway was busy/blocked (CPU spike, synchronous work, slow disk, very slow model call in the same handler, etc.).

2) Failed to decrypt … DecryptionFailed(UnencryptedWhenPassthroughDisabled) + “DAVE decrypt failures…”

This is the real voice-related one: Discord voice channels are increasingly using DAVE (Discord’s voice E2EE), and @discordjs/voice 0.19.x (what OpenClaw currently uses) has known problems receiving/decrypting audio on DAVE-enabled channels.

The log even points at the upstream tracker: https://github.com/discordjs/discord.js/issues/11419

What this means in practice:

  • Voice receive/transcription may be flaky or totally broken (speaking events / audio segments can be missed).
  • If you’re only joining but not relying on receive/transcribe, it’s mostly just noisy logs.
#

Workarounds (today):

  • Make sure you’re on the latest OpenClaw build (in case deps were bumped): paste openclaw --version.
  • If you don’t need /vc right now, disable Discord voice to avoid the spam:
  • Use Discord voice messages (attachments) or plain text as a stopgap; those don’t rely on realtime voice receive.

3) cron: timer armed … clamped:true

Benign. It just means the cron scheduler armed a timer and clamped the sleep interval (OpenClaw polls cron on a fixed cadence when the next job is far out).

If you paste:

  1. openclaw --version
  2. your Node version (node -v)
  3. whether /vc actually responds (i.e., do you get transcripts / spoken replies?)

…I can tell you whether you’re just seeing the known DAVE warning noise, or if you’re hitting the “zero audio capture” failure mode from that upstream issue.

woven niche
#

2026.2.25, node v22.22.0. /vc was responding after 2 mins yesterday, today no responses.

solid ibexBOT
#

Yep — with 2026.2.25 + Node v22.22.0, that symptom (“worked yesterday, today no responses”) lines up exactly with the DAVE/E2EE receive breakage.

What’s happening

  • Failed to decrypt: DecryptionFailed(UnencryptedWhenPassthroughDisabled) + “DAVE decrypt failures detected” means the bot is receiving voice packets it can’t decrypt.
  • When that happens, OpenClaw’s /vc pipeline can’t capture audio → no transcription → no replies.
  • This is a known upstream issue in the Discord voice stack (@discordjs/voice 0.19.x), tracked here: https://github.com/discordjs/discord.js/issues/11419

Why it was responding “after 2 mins” yesterday

Sometimes you’ll get some decrypted frames (or the channel/client mix temporarily negotiates differently), so it looks like it “eventually wakes up”. Then it flips back into decrypt-fail mode and you get silence again.

What you can do right now

  1. Hard reset the voice session
  • /vc leave then /vc join
  • If that doesn’t help, restart the gateway process entirely.
  1. Try a different voice channel / server
    Some channels seem to behave differently with DAVE rollout. Quick A/B testing tells you if it’s channel-specific.
#
  1. If you need reliability today: disable /vc
    Set channels.discord.voice.enabled=false and use text / voice message attachments instead. (Docs: https://docs.openclaw.ai/channels/discord#voice-channels)

About the other warnings

  • Slow listener … 1966ms is usually just “gateway was busy for ~2s”. Not great, but it wouldn’t explain “no responses” by itself.
  • cron … clamped:true is harmless.

If you want, paste ~30–50 lines around when you /vc join today (including any reconnect/disconnect lines). If it’s doing the classic “Ready → Disconnected → Ready …” loop from the upstream issue, that’s essentially confirmation it’s the DAVE problem and not your config/perms.

woven niche
#

but right now this feature is not possible to run smoothly consistently right now

solid ibexBOT
#

Yeah, that’s a fair takeaway right now.

DecryptionFailed(UnencryptedWhenPassthroughDisabled) + the “DAVE decrypt failures detected” warning means /vc can’t reliably receive audio on many (most) Discord voice channels at the moment, because Discord is rolling out DAVE (voice E2EE) and @discordjs/voice 0.19.x is still unstable with it. When receive breaks, OpenClaw has nothing to transcribe → no replies.

So today /vc is basically best-effort / experimental, not something you can count on to be smooth/consistent.

Practical options:

If you want, share a short snippet around /vc join (showing connect/disconnect behavior). It helps confirm you’re hitting the DAVE failure mode vs. something local.

woven niche
#

does having it setup like i have now but not using it a performance issue for other things? does it need to be disabled or can i leave it as is

solid ibexBOT
#

If you leave your config as-is but don’t actually join a voice channel, it’s basically not a performance issue.

Key point: OpenClaw only starts the expensive parts (voice UDP receive, opus decode, transcription loop, etc.) after it has an active /vc join session (or voice.autoJoin has joined one). If it’s not connected to a VC, there’s nothing to decrypt/transcribe, so no real CPU burn.

When you should disable it:

  • You have channels.discord.voice.autoJoin configured (then it will join on startup and can get stuck in DAVE decrypt/reconnect weirdness → noise + potential CPU/network churn).
  • You’re seeing lots of discord/voice warnings because it’s currently connected (log spam).
  • You want to avoid accidentally using it until the upstream DAVE stuff stabilizes.

How to disable (either works):

  • Set: channels.discord.voice.enabled = false
  • Or remove channels.discord.voice entirely.

Docs section: https://docs.openclaw.ai/channels/discord#voice-channels

If you paste your channels.discord.voice block (redact tokens), I can tell you if you’re in the “safe to leave enabled” case or if autoJoin means it’s actually doing work in the background.