Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

Omarchy radio MP3 stream plays ~1-4 min then emits digital silence while showing Playing (2.0.1 & 2.3.0)

Open
  • Is something wrong?
#609 0 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
4/5
Estimated time
3-5 days
Newbie friendliness
18/100
Issue type
Bug
Clarity
Mostly clear
Activity status
Active
Tech stack
go
Domain
audio-video-rtc

Research direction

The issue points at the stream-feed path for MP3 HTTP radio with ICY metadata, including the ICY metadata reader and the ffmpeg fallback for radio streams that it cites as prior fixes. Start by reproducing with the stream URL in the issue and the measurement one-liner, then see where PCM stops being committed while the playing state stays set. Done means the Omarchy stream keeps producing non-silent output past four minutes, confirmed with the same volumedetect check.

Written by the indexing model from the issue text.

Description

Summary

cliamp plays the Omarchy radio stream (http://radio.cliamp.stream/omarchy/stream) for ~1–4 minutes, then stops producing audio entirely while the UI keeps reporting "Playing." The track position keeps advancing, the connection to radio.cliamp.stream stays up, but the PipeWire sink receives pure digital silence. Reproduced on both cliamp 2.0.1-1 (Omarchy repo) and cliamp 2.3.0 (AUR cliamp-bin), freshly installed.

Environment
  • OS: TryOmarchy (Arch) running under QEMU/KVM, virtio-snd
  • Audio: PipeWire + wireplumber, pipewire-pulse and pipewire-alsa (cliamp uses the libasound path)
  • Stream format probed as MP3 (codec mp3, format mp3, carries ICY metadata)
Repro
  1. cliamp, open http://radio.cliamp.stream/omarchy/stream (it is the resume default).
  2. Wait 1–4 minutes.
Observed while it "plays"
  • Default-sink monitor measures pure digital silence:
    mean_volume: -91.0 dB / max_volume: -91.0 dB (ffmpeg volumedetect)
  • Process CPU flatlines; then on 2.3.0 the process sometimes exits entirely (no socket, no coredump).
  • Stall episodes correlate with host-side (VM host) activity — e.g. interacting with the host GUI stops it immediately. Correlation noted, not proven causal; the silence is produced in-process, into cliamp's own sink.
Control: same route, different player

The identical audio path plays indefinitely with mpv (--ao=alsa = libasound, same as cliamp, and --ao=pulse) and paplay. Healthy reading on that route: mean_volume: -25.3 dB / max_volume: -8.1 dB. The PipeWire graph and bridge are proven good.

Suspect

MP3 HTTP radio streams with ICY metadata. Related prior fixes ("fix(player): keep ICY metadata reader attached for ffmpeg radio streams", "fall back to ffmpeg for non-Vorbis OGG HTTP streams") suggest this family: the stream-feed reader wedges mid-playback and the player stops committing PCM while its state machine stays "playing."

Measurement one-liner (run while it claims to play)
parec --device="$(pactl get-default-sink).monitor" --channels=2 --format=s16le \
  | ffmpeg -v info -f s16le -ar 44100 -ac 2 -i - -af volumedetect -f null -

Happy to run patched/debug builds, capture cliamp.log around a stall, or add verbose logging.

Dominant language
Go
Stars
4.4k
Forks
307
Avg merge
2d 21h
Merged PRs (30d)
56

Getting set up

  • No Dockerfile or Docker Compose file
  • Has a pull request template
  • No contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from bjarneo/cliamp

All issues in bjarneo/cliamp

Similar issues

More Go issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.