Thank You mpv — Building a 24/7 Discord Radio on an Old ASUS Laptop

[VardoDalgurak]

Building DJ Murloc — My Experience Using mpv for Discord Audio Streaming

Hello to the mpv developers and community!

First, I would like to apologize for originally posting a report addressed to Music Player Daemon (MPD) in the mpv discussion section. I confused the two projects.

Thank you to the community member who pointed out my mistake.

Rather than leaving an unrelated report here, I have rewritten it to focus specifically on mpv, which has become an essential part of my project.

I also want to thank the developers and maintainers for making this excellent software available.

1. My Project: DJ Murloc / Radio EAF

I'm a Linux beginner living in Norway.

I wanted to reuse an old ASUS laptop to create a small music and announcement system for approximately five friends who play World of Warcraft together.

The computer has:

• Intel Celeron N2840 processor
• Approximately 2 GB RAM
• antiX Linux
• Firefox ESR running Discord Web

The laptop stays powered on with its lid closed, and I administer it remotely using SSH.

My goal was to play music, automatically insert funny raid announcements and send the resulting audio to a private Discord voice channel.

I wanted to achieve this without purchasing commercial radio automation software.

2. Why mpv Is Important to My Setup

MPD handles the music library, Internet radio streams and scheduled announcements.

However, I needed a way to take the resulting HTTP audio stream and send it to a virtual microphone that Discord Web could use.

This is where mpv became particularly useful.

Our audio chain is:

MPD → HTTP MP3 stream → mpv → PipeWire virtual sink → Virtual microphone → Discord Web.

mpv reads the stream from:

http://127.0.0.1:8000

and sends the audio to a PipeWire virtual sink named dj_murloc, using the PulseAudio-compatible output.

The corresponding virtual microphone, dj_murloc_mic, is selected as the microphone input in Discord Web.

This approach allowed us to transmit audio without using the laptop's physical microphone or speakers.

3. How I Run mpv

Our initial working command was:

PULSE_SINK=dj_murloc mpv --no-video --ao=pulse http://127.0.0.1:8000

We later detached mpv from the terminal using nohup.

Finally, we created a runit service script to supervise the player:

#!/bin/sh

export XDG_RUNTIME_DIR=/run/user/1000
export PULSE_SERVER=unix:/run/user/1000/pulse/native
export PULSE_SINK=dj_murloc

exec /usr/bin/mpv \
  --no-video \
  --ao=pulse \
  --really-quiet \
  http://127.0.0.1:8000

We successfully verified that runit and mpv were running together.

However, persistent startup after a complete system reboot and long-term recovery behavior still need further testing.

4. Mistakes I Made

Mistake 1: Running mpv from an SSH session

At first, I launched mpv directly from my Windows PowerShell connection to the Linux laptop.

When I closed the terminal, the audio transmission stopped.

I initially thought the problem was with the music server.

I eventually learned that a long-running audio process should not depend on an interactive terminal.

We first used nohup and later runit.

Lesson learned: Proper process management is essential when building an unattended system.

Mistake 2: Assuming every audio interruption was an MPD problem

On several occasions, MPD continued playing music, but Discord received no audio.

After checking the playback chain step by step, we found that mpv was no longer running.

Starting mpv again restored the audio.

Lesson learned: Each component of an audio pipeline must be checked independently.

We did not capture enough diagnostic information to determine why mpv terminated, so I am not reporting this as a confirmed mpv bug.

Mistake 3: Not implementing supervision from the beginning

Since my goal was continuous operation, I should have considered process supervision earlier.

I eventually configured runit to restart mpv if its process exits.

This improved our setup, although it still requires more testing.

Lesson learned: Reliability should be part of the initial system design, rather than something added only after failures occur.

Mistake 4: Confusing the browser connection with the audio player

We later experienced another interruption where mpv remained active and MPD continued playing, but the Discord account had left the voice channel.

Manually reconnecting Discord restored the transmission.

This helped me understand that mpv and Discord Web are independent components with different failure modes.

Lesson learned: A running audio player does not guarantee that an external communication service remains connected.

This was not an mpv issue.

5. What Worked Well

I particularly appreciate that mpv:

• Can receive an HTTP audio stream directly.
• Can operate without a graphical video window.
• Supports PulseAudio-compatible output routing.
• Can be integrated into Linux scripts and service supervision.
• Works on relatively modest hardware.

For my small project, these capabilities were exactly what I needed.

The virtual audio output was adjusted based on listening tests, eventually reaching 35% in our configuration.

This adjustment was made through PipeWire, independently of mpv's playback controls.

6. Constructive Feedback

From the perspective of a beginner, I would find additional practical examples useful for:

• Running mpv continuously as a supervised audio-only service.
• Handling temporary HTTP stream interruptions.
• Recovering audio playback after network failures.
• Troubleshooting PulseAudio/PipeWire routing.
• Diagnosing unexpected process termination.
• Deploying mpv on lightweight Linux systems.

These are suggestions for documentation and beginner-oriented examples, not claims of missing functionality or software defects.

7. What I Still Need to Improve

My next goals are:

• Testing recovery after deliberate mpv termination.
• Verifying service startup after reboot.
• Recording useful logs when playback stops.
• Improving handling of temporary streaming interruptions.
• Monitoring CPU and memory consumption.
• Improving the independent Discord voice connection.

I want to document these improvements as part of my learning process.

8. Final Thoughts and Appreciation

This project has taught me much more than I expected.

I started by wanting a simple music station for a few friends. Along the way, I learned about Linux process management, HTTP audio streaming, virtual audio devices, remote administration and troubleshooting.

mpv has been a valuable part of making that possible.

I also learned that when something stops working, it is important not to assume that the software itself is defective. In many cases, my configuration choices or lack of experience were the real challenges.

Thank you for developing and maintaining mpv and for making it available to the community.

I appreciate the opportunity to learn from your work, and I hope this experience may be useful to another beginner attempting a similar setup.

Best regards,

DJ Murloc / Radio EAF
Norway

*An independent personal learning project using mp

[llyyr]

this is the mpv discussion page, not mpd

[VardoDalgurak]

You're absolutely right! My apologies for posting this in the wrong repository. I confused the MPD and mpv discussion pages.

Thank you for pointing it out, and thank you to the mpv developers as well. Your software is also an important part of my project.

I'll move the MPD-specific feedback to the appropriate community.

Sorry for the confusion!

[CounterPillow]

Stop spamming us with LLM output

[ion1]

MPD → HTTP MP3 stream → mpv → PipeWire virtual sink → Virtual microphone → Discord Web.

For your consideration: MPD → HTTP Opus stream → Discord bot on a voice channel.