buffering/skipping

[jconti8190]

getting a lot of buffering and skipping with the latest release. i tried running from a few different ways and all turned up the same results

[m0ngr31]

What hardware are you running on? Do you have issues in the browser?

I'm just telling it to pull the highest profile possible. It doesn't automatically negotiate based on internet speed

[jconti8190]

tried it on a firestick and on a pc. the firestick actually did better since it would just skip back. on pc the vlc stream would just stop. and by browser you mean the regular espn site? if so no

[SoSJames]

I'm seeing the same behavior. Channels stutter and occasionally freeze when playing in MPC-HC or VLC. The same streams seem to work fine playing through Jellyfin or Kodi. Original streams are fine through the ESPN+ site on the same hardware. I've also noticed that the behavior seems to show up on demanding streams like the 60fps NHL broadcasts. I'm guessing this has something to do with how ffmpeg repackages the HLS coming from Streamlink. Maybe ffmpeg isn't keeping up with the segments. I'm not sure about how Streamlink handles the stdout to ffmpeg, but perhaps increasing Streamlink's ringbuffer might help?

[m0ngr31]

@SoSJames Thanks for the ring buffer suggestion. I'll change that and we can see if it makes a difference

[BluchipStudio]

@SoSJames Thanks for the ring buffer suggestion. I'll change that and we can see if it makes a difference

can i ask why we are running it through streamlink when ffmpeg can accept the auth header directly along with a chrome useragent to play the streams directly ?

[m0ngr31]

@BluchipStudio I guess I had never considered that. I'll play with that and see what I can do

[BluchipStudio]

@BluchipStudio I guess I had never considered that. I'll play with that and see what I can do

yeh i think i may be a good option to help remove one of the possible failure point of the application is really amazing

also for the ffmpeg commands i currently use

ffmpeg -i $url -c copy -tune zerolatency -f hls -hls_time 2 -hls_segment_type mpegts -hls_segment_filename segment%09d.ts master.m3u8

in other software and its been perfect

[m0ngr31]

I have it working locally with just ffmpeg right now, but I'm not sure how to automatically choose the best quality profile? I'm not sure if ffmpeg will automatically negotiate profile based on internet speed? I'm certainly not an ffmpeg expert

[m0ngr31]

After throttling my connection, it seems as if ffmpeg is just grabbing the 720p30 profile no matter what. On the 2 events I played with (women's NCAA soccer and volleyball), I'm not sure if 720p60 is even available. I might have to wait until tonight to test an NHL game

[m0ngr31]

Okay, I figured out how to tell it what to play. Going to be pushing up an update soon!

[m0ngr31]

New version pushed. Hopefully this will help

[jconti8190]

i lost sound with the new update

[m0ngr31]

Yeah, I can reproduce. I'll have a fix soon

[m0ngr31]

Sound should be fixed now

[jconti8190]

sound working again but unfortunately still getting the buffering. will do more testing this weekend at a different location with faster internet but i dont think that is the issue

[m0ngr31]

What hardware are you running on? Have you tried a lower quality preset?

[SoSJames]

Just to chime in, I've updated to the latest version in the middle of a game last night. I'd say the problem on my end is about 90% better. An observation though. It seemed to me that the streams tended to struggle (during a 720p60 NHL game) beginning just before the cut to commercial, and just coming back. Once the problem starts, closing the player and reopening it makes it disappear until the next break. I can't see the ESPN m3u8, but if I had to guess, they're probably using the HLS X-Discontinuity tag when they stitch in commercials. The current version of FFMPEG chokes on those tags and users report the exact same kind of skipping/freezing mentioned here. There appears to be a patch: https://trac.ffmpeg.org/ticket/5419 , but it's nowhere near hitting the FFMPEG stable channel. If I'm totally off-base, feel free to ignore this note.

[SoSJames]

To chime in again, it looks like someone who had this same-sounding issue created a FFMPEG build with a reclock patch to resolve it. Problem is, I'm not certain which FFMPEG version it's based on. Might be useful for testing purposes, perhaps. The Github project is here: https://github.com/jjustman/ffmpeg-hls-pts-discontinuity-reclock

[m0ngr31]

Did you have the same issue when Streamlink was parsing the stream first? I watched a fair bit of soccer the other day when I was testing this, and never had any hiccups transitioning to commercial breaks, but I can't speak for every event...

And when you say struggle, would the stream crash or did it have some buffering issues?

[SoSJames]

The problem's the same (BTW, Streamlink can't handle X-Discontinuity tags, either). It seemed slightly better with Streamlink out of the loop, but still occurring going into and out of the breaks. What happens is I'll see a little freeze and/or a skip forward in the video by a second or two. Then the commercials come on, sometimes freezing between them. When it comes back from the break, there's almost always a freeze/lag. If I reload the stream at that point, it seems to go away. If not, the player then experiences persistent buffer underruns which cause subsequent freezes. The reason I suspect the X-Discontinuity tag is that when FFMPEG hits one, it will throw multiple errors and retry until they clear up. That few seconds of hiccups brings the processing far closer to real-time, leading to the player problems. My question is, are you seeing geotargeted ads during your soccer streams? If not, those tags wouldn't exist in the relevant M3U8. I don't watch much besides NHL on ESPN+, But I can say that the few times I've opened as soccer match or any other sport, the issue didn't seem evident (although I never leave them running long enough to be sure).

[SoSJames]

Also, to be clear, everything I'm saying is a hunch. I've yet to even verify they're using that tag in the M3U8 at all. Just looks exactly like the behavior I'd expect if they did.

[m0ngr31]

I wasn't seeing geo-targeted ads, and I live in the blackout zone for my team, so I'm not able to watch them on ESPN+ :disappointed: I bet your hunch is correct. I'll mess with patching ffmpeg this weekend and see what I can come up with.

[SoSJames]

I appreciate it, and I hope my guess proves correct. I hate to hassle you after you've written something that's already so useful. Also, you could always add a SmartDNS service or a VPN to your Docker stack so you can avoid those blackouts. I have to do that too because, even though I'm not in my team's blackout zone, I'm square in the middle of 3 overlapping team's zones, so I'd miss half of the NHL season otherwise.

[m0ngr31]

I pushed up a new container last night that includes the patched version of that ffmepg build, along with a few other ffmpeg argument changes. I watched a few periods of the Sharks vs Ducks game and it seemed to work pretty good compared to without the changes.

[SoSJames]

I'll give it a try tonight. Thanks for all the hard work, it's greatly appreciated!

[SoSJames]

Fingers crossed, but I'm a full period into a game tonight without a single lag, freeze, or skip. My player's buffer is stable and showing no signs of the previous underruns. Not sure if it's the FFMPEG build or the argument changes, but I'm optimistic that this issue's resolved. I'll report back when the game concludes.

[SoSJames]

As a follow-up, I've gotten through a whole game without any issues. Smooth playback, no commercial issues, playback buffer full at all times. So, I'd say the changes did the trick. Can anyone else that had the same problems confirm/concur? @jconti8190 ? And once again, many thanks to @m0ngr31 for being so responsive and willing to troubleshoot a problem he himself wasn't even having.

[m0ngr31]

That's great to hear! If I can figure out the token refresh issue and the docker permission issue then we'll be in business

[SoSJames]

I'm not sure what you mean about a token refresh issue, but if you mean the access tokens you're grabbing at the start of a stream time out, I have a thought. This ESPN Kodi plugin: https://github.com/matthuisman/slyguy.addons/tree/master/slyguy.espn handles authentication like your setup does, and must be requesting new tokens because it doesn't have any timeout issues. Maybe there's a hint in its code you could follow?

[m0ngr31]

I saw it once, but haven't been able to reproduce it, but it seems like occasionally it'll fail to update the tokens before they expire. I'll take a look at that code though.

[m0ngr31]

I'm going to close this issue. If there are still some buffering issues I'll re-investigate