Make vlc more resilent with unreliable streaming content

Bug #790216 reported by Teo on 2011-05-30
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
VLC media player
Invalid
Undecided
Unassigned
vlc (Ubuntu)
Wishlist
Unassigned

Bug Description

Binary package hint: vlc

Steps to reproduce:

1. Go to File/Open network stream
2. Write or paste the address of a network stream, for example http://mediapolis.rai.it/relinker/relinkerServlet.htm?cont=7pPpPlussPYNFVvokgeeqqEEqual
3. Hit the play button, watch and wait.

At random times (it may be after several minutes), the stream stops playing and closes. The video display area disappears (i.e. VideoLan only shows playback control and the window is resized) and the playhead goes back to the beginning and stops showing current time and total time.
Everything is as if you had hit the stop button.

It doesn't matter whether it is the server actually closing the connection, or if the server stops responding, or if the network connection is failing or none of these. The client MUST be 100% bulletproof to all kinds of error conditions, and if anything fails, it MUST retry and retry and resume normal playback as soon as possible.

If you can manually resume the playback (which is ALWAYS the case, by manually hitting play again and manually seeking the point where playbak has stopped), then the player should do all this automatically.

A stream is by definition something that should never stop playing until it is finished. Any temporary network issue should cause only temporary stream interruption, never a stop without a resume. Playback should ALWAYS resume when possible.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: vlc 1.0.6-1ubuntu1.6
ProcVersionSignature: Ubuntu 2.6.32-31.61-generic 2.6.32.32+drm33.14
Uname: Linux 2.6.32-31-generic i686
NonfreeKernelModules: nvidia
Architecture: i386
Date: Mon May 30 15:10:11 2011
InstallationMedia: Ubuntu 10.04 LTS "Lucid Lynx" - Release i386 (20100429)
ProcEnviron:
 PATH=(custom, no user)
 LANG=en_US.utf8
 SHELL=/bin/bash
SourcePackage: vlc

Teo (teo1978) wrote :
Rémi Denis-Courmont (rdenis) wrote :

Actual behaviour is expected and suggested behaviour is invalid.

Changed in vlc (Ubuntu):
status: New → Invalid
Teo (teo1978) wrote :

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?

Changed in vlc (Ubuntu):
status: Invalid → New
Rémi Denis-Courmont (rdenis) wrote :

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.

Changed in vlc (Ubuntu):
status: New → Invalid
Teo (teo1978) wrote :

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.

Teo (teo1978) on 2011-06-05
Changed in vlc (Ubuntu):
status: Invalid → New
Teo (teo1978) wrote :

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.

Rémi Denis-Courmont (rdenis) wrote :

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.

Changed in vlc (Ubuntu):
status: New → Incomplete
status: Incomplete → Invalid
Teo (teo1978) wrote :

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

Changed in vlc (Ubuntu):
status: Invalid → New
Benjamin Drung (bdrung) wrote :

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.

Changed in vlc (Ubuntu):
status: New → Incomplete
Teo (teo1978) wrote :

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?

Rémi Denis-Courmont (rdenis) wrote :

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

Teo (teo1978) wrote :

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

Changed in vlc:
importance: Unknown → Undecided
status: Unknown → New
status: New → Invalid
Changed in vlc (Ubuntu):
status: Incomplete → Invalid
michael kennedy (mikewkennedy) wrote :

"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.

Teo (teo1978) wrote :

@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.

Changed in vlc (Ubuntu):
status: Invalid → Incomplete
status: Incomplete → Confirmed
Rémi Denis-Courmont (rdenis) wrote :

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

Changed in vlc (Ubuntu):
status: Confirmed → Invalid
Teo (teo1978) wrote :

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.

Changed in vlc (Ubuntu):
status: Invalid → Confirmed
Rémi Denis-Courmont (rdenis) wrote :

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

Changed in vlc (Ubuntu):
status: Confirmed → Invalid
Teo (teo1978) wrote :

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.

Teo (teo1978) wrote :

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

Changed in vlc (Ubuntu):
status: Invalid → Confirmed
Rémi Denis-Courmont (rdenis) wrote :

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

Synching with upstream status.

Changed in vlc (Ubuntu):
status: Confirmed → Invalid
Teo (teo1978) wrote :

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)

Changed in vlc (Ubuntu):
status: Invalid → Confirmed
Reinhard Tartler (siretart) wrote :

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.

summary: - network stream randomly stops playing
+ Make vlc more resilent with unreliable streaming content
Changed in vlc (Ubuntu):
importance: Undecided → Wishlist
Teo (teo1978) wrote :

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

BabyCakes (babycakes) wrote :

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.

Dimitri Pappas (fragtion) wrote :

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

Kevin Fiebig (d-ubuntu-3) wrote :

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.

Kevin Fiebig (d-ubuntu-3) wrote :

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.

cto322 (to314xl) wrote :

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.

Richard (ismail-a) wrote :

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

RonCam (rac2) wrote :

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.

RonCam (rac2) wrote :

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?

Risharde (risharde) wrote :

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.

Anders Kaseorg (andersk) wrote :

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

ubnt ubnt (ubntubnt34234) wrote :

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

Alexander Adam (7ql6) wrote :

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?

Jan Schulze (g-jan-8) wrote :

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?

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.