Applet version/Build date

2.2.4 (2026-03-28 17:25:13)

Cinnamon version

Cinnamon 6.6.7

Distribution

Linux Mint 22.3 - Cinnamon 64-bit

Graphics hardware and driver used

No response

Applet name and maintainer

radio@driglu4it @jonath92

What happened?

When the networks interface changes, e.g. from wired to wireless, the applet stops playing and does not recover.

Other information

A quick search revealed the following information:

mpv already sets reconnect=1 and reconnect_delay_max=7 by default, but these only handle cases where the server closes the connection — not a full network interface change (which tears down the TCP connection at the OS level).

To handle a network interface switch, you need to pass additional FFmpeg options via --stream-lavf-o. The relevant FFmpeg HTTP protocol options are:

• reconnect_streamed=1 — allow reconnecting even for non-seekable/live streams
• reconnect_on_network_error=1 — reconnect when a network-level error occurs (requires FFmpeg 4.4+)
• reconnect_delay_max=<seconds> — max delay between reconnect attempts (mpv already sets this to 7)

Command line:

mpv --stream-lavf-o=reconnect_streamed=1 --stream-lavf-o=reconnect_on_network_error=1 https://...

Caveats:

• reconnect_on_network_error is only available in newer FFmpeg versions. If your FFmpeg doesn't support it, mpv will log a warning about an unrecognized option but continue.
• These options only work for HTTP/HTTPS streams. For other protocols (e.g., raw TCP/UDP), reconnection behavior depends on the specific FFmpeg protocol implementation.
• If the reconnect attempts exceed reconnect_delay_max or the stream is still unavailable, mpv will eventually give up and stop. In that case, a shell wrapper that re-launches mpv on exit is a more robust fallback:

while true; do mpv https://your-radio-stream; sleep 5; done