Closed Zero3K closed 6 years ago
So still no change with the new version?
You use the Live-atl.Twitch.TV | US East: Atlanta, GA according to https://twitchstatus.com/ . On this side you can also check the server status. Though i doubt it's the servers fault cause your last direct link actually worked for me without problems (running with several other streams a full hour).
You can try following links to test the twitch servers I use (idk how long this links are valid):
Yes, still no change with the new version.
Please test if it also occurs with other livestreaming services like youtube livestreams and https://mixer.com/ .
It occurred when viewing two Youtube Live Streams. The Log is attached.
EDIT: Maybe the connection timeout value is set too low.
Looking at the log, this is not the problem from before.
There are some segment timeouts starting from 1:20 PM to 1:27 PM. But not enough to break connection which is not perfect but ok.
There are two reasons the connection broke. First one is the 404 errors occurring from 4:36 PM on. The server says there are no segments anymore at the URL given in the m3u8 file (the list of segments to load). The other connection breaks at 5:32 PM because the server says it is forbidden to load the m3u8 file anymore (Maybe the live stream ended here?).
So unlike before it's no longer a problem of timeouts (hence changing timeout won't change anything), but a problem to keep downloading the m3u8 files. I will look into that.
Can you check if the problem with twitch connection failing is also caused by failing m3u8 downloads?
The issue with Twitch is still because its timing out frequently. The log is attached.
The tests indicate the timeout problems only occur as bad with twitch.
Some more things to try to find the cause:
Try to play the direct links (the ones you posted before and can be found in StreamBuffRe in the stream information dialog) in a media player like vlc or MPC. Check if the stream plays without lagging.
When you have a portable device with StreamBuffRe on it try using a public wifi and see if it works better there. If so it's most likely your ISP.
Try to use a VPN to get the direct link of another twitch server to check if it only occurs on your default one.
To sum up: You have only problems with twitch and disconnects also occur with other programs like MPC. But streams do work well without lagging and buffering in your browser (streams will not disconnect because the twitch page will automatically try to reload them)?
Conclusion: It is most likely a problem with your ISP or connection to twitch. Both cases are out of scope of StreamBuffRe.
Anyway here are some things to try: You tried a proxy before (see 7 Mar) but disconnects still occur. Maybe you ran into the now fixed problem of StreamBuffRe thus using a proxy now might help. Try running twitch live streams in different browsers or use a browser plugin to change your UserAgent. If it works flawless with some UserAgents/Browsers but not with others, you ISP might check on it. The UserAgent StreamBuffRe uses could be made editable to circumvent this problem. Try using a VPN to completely bypass ISP throttling. In case of free VPNs I'm only aware of either fast but limited VPN services ( like https://hide.me/ ) or unlimited but slow VPN services (https://protonvpn.com).
If twitch streams don't work but everything else does, only two options remain:
There's no way to fix the timing out when another program is using most of the bandwidth? (such as a browser buffering a Youtube video)
There is already a way of handling such cases. Even if the download of a segment fails it is retried several times. But this can't help when a livestream loads to slow, because the segments of a livestream are only available for a short time. So if the download is too slow, the stream will fail at some point eventually.
Hence this doesn't help with your problem.
I don't think its loading too slow.
When streams also lag in the browser, segments are loaded to slow. This is a problem with your connection to the service (looks like twitch only, for whatever reason) and can not be handled by StreamBuffRe.
Its not only Twitch. Its also occurring with Streamate/Cammodels.
If several programs have a problem with lagging/buffering, it is a connection problem which can't be handled by StreamBuffRe.
Well, sometimes the stream just ends up freezing with no message about the stream disconnecting being shown.
If the bar under the playlistentry stays gray (instead of getting red) and no new segments are loaded (can be checked via "show info"), this is the same error as in #31 and should be fixed with the next release. I hope to release the new version soon and invest some more time in StreamBuffRe again.
Do any streams that you are viewing via it get disconnected/freeze when viewing a 10+ minute video on hooktube.com (which is a front-end for Youtube)?
Please open a new issue for this and answer the following questions there:
I don't use hooktube but i had no problem on a random test video. For StreamBuffRe it makes no difference if you use hooktube or youtube (at least if you only use 720p and nothing above), it downloads and plays a simple mp4 file.
I mean, viewing a video via hooktube.com in a web browser while a stream/streams are playing via StreamBuffRe.
As I said before, I don't use hooktube, hence I don't know about any problems. Either the problem is your connection or hooktube itself. Anyways it is not a problem of or created by StreamBuffRe.
Okay. How about you try downloading a test file from https://speed.hetzner.de/ while viewing a couple of twitch streams via StreamBuffRe and see if the streams disconnect or not?
Due to the bandwidth limit of an internet connection more parallel downloads will slow each other down. Hence if you download something while watching a livestream the segments of the live stream will be downloaded slower. Once the segments are downloaded too slow (half the time they are, for example a 2 second segment times out after 4 seconds of downloading), the download will hit a timeout and fail. If a segment download fails three times (for example because of the timeout) the livestream will disconnect. The reason for the timeout is that many live streaming sites only provide the segments for a short time. Hence they can't be downloaded after the timeout anyways.
So this is a connection problem. My test connection (around 50 Mb/s download) allowed me to play several livestreams while downloading the 1 GB file from your link. Previous tests show that more streams together will lead to a disconnect due to insufficient bandwidth.
I still don't understand why they are disconnecting when my bandwidth isn't being maxed out.
From here on I can only repeat myself. It is a general problem with your connection.
I can't really tell what causes the problem. Maybe your connection is not stable enough so that sometimes your bandwidth goes down for a short period (long enough to cause timeouts). This could be tested with a very large download (it has to take an hour or so, long enough for the problem to occur). Short periods of high pings in online games are also indicators for an unstable connection.
Did you test multiple livestreams when using other internet connection (like public Wi-Fi)?
The "video freezing and stream showing as grey in the main window issue" is still occurring in the latest version.
I think it has something to do with the upload speed provided by the ISP being used fully.
A speed test (don't use the one from your ISP for better results) will tell you about low upload speed.
ISPs have many ways to control and throttle the bandwidth of customers. So it could also be that they throttle only certain services (like twitch) or certain kind of traffic (like video streams).
Its not low upload speed, its that its being maxed out by using P2P programs (which means that StreamBuffRe doesn't have enough upload to use for communicating between itself and the media player).
Yep, that could be the reason.
Is there any way to fix it? I think that it should be using the local bandwidth, not the bandwidth provided by the ISP (if possible).
You could try to throttle the upload bandwidth used by the other P2P programs.
When you speak of 'local bandwidth' I assume you refer to the connection from your PC to your router. It is very unlikely that this connection is actually slower than the connection your ISP provides when downloading/uploading stuff from and to other server on the internet. Online video streams and the P2P programs depend on the bandwidth provided by your ISP. Thus StreamBuffRe can’t just use ‘local bandwidth’.
I mean, use the local bandwidth for the communication done between it and the media player.
The communication between StreamBuffRe and its media players happens only on your PC. No external connection or "real" network (like a connection to other devices) is involved. StreamBuffRe can be used completely offline for local media files (just drag and drop them onto the main window to add them to the playlist).
Now its happening even when trying to view one stream.
Whenever you have problems with streams please check if they also occur when using the twitch webpage (ensure you don't use the low latency mode for streams). Also check at least one stream from another service like a youtube livestream to ensure StreamBuffRe causes the problem and neither your connection nor the used services.
Actually, its just stating "closed by user request" even though I didn't close it myself.
That is just the default message that shows up for HLS and MPD streams whenever the download of one of them stops for any reason other than the streamer himself ended the stream. So it shows up if you stop buffering a livestream as well as when the livestream times out.
What actually tells you the cause of the problem are the error messages (like timeouts) before the "closed by user request" message.
Here's the log of when the issue occurs:
5:25:14 PM - OpenStream opening stream:BackgroundGuy02 5:25:14 PM - PlaylistEntry starting creation StreamJob for url: http://www.twitch.tv/backgroundguy02 5:25:14 PM - PlaylistEntry finished creation of StreamJob for url: http://www.twitch.tv/backgroundguy02 5:25:14 PM - StartStreamConsumer started HTTP_StreamProvider with adress: http://localhost:55556/ 5:25:16 PM - MPC_Player Stream opened while player is running with url: http://localhost:55556/ 5:25:16 PM - MPC_Player starting mpc with args: "http://localhost:55556/" /slave 1707244 /new /webport 9876 5:25:17 PM - MainController HLS Stream 'BackgroundGuy02' closed by user request - 5:25:17 PM - SegmentDownloadQueue`1 disposed DownloadQueue for: BackgroundGuy02 5:25:17 PM - HLS_StreamProvider Disposed 5:25:17 PM - RemoteMPC Player closed - poll closed 5:25:17 PM - RemoteMPC Player closed - poll closed
Since there are no timeouts and the HLS_StreamProvider is closed directly, I don't think it is a problem with network. Please check if the same behavior occurs when using MPV instead of MPC.
The issue doesn't occur with MPV. The log of it starting is as follows:
8:32:37 AM - CommandQueue executing command: ResolveAndPlay 8:32:37 AM - ResolverManager Resolving url: https://www.twitch.tv/twitchplayspokemon 8:32:40 AM - ResolverManager Finished resolving url https://www.twitch.tv/twitchplayspokemon 8:32:40 AM - CommandQueue executing command: AddPlaylistEntries 8:32:40 AM - OpenStream opening stream:TwitchPlaysPokemon 8:32:40 AM - PlaylistEntry starting creation StreamJob for url: https://www.twitch.tv/twitchplayspokemon 8:32:41 AM - PlaylistEntry finished creation of StreamJob for url: https://www.twitch.tv/twitchplayspokemon 8:32:41 AM - StartStreamConsumer started HTTP_StreamProvider with adress: http://localhost:55556/
Ok, I will check out the problem with MPC on the weekend. Please provide the exact version of the MPC you use (version number as well as 32/64 bit) to ease testing.
MPC-HC 1.7.15 (x64)
Although I only found MPC-HC 1.7.13 (x64) as latest version, I found the cause of the problem and will release an update with a fix tomorrow.
Check version 0.6.10.2, it should work again.
It works. Thanks for fixing it.
When I have 3 or more streams open, I lose connection to them over time and I also get "segment is missing" errors. The bandwidth isn't being maxed out when it happens.