Make vlc more resilent with unreliable streaming content

Actual behaviour is expected and suggested behaviour is invalid.

Could you explain why you would expect a player to stop playing at the smallest interruption of stream availability and why you think it's ok that the user have to manually restart playing and, what's even worse, manually seek for the point at which it was interrupted every time it stops playing?

VLC does not stop at the slightest interruption. If there is transient packet loss, playback will be paused when the input buffers underflow, until the buffers refill to a reasonable level. This is a bit annoying, but it is unavoidable.

Otherwise, if the connection fails, then VLC gives up. This is the most basic network resiliency feature. When the server or the network is overloaded, the *last* thing to do is immediately retry. It would only make the problem worse. Web browsers, email agent, newsgroups agents, aggregators... don't reconnect automatically either. They just wait for the user to explicitly retry (or a fixed timer in some cases).

Admittedly, there is a small problem in VLC: it often silently stops in case of network failure, instead of printing an obnoxious modal error dialog. That is not a big deal though.

Well, at the very least then, it should remember the playhead position, so that you could resume by just hitting play. Right now, you can't heven know at which point it stopped (unless you were looking at the time counter just before it disappeared). That _is_ a pretty big deal.

> When the server or the network is overloaded, the *last* thing to do is immediately retry.

Well it could retry after a given (and settable) time interval and for a maximum given (and settable) number of times.

> Web browsers, email agent, newsgroups agents, aggregators... don't reconnect automatically either

FTP clients and download managers do, however.
Web browsers and email clients are programs that require continous user interaction (i.e. browsing) anyway, so it's ok if you occasionally need one more click in the case of a failure. A stream is something you usually leave playing while you are not in front of the computer with your hand on the mouse and keyboard, just like an FTP client or a download manager is something you usually leave downloading while you are away, More robustness is required in these cases, of course without unreasonably flooding the network with requests.

Anyway, these random stops happen so often that I wonder whether these are real network/server failures or if there's something wrong on the client side. May you suggest a way to dump (relevant) network traffic so that I could dig into the issue?

thanks
m.

I'm reopening this because it definitely needs to be fixed, though maybe the subject could be changed to something more precise and maybe this could be split into two separate issues:

1. When a stream stops playing because of an error, the playhead forgets its position.

2. Playback is not reliable in that at the first failure it stops. It IS possible to make it reliable WITHOUT hogging the network or flooding the server. It's as easy as retrying after a given time interval (not immediately) and up to a given number of times (not forever). This is not incompatible with network resiliency and this is the most basic network robustness feature, Any program that needs a minimum of reliability does that. I've never seen a Youtube video suddenly stop playing.

I have no problem playing the specified video (10 and a half minutes without a hitch).

If you think there is a bugin VLC, please provide a patch. As far as I am concerned, this issue is closed.

Well the specified video is just an example and it doesn't always fail. Sometimes you can play a stream for an hour witjout a glitch, sometimes after just a couple of minutes you observe the issue. Just one 10 minutes test does not prove nothing.

Yes there is a bug in VLC, and I explained what the bug is: that when there is a failure playing the stream, it does not retry to ensure robustness. The fact that you cannot reproduce a failure does not mean that the bug is not there: to say the bug is invalid you should observe that where there _is_ a streaming issue VLC resumes gracefully.

Also, note the doesn't-remember-playhead-position issue, which is very clear and plainly wrong.

I don't understand your closing the bug just because the reporter doesn't provide a patch. I am not a developer. If bugs were to be reported only when someone was able to provide a fix, then bug trackers wouldn't need to exist.

Please close this when you really observe that the issue is invalid, or when it is fixed (or if you find out it is a duplicate or whatever), but closing it because it is _not_ fixed or because you cannot even reproduce the situation where the issue can be observed or not observe, does not make much sense

The correct status for this bug is incomplete, because we do not have all information to debug it. It would be nice to have a test case that always triggers the issue.

I'd like to provide a log file but I can't get logging to work.
I went to Preferences/Advanced/Logging and I set a log file called "vlc.log" in my home folder but it hasn't even created the file.
What am I missing? What more do I have to do to enable logging?

As far as upstream is concerned this is invalid. Best of luck if you want to fork the HTTP and MMS inputs in Ubuntu....

Yeah unfortunately it looks like the upstream developers don't see this as an issue, and the explanation they give about it is "plonk".

https://trac.videolan.org/vlc/ticket/4774

"Actual behaviour is expected and suggested behaviour is invalid" this is a classic case of "functions as designed" when the problem is that it was designed poorly.

I have been streaming video from a gopro camera with it's own wifi network to VLC and then rebroadcasting my screen over google hangouts - see this: http://www.youtube.com/watch?v=I9Q5Y6iiNgE&src_vid=4g2WhBRc7vo&feature=iv&annotation_id=annotation_231482

So, developers, here is a new use case for you. Because of this "plonk" I can't accomplish my goal of livestreaming from my gopro!

I just wish it would keep streaming or at least try and re-connect to the stream. I am often not at the same place as my camera when this happens, and I am unable to hit the play button to restart the stream....

And I thought I would comment because I found your comment so laughable. Engineers! thinking inside the box since the box was unboxed.

@mikewkennedy, why do you generalize rdeni's reasoning as if it was typical of engineers? I am an engineer too, and the poor design behind this bug and especially the absurd arguments behind the decision not to fix it, seems to me an example of _bad_ engineering.

I find this insulting. But surely you know better than the main VLC developer (a.k.a. myself). Not.

If you don't want to fix it, then close it on your own bugtracker ("won't fix" would be the proper status but I guess you'll insist in calling it "invalid", do whatever you want on your own bugtracker), but leave it open here (where it has been confirmed by other users) just in case some other developer with a little of common sense may some day want to fork the project and fix it.

It is a basic rule of network engineering not to automatically reconnect since it typically will fail if not aggravate network congestion. Period.

I can't believe I'm reading something that stupid.

The basic rule of network engineering is not to automatically reconnect IMMEDIATELY and indefinitely.
But an equally basic trick of network engineering is to *do* automatically reconnect AFTER A SMALL TIME (e.g. a few seconds) and up to a LIMITED NUMBER OF TIMES.

FTP clients do that, email clients often do that, most any-kind-of-network-software clients do that, and it is especially vital for a video streaming client.

But surely you know better than anybody in the world, because you are the main VLC developer.

I am not here to be insulted. And you are contradicting the initial bug report here, oops.

Synching with upstream status.

Contraddicting?!?! Oh well, just because in the OR I said "100%" and "as soon as possible"? For god's sake.

Nobody here has inulted you, unless questioning that everything you say or do is right is an insult.

You are not here to dictate the closing of bugs opened by the community, either. Do whatever you want in your own bugtracker, but you should leave this open in case some other developer is willing to fix it and provide a patch, which by the way you said (or seemed to imply) would be welcome (#7)

I've updated the bug to what I got from this "discussion". Frankly, I do not think that with this bug history, anyone is going to work on this soon.

I'd say "unreliable network conditions" rather than "unreliable streaming content".

Teo, thank you for your persistence. (Bug #790216, Make vlc more resilent with unreliable streaming content) This is a problem and continues to be a problem on connections that chronically drop.

Wow. Excuse me for butting in but I cannot for the life of me comprehend the retardation in calling this report "Invalid"? VLC has major problems in this regard. If it's not the GUI spamming error messages as it tries to play next item in playlist when a stream fails (because it doesn't know how to wait a second or two before retrying - you have to click 'dont show me errors' to have some sanity restored), then it is the client's dismal handling of failures. In dummy mode, if a stream disconnects, the VLC process may continue to run indefinitely 'timed-out' state. If the process could die, I could use a script to re-start it, but it doesn't die. Sometimes it doesn't even show an error? This is not an Invalid report. Such classification can only rationally amount to arrogant developer denial. Which is unfortunate, because VLC remains a great tool with much more potential. But first this Quirky Shit needs to be Acknowledged. Then it needs to be fixed. Can we get past the Acknowledgement state, please ? We've been annoyed by this 'unexpected' behaviour for years already

Bug still exist. Another case that is able to reproduced.

I have FOUR different galaxy S3 android phones that I run the program "IP Webcam" on. For information's sake this is also reproduced easily with my one actual IPcam(Foscam Fi8918wb).

If they are close enough to get full wifi signals I have no issue at all keeping their streams open in VLC to record. If they are are (mounted) where the signal is low (1-2 bars, around -70db). The devices maintain connection. But the streams freeze constantly. Within 10 minutes of starting. I can switch out phones and locations and it remains the same. Low connectivity, but no disconnects = inability to stream.

While using VLC would be wonderful as it allows me more freedom to what I wish with the streams, right now I'm having to use less robust software that knows how to keep a stream connected.

Logs show nothing.

proofreading... to add to the above. When I say 'freeze' I mean the streams just stop completely. Stream has to be restarted. Like above cases.

There is a related problem that can be easily tested.
For french user, when I use VLC to watch a TV stream (freebox) on my bad connection,
quite often (for example when I browse a heavy web page) the video and sound stream will almost freeze : video gets blur and sound stops. Either the stream will completely stops or after a while (e.g. when the web page is fully loaded) image will be back but the sound stream will never recover. I have two solutions: stop the stream and reload or reload the video stream (by choosing Audio tracks -> disable then enable it again).

Before making VLC fully resilient against stream problem it may be interesting at first to make it resilient to sound stream loss by detecting that the sound stream is lost/empty.

A get-around for streaming audio is to use mplayer from the command line.

mplayer is somewhat resilient but can be placed in a bash loop and using tmux there is remote ssh access from anywhere, too.
A restart is necessary if your public ip periodically change or on laptop resume.

while true; do mplayer http://stream.techno.fm/techno.256k.mp3; sleep 5; done

Richard deserves another karma point for a work-around for a VLC-bug/and or/robustness problem that has been otherwise resolved since this thread was started, in 2011. In this case, it pays to read to the very end ...

His script does work quite well, and at last I'm able stream with minimal interruption and, when necessary, recovery.

When Richard's script goes into action, I see this explanation of the problem, in terminal:
  Cache empty, consider increasing -cache and/or -cache-min. [performance issue]

I'm intending to search for a VLC plugin that detects this condition and then duplicates the script's action.

I now have VLC playing streaming radio with very good stability, for hours, whereas before there were interruptions every 20-30 minutes.

First, drag the desired stream from the Media Library into the PlayList, and turn-on (click repeatedly as needed, to select) 'Loop One'. Avoid playing streams while they are inside the Media Library, even though it seems to work.

Second, in Media -> Open Network Stream -> Show More Options -> Caching, increase the value to something greater than its default, which is 1000ms. The configuration range goes as high as 60000ms, just to give some idea of the available scale.

Start the stream normally, by double-clicking it (in the PlayList) or use Start icon in lower-left corner.

I'm seeing good stability beginning at 7500ms, but it's possible this may depend upon the quality of each individual stream.

Both setting 'one loop' to 'on' and setting the cache may be done most easily by editing the parameters in whatever your distro/desktop environment uses as a program launcher.

The parameters take this form:
 --loop --network-caching=5000
and, the latter would set the cache for five seconds. There is one space preceding the two hyphens.

The only disadvantage is that if you're searching the streams for audio content, there will now be a slight delay before the audio begins to play. At the default value of 1sec, this delay is almost imperceptible, but expect this to change as the caching time increases.

So, maybe not a 'bug' at all? Are others having success with this?

6 years later and VLC has not improved regarding this issue
What gets me is Remi's comment

"VLC does not stop at the slightest interruption. If there is transient packet loss, playback will be paused when the input buffers underflow, until the buffers refill to a reasonable level. This is a bit annoying, but it is unavoidable."

The feed literally "stops" which implies the disconnection of feed which is what we want to avoid... VLC shouldn't make that decision, that decision should be based on the actual connection state.

So why not make an option for people decide how long they'd like VLC would wait? Streaming or restreaming an unstable feed causes VLC to stop and reconnect causing issues with synchronization of the streaming feed in many cases.

There’s an --http-reconnect option that seems to address this problem. (Why is it disabled by default?)

wrong, this is not fixed and --http-reconnect does not reconnect a RTSP stream that drops or otherwise stops wo user action.

Instead of fighting everyone the engineers should just accept that the original design was partially off, and add the feature as an option. (just like http-reconnect, add an rtsp-reconnect option). if you think its proper network etiquette to have this off, then have it off by default. but give you users the option of enabling it when needed. You really think all the replies here are from people who are trying to maliciously hammer servers? logically it doesnt make sense for something to interrupt/halt a medium like video but for when a user's action stops that video. so ADD RTSP-RECONNECT please. tks

Does anyone knows a player that is able to handle this (without having to use hacks like these: https://raspberrypi.stackexchange.com/questions/40637/restart-mplayer-stream-process-on-loss-of-internet-connection)?

Or is there any VLC plugin that can do this?

TL;DR: Try ffplay. The standard player in the FFMPEG package.

We have had the same problem with monitoring surveillance steam of sub-par cameras. After waiting for about a year I am trying it again, right now, using the latest snap version. At this very moment of typing, I am looking at two different windows. One is a stream displayed in vlc, the other in ffplay. Same source, which still is a crappy stream of a crappy camera.

For those of you interested: I started the stream without any special voodoo. Just "vlc 'rtsp://URL'" repectively "ffplay rtsp://URL".

Result: The VLC window is frozen almost permanently. It updates between every 15 seconds and once every other minute. ffplay produces a constantly moving picture. It's not great, bco of the low quality of the crappy stream, but I can see what happens in front of the camera.

So, what am I supposed to think now? Is FFMPEG the superior product for my use case?

It is still an issue in 2021, with VLC (tested on an old Raspberry Pi):

VLC media player 3.0.16 Vetinari (revision 1.0.6-1682-g88158c836)
VLC version 3.0.16 Vetinari (1.0.6-1682-g88158c836)
Compiled by pi on serge-testpi (Nov 10 2021 15:40:45)
Compiler: gcc version 10.2.1 20210110 (Raspbian 10.2.1-6+rpi1)

To summarize the current status:

- VLC will stop playing if the network stream is disrupted. This is painful in headless operation, because you can not detect it. If queried via the remote control socket, "is_playing" command returns '1', but no reconnecting happens ever.

- VLC developer Rémi Denis-Courmont (rdenis) 's is aware of this situstion and his statement is that this is a feature and will not be changed.

- Alternatives can/should be used if you plan to use a media player as a daemon/background service

My 2 cents on the topics: it is a nice idea to protect the internet infrastucture by default. But doing it by sacrifying resiliency, and without an option to change the behaviour, is suboptimal.

But this is how free software goes: without guarantee to fitness for any purpose... And sometimes it is true for paid software, too.

Anyway, I'd like to thank the VLC developers work put in the project so far !

Same issue on Windows. It would be nice to have an auto reconnect option. We don't care if it's going to "overload the server with requests". That should be our choice. I use it for my home security cameras and they frequently lose connection. I set up a playlist on autoloop but it's opening the playlist instead of just trying again as expected.

It would be nice to have a setting that lets the system auto retry every x seconds, indefinitely, so whenever the feed is back on, we get the feed alive again. I like to monitor my camera using VLC and it's nice to just have it playing without having to go to the computer to restart the feed.

I don't care about protecting the internet infrastructure, I just want to have this working. You can limit the feature to local feeds if you're so concerned with network politeness. Or limit the retrials to not happen more than once every 20 seconds or something like that.

Any server has protection against excessive requests, so even if it is an internet server it will just lock us out if we "abuse".