Mpv: Reconnect if disconnected on network stream.

[shinctl]

Hello guys,

Is there a command line option on MPV to automatically reconnect to a network stream?

Sometimes I get some network hiccups and the file stops playing, but if I just restart, it continues the playback normally.
I've tried with the "loop" option, but I keep getting unable to seek error.

Thanks.

[shinctl]

Current command line (I've tried lots of cache options also)

mpv --cache-pause-initial=yes --cache-pause=no --cache-default=15360 --cache-initial=256 --demuxer-thread=yes --demuxer-readahead-secs=30 --framedrop=vo --sid=1 -cache-secs=30 URL

[dnmTX]

@shinctl i've had the same problem when leaving the player paused for longer time and then went away.It's basically server's fault,if you go trough terminal: mpv --h=network-timeout you'll see that is set to 0.000 aka to never expire.To answer your question i personally couldn't find such a command line assuming that if one is implemented would consume too much resources just to continuously checking if the connection is alive.

[shinctl]

Network timeout option does not cover some errors, sadly :(
A option like VLC's "--http-reconnect" would be awesome.

[ghost]

There's already reconnection code. You're providing too little information to do anything. This should just be closed.

[shinctl]

If there is, how could I use it? I've tried searching all around the manual @mpv.io, but could not find any reconnect/restart option.
About the error I receive sometimes (Yes, I know it's the streams fault), but a reconnect after this error would be nice.
Error: [ffmpeg] NULL: missing picture in access unit

[shinctl]

ATM mpv uses the "reconnect 1" option from ffmpeg right?
These other flags should help also...

-reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1

[porsager]

I'm curious if these options solved the disconnect issue for you?

[shinctl]

Nope... I just gave up and used another player.

[porsager]

Oh ok.. Which one if I may ask?

[rudevdr]

@shinctl which other player?

[garoto]

The input.conf line below is merely using mpv properties and the documented syntax listed on the manual:

CTRL+r write-watch-later-config ; show-text "Reloading file..." ; loadfile "${path}"

Granted, in the beggining, I've only found out about these sort of capabilities of input.conf and other mpv facilities because I lurked a lot on this issue tracker, reading every ticket that had a title even remotely interesing.

So yeah, search this issue tracker more.

[ghost]

Still not clear what this issue is even about. Not a single log, not even a description of ma use case. Closing.

[porsager]

In my case I'm seeing Radio streams just stopping (no audio) without any information. It'll happen after several hours/days playback, and it's very sporadic. I was thinking of setting up a test case that could check for audio activity, and record once it stopped. Then set up multiple players starting some at the same time, and some later to figure out if it's a disconnect from the source causing it, or something for the single player. Either way, it's hard to debug when it occurs with no output, but audio just stops.

I'd be willing to set up test, if you have ideas so we can open the issue again?

[ghost]

Is that just a mp3/ogg stream (typical web radio)?
Does it show "buffering" on the status line when it gets stuck?
This doesn't sound like disconnection, just being stuck, which I've sometimes observed too.

[porsager]

Yeah, In my case a regular mp3 cast link like : http://live-icy.gss.dr.dk/A/A05H.mp3.m3u

It's been a while since I looked in to it, so I honestly can't remember about buffering, but I'd love to look at it again since it's a recurring issue for us that we've just "learned to live with".

I'll try to set up a test with some verbose logging the coming week. Do you have any solution for solving the "stuck" situation you've encountered?

[ghost]

The case I encountered was with HLS, so potentially completely different.

I suspect there's something broken with ffmpeg's network timeout handling.

You can just reopen the stream.

If it's stuck, you may also get some information by dumping the demuxer-cache-state property, or by attaching a debugger and making a back trace on all threads.

[ghost]

There's also --network-timeout. This may or may not do something. Maybe you can test this by temporarily disconnecting the network cable or so.

[ghost]

It turns out FFmpeg does not set a network timeout by default (anymore?), and since mpv explicitly makes FFmpeg use its default by default, mpv didn't have a timeout either.

I've changed this in git master. Now it uses a 60 second timeout. So instead of getting stuck in "Buffering" for a longer time, it should exit after 1 minute. I had to add a workaround for the cursed RTSP issue (it doesn't set a timeout for RTSP).

Regarding reconnecting, this is tricky too. HTTP normally reconnects, but only if the server accepts range requests. This is because for "static" streams, you want to continue where it left off, instead of starting from the start again.

mp3 web radio (aka icy/shoutcast/etc.) will not accept range requests, so mpv won't reconnect by default. You can force this with --stream-lavf-o=reconnect_streamed=1. I'm hesitant to enable this by default, because sometimes media is delivered without support for range requests, which could lead to very irritating behavior, especially with HLS/DASH.

I don't know if HLS is affected by these changes.

[porsager]

Uh, great work wm4 ! I've unfortunately been too bogged down by other tasks this week, but once I get to it I'll set up tests with git master and last release! Very interesting!

[voidzero]

Here's an issue I've been having:

A: 00:00:33 / 00:00:39 (82%) Cache: 6.5s/121KB
[ffmpeg] tls: Error in the pull function.
[ffmpeg/demuxer] aac: Packet corrupt (stream = 0, dts = NOPTS).
A: 00:00:39 / 00:00:39 (98%) Cache: 0.3s/4KB
[ffmpeg/audio] aac: Input buffer exhausted before END element found
Error decoding audio.
A: 00:00:39 / 00:00:39 (98%) Cache: 0.0s


Exiting... (End of file)

I'd like mpv to try everything to reconnect on issues like this one. I listen to a lot of talk radio and interruptions suck. This mainly happens on my mobile (mpv with termux) fairly often, maybe due to wifi, I'm not sure.