Reconnect if disconnected on network stream. #5793
Comments
|
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 |
shinctl
changed the title
|
@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. |
|
Network timeout option does not cover some errors, sadly :( |
|
There's already reconnection code. You're providing too little information to do anything. This should just be closed. |
|
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. |
|
ATM mpv uses the "reconnect 1" option from ffmpeg right? -reconnect 1 -reconnect_at_eof 1 -reconnect_streamed 1 |
|
I'm curious if these options solved the disconnect issue for you? |
|
Nope... I just gave up and used another player. |
|
Oh ok.. Which one if I may ask? |
|
@shinctl which other player? |
|
The
Granted, in the beggining, I've only found out about these sort of capabilities of So yeah, search this issue tracker more. |
|
Still not clear what this issue is even about. Not a single log, not even a description of ma use case. Closing. |
ghost
closed this as
|
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? |
|
Is that just a mp3/ogg stream (typical web radio)? |
|
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? |
|
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 |
|
There's also |
Until now, we've made FFmpeg use the default network timeout - which is apparently infinite. I don't know if this was changed at some point, although it seems likely, as I was sure there was a more useful default. For most use cases, a smaller timeout is more useful (for example recording something in the background), so force a timeout of 1 minute. See: #5793
|
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 I don't know if HLS is affected by these changes. |
|
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! |
It sometimes happens that HLS streams freeze because the HTTP server is not responding for a fragment (or something similar, the exact circumstances are unknown). The --timeout option didn't affect this, because it's never set on HLS recursive connections (these download the fragments, while the main connection likely nothing and just wastes a TCP socket). Apply an elaborate hack on top of an existing elaborate hack to somehow get these options set. Of course this could still break easily, but hey, it's ffmpeg, it can't not try to fuck you over. I'm so fucking sick of ffmpeg's API bullshit, especially wrt. HLS. Of course the change is sort of pointless. For HLS, GET requests should just aggressively retried (because they're not "streamed", they're just actual files on a CDN), while normal HTTP connections should probably not be made this fragile (they could be streamed, i.e. they are backed by some sort of real time encoder, and block if there is no data yet). The 1 minute default timeout is too high to save playback if this happens with HLS. Vaguely related to #5793.
|
Here's an issue I've been having: 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. |
|
I encounter the same problem. Here's the output: During the daytime this error has not occurred, but as evening draws on then it occurs several times per hour, presumably as the server gets more loaded. This is easy to reproduce so if you'd like more logs just let me know what command line options to add. (I realise this issue is closed, but the problem persists. If you would prefer that I post on another issue, then just let me know which. This seemed the most relevant.) |
|
You can try the options suggested in #8779 (comment) |
|
@guidocella : sorry for delay, I wanted to test the suggestions propertly and that took a few days It worked very well for http://live.slovakradio.sk:8000/FM_128.mp3. Thanks very much! But the BBC still drops out with exactly the same symptoms: This takes between 5-30 minutes to exit, but the behaviour isn't time-of-day sensitive. |
|
This issue is really bothersome ... I wish MPV would automatically reconnect to my security camera's RTSP streams, when they hang. I have to exit and start a new MPV process, and then resize the window again. Please fix the player so that it automatically reconnects. |
|
Please fix the player so that it automatically reconnects.
perhaps '--loop-playlist=force' helps you.
Alexis
|
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.
The text was updated successfully, but these errors were encountered: