plugins.twitch: fix date offset of prefetch ads #4942
Conversation
|
I've been trying the whole day getting a mid-roll ad where the stream doesn't resume after the filtering. I had this issue for a second time yesterday when I quickly tested something in Streamlink Twitch GUI, so I once again didn't capture any logs. The only settings that are different on my system when running from the Twitch GUI compared to running Streamlink from the command line shell is the live-edge value and other unrelated things, so I've been checking with these different parameters for the past couple of hours, but no success so far. I also haven't received much feedback so far, only people waiting for a merge and comments from people where it's very likely that they made a mistake while trying to help. This will only be merged if there's enough confidence, so feedback is required in terms of actual real-world tests with a trace log and the patch applied for logging the HLS playlist contents. This can't be properly implemented/fixed without the right data, and I don't have all the data needed for that. |
|
@bastimeyer It might be worth adding a new comment over on #4934 that is essentially a copy paste of your other comment with the install instructions for this branch to try and boost the signal. I can't even duplicate the issue on the latest stable release (but I also only watch some Twitch in the evenings so the number of mid-rolls I've run in to is low) and this branch has the same behavior for me so I'm not confident saying whether it works one way or the other, we need more people testing and providing feedback. |
|
I was already thinking about that. I won't be having much time this evening for further debugging adventures, so hopefully someone else can provide some data. |
|
I have installed latest streamlink twitch gui via win64 installer. How can I test this PR? just replacing twitch.py in plugins folder? |
|
Updated installation instructions for this PR have been posted here: #4934 (comment) |
|
@eldepor This is not meant to be run from the Twitch GUI. This is meant for providing a trace log. |
|
file fix.log.gz |
|
Well, thanks for checking, but once again, this is not what I'm looking for and been asking for, same as #4934 (comment) I am looking for cases, where it doesn't resume. Streamlink is resuming the output after ad breaks according to your log, so everything is working as intended. Just in case this isn't clear, if your player is having issues due to the paused output and the resumed content with different timestamps afterwards, then this is not an issue of Streamlink. I'll merge this PR later today in the evening, because I haven't encountered a mid-roll again where Streamlink didn't resume its output afterwards. It's too rare and having the main issue fixed first is more important. |
There's something I don't understand. I installed streamlink twitch gui win64 a month ago, been watching several streams with VLC and -twitch-disable-ads disabled/unchecked and have never experienced any single pause/ad break or prerroll ad during any of the streams I have been watching for hours. In short, ads literally didn't exist for me. So I checked -twitch-disable-ads option and now that screen is not popping anymore, the stream starts but now I have those pauses (ad-breaks I suppose) during the stream, and sometimes at the begining, that I never had before but that you say it's the intended behavior of the software (the streams resumes after tho, for the moment) So which is really the normal behavior of Streamlink twitch GUI? The first case I described without any stream pause or with them? If it's the second one, then why didn't I have any adbreak/stream pause during a whole month of daily stream watching for hours and now I do have them since last 3/4 days? Thanks. |
|
First off, this is not the Streamlink Twitch GUI repo and Streamlink Twitch GUI is not involved AT ALL when watching streams. It's a browser and launcher for Streamlink. That's all. Please read the README first. Second, this is all intended behavior and I suggest that you read the docs and the stickied meta thread here before commenting. Asking questions here unnecessarily bloats up the thread. Read what I have been posting on several places here over the past days. I won't be doing this for several individuals again, just because they somehow avoid reading the already published statements. Again, you were not seeing any ads, because Twitch didn't embed them. Simple as that. This has changes a couple of days ago when they made changes to their embeddable web player, whose streaming access tokens Streamlink has been using. |
|
Ok sorry. Pls delete my question if you want. Thanks. |
|
I've updated the stickied thread with a bit more information for people who are new and are unaware of the whole situation. |
|
I haven't been able to find any non-resuming mid-roll ad pauses again. This can be fixed later if it's indeed an issue. Going to merge this now, so that at least we have the main issue fixed. Once the next nightly builds have been built and more people have tested the new changes, we can publish a new release. |
Is this planned to be fixed in future patches/releases of Streamlink? Thanks |
|
5.1.0 was released earlier today, which includes all the recent fixes, including this PR. The stickied thread has also been kept up2date the whole time. |
Yes, I have it installed already. I mean this other "freezing during ads" issue (if we can call it issue) of my above post which is still happening due to the twitch embeddable web player changes you mentioned, and that I didn't experience before last month:
|
Seriously.. Is this so hard to grasp? Please... Read this, I can't stress this enough. Ads are now embedded into the stream and Streamlink allows you to filter them out and pause the output. If the output pauses, so will your player's playback and you'll have to wait for the regular stream to continue. Think of commerical breaks on TV channels if this helps you. There is nothing that can be done here. If you want to prevent ads instead of having to filter them out, then all the potential options are listed and explained thoroughly in the linked sticky thread. Locking the thread now. I won't be discussing this with any individual user anymore from now on. This is a waste of my time and nerves. I've been commenting and commenting over the past few days. Just because Twitch didn't embed ads the past couple of months and just because some people might not have had any embedded ads during other times prior to that doesn't mean that embedded ads didn't happen and we didn't have to deal with this here. Follow the old threads if this confuses you. |
Resolves #4934
Resolves #4106
WORK IN PROGRESS
Don't merge yet without strong confirmation that this is indeed working correctly. As mentioned in #4934, one of the mid-rolls I encountered resulted in the filtering not stopping. I don't know why, because I didn't run trace logs at the time. It's possible though that the streamer simply forgot to turn off ads. I'm saying that, because the last 8 mid-rolls or so I had on other channels were properly filtered out and the stream continued fine afterwards, hence why I'm opening this PR now. The added test fails without the modification made to the
TwitchM3U8Parser. The test is derived from data I gathered earlier today.DEBUGGING
Please apply the following diff first when testing this PR/branch and then set
--loglevel=traceand--logfile=/path/to/file.log(remove the file first before running streamlink, because the log gets appended). Knowing the content of the HLS playlist when mid-roll ads occur is important, because there are lots of variations that need to be covered.Btw, the branch of this PR is different from the one I posted in #4934, because I had to refactor stuff.
As explained in #4934, the issue was that when cloning the last regular segment in the playlist for generating a prefetch segment from the provided prefetch URL, timestamps were not updated. Twitch now includes ads in the prefetch data and fortunately, they include proper dateranges which can be used for filtering those prefetch ads. The bad news is that prefetch data only consists of a URL, so the program date time of the cloned prefetch segment needs to be calculated from the program date time of the last segment with its duration added to it. Since there's more than one prefetch segments, this may be an issue, but it will most likely be fine.
In #4106 I've explained that an alternative solution would be strictly caching the prefetch data and not shifting the live-edge of the HLS stream. Then all the metadata of the regular segments would always be available. However, this adds more delay, because the playlist needs to be refreshed during the runtime of the latest segment, which is two seconds.