Later versions of Vaft have massive issues with endless buffering

[Jules-A]

Previously I was using Adguard Extra with uBlock Origin on Firefox and was only getting endless buffering rather rarely (100% on raids though) but had to look for new solutions since it was causing Youtube to detect an adblocker even when disabling the script on Youtube (not sure how the hell that happens).

This lead me to trying different solutions but with the proxy ones I still got ads and some others interfered with the BetterTTV extension and caused it to break.
Vaft doesn't seem to interfere but would cause endless buffering almost instantly and even after spending 2hrs trying all the different options which didn't help (neither did using as uBO resource).
Then I tried reverting to version 30 (since the buffering logic was majorly reworked) and so far it seems to be working fine for hours with the exception of raids that break it 100% of the time.

I was going to try have the tab reload after raiding to try fixing that issue but I wasn't sure how to detect it (are you able to add that as an option)?

[pixeltris]

Comparing 30/33 there's a change which might potentially be causing the infinite buffering:

TwitchAdSolutions/vaft/vaft.user.js

Line 712 in 5a85380

if (position > 5 &&// changed from >0 to >5 due to issues with prerolls. TODO: Improve this, player could get stuck

Try changing that 5 to 0. Can't see anything else.

I don't watch Twitch enough to realistically help with the raid issue but AI gives a pretty reasonable answer. Question: write me a userscript which reloads the tab when the active channel changes due to a raid by intercepting history.pushState. (referrer=raid in url)

Answer:

// ==UserScript==
// @name         Twitch Raid Tab Reloader
// @namespace    tampermonkey.net
// @version      2025.12.24
// @description  Full tab reload when a raid occurs (?referrer=raid)
// @author       You
// @match        www.twitch.tv*
// @grant        none
// @run-at       document-start
// ==/UserScript==

(function() {
    'use strict';

    /**
     * Wrap the original pushState to detect internal navigation.
     */
    const originalPushState = history.pushState;

    history.pushState = function(state, title, url) {
        // Execute the original pushState navigation
        const result = originalPushState.apply(this, arguments);

        try {
            // Create a URL object to parse parameters from the target URL
            const targetUrl = new URL(url, window.location.origin);

            // Check if the raid parameter is present
            if (targetUrl.searchParams.get('referrer') === 'raid') {
                console.log('[Raid Reloader] Raid detected. Reloading tab...');
                
                // Force a full page reload
                window.location.reload();
            }
        } catch (e) {
            // Fallback for relative or malformed URLs
        }

        return result;
    };
})();

[Jules-A]

if (position > 5 &&// changed from >0 to >5 due to issues with prerolls. TODO: Improve this, player could get stuck
Try changing that 5 to 0. Can't see anything else.

Didn't help.
Also I noticed that some raids worked fine with the revert so it's not 100% chance of failure like newer Adguard Extra or Vaft scripts are.

In regards to the reload, I might try that out but I'd probably want to also check if it's in a buffering state before reloading in case it worked fine. If that's possible obviously.

[pixeltris]

Didn't help.

Well I cant see anything different between 30/33 that would make any difference to buffering. The diff is linked above.

In regards to the reload, I might try that out but I'd probably want to also check if it's in a buffering state before reloading in case it worked fine. If that's possible obviously.

The script has buffering mitigation. It checks if the player is buffering and triggers pause/play when it detects it. If this code functions correctly it fixes the buffering and there's no reason to reload the tab. It would make more sense for you to play around with that code instead:

TwitchAdSolutions/vaft/vaft.user.js

Lines 699 to 756 in 5a85380

	function monitorPlayerBuffering() {
	if (playerForMonitoringBuffering) {
	try {
	const player = playerForMonitoringBuffering.player;
	const state = playerForMonitoringBuffering.state;
	if (!player.core) {
	playerForMonitoringBuffering = null;
	} else if (state.props?.content?.type === 'live' && !player.isPaused() && !player.getHTMLVideoElement()?.ended && playerBufferState.lastFixTime <= Date.now() - PlayerBufferingMinRepeatDelay && !isActivelyStrippingAds) {
	const position = player.core?.state?.position;
	const bufferedPosition = player.core?.state?.bufferedPosition;
	const bufferDuration = player.getBufferDuration();
	//console.log('position:' + position + ' bufferDuration:' + bufferDuration + ' bufferPosition:' + bufferedPosition);
	// NOTE: This could be improved. It currently lets the player fully eat the full buffer before it triggers pause/play
	if (position > 5 &&// changed from >0 to >5 due to issues with prerolls. TODO: Improve this, player could get stuck
	(playerBufferState.position == position || bufferDuration < PlayerBufferingDangerZone) &&
	playerBufferState.bufferedPosition == bufferedPosition &&
	playerBufferState.bufferDuration >= bufferDuration &&
	(position != 0 || bufferedPosition != 0 || bufferDuration != 0)
	) {
	playerBufferState.numSame++;
	if (playerBufferState.numSame == PlayerBufferingSameStateCount) {
	console.log('Attempt to fix buffering position:' + playerBufferState.position + ' bufferedPosition:' + playerBufferState.bufferedPosition + ' bufferDuration:' + playerBufferState.bufferDuration);
	doTwitchPlayerTask(!PlayerBufferingDoPlayerReload, PlayerBufferingDoPlayerReload, false);
	const isPausePlay = !PlayerBufferingDoPlayerReload;
	const isReload = PlayerBufferingDoPlayerReload;
	doTwitchPlayerTask(isPausePlay, isReload);
	playerBufferState.lastFixTime = Date.now();
	}
	} else {
	playerBufferState.numSame = 0;
	}
	playerBufferState.position = position;
	playerBufferState.bufferedPosition = bufferedPosition;
	playerBufferState.bufferDuration = bufferDuration;
	}
	} catch (err) {
	console.error('error when monitoring player for buffering: ' + err);
	playerForMonitoringBuffering = null;
	}
	}
	if (!playerForMonitoringBuffering) {
	const playerAndState = getPlayerAndState();
	if (playerAndState && playerAndState.player && playerAndState.state) {
	playerForMonitoringBuffering = {
	player: playerAndState.player,
	state: playerAndState.state
	};
	}
	}
	const isLive = playerForMonitoringBuffering?.state?.props?.content?.type === 'live';
	if (playerBufferState.isLive && !isLive) {
	updateAdblockBanner({
	hasAds: false
	});
	}
	playerBufferState.isLive = isLive;
	setTimeout(monitorPlayerBuffering, PlayerBufferingDelay);
	}

[Jules-A]

Didn't help.

Well I cant see anything different between 30/33 that would make any difference to buffering. The diff is linked above.

Okay... so... instead of setting to 0, removing that initial position check ends up fixing it.
While I didn't see any infinite buffering, there was some very brief black screens or buffering that lasts up to 5secs on pre-rolls and mid-roll buffing that's around a sec or so and might be possibly improved by changing the config.

About raids, with the old version of the script, I actually haven't noticed any issues with infinite buffering lately. I think the channels it initially occurred on were tabs that weren't reloaded and were running the newer version of the script still.

[pixeltris]

Okay... so... instead of setting to 0, removing that initial position check ends up fixing it.

The initial position check is to avoid it pausing/playing before it starts playing the stream as if it does this it can take longer for there to be any playback and it looks weird to the user as it looks like the player is pausing. That's also why it was increased from 0 to 5.

While I didn't see any infinite buffering, there was some very brief black screens or buffering that lasts up to 5secs on pre-rolls and mid-roll buffing that's around a sec or so and might be possibly improved by changing the config.

Yes there could be some improvements for sure. The 5 secs on preroll could be related to it doing pause/play early as mentioned (there's a console log when it does this). Or it could be related to there being too many network requests when the stream starts. It tries using minimal network requests for a period of time (briefly using just low resolution) but this time might need to be increased:

TwitchAdSolutions/vaft/vaft.user.js

Line 37 in 5a85380

scope.PlayerReloadMinimalRequestsTime = 1500;

Unfortunately I'm personally back to not watching Twitch at all so I'm unlikely to make any further changes. PRs are welcome for anyone who wants to improve the code or make config tweaks that work better.

[Jules-A]

Hmm... I noticed an issue with the older version, when stripping is required which seems very rare, I just get a black screen for the whole duration of the ad.

I tried playing around ways to improve the issues I was seeing and did manage to find some success (by checking for buffering more frequently if the count is > 0), however there appears to be another bug with resolution during ads, it seems to be stuck playing the stream at low res.

[pixeltris]

when stripping is required which seems very rare, I just get a black screen for the whole duration of the ad

Yes when it needs to use stripping it can last for the full duration of the ad. You're at the mercy of the servers providing you with a clean stream.

however there appears to be another bug with resolution during ads, it seems to be stuck playing the stream at low res

If you're talking about the latest version of the script if you increased PlayerReloadMinimalRequestsTime it will use low res only for that entire duration as that's what that setting does (uses 1 specific backup stream, which is currently set to low res). Otherwise it should be able to get higher resolution after PlayerReloadMinimalRequestsTime, would always recommend setting specific quality in the player settings rather than auto quality as it can prefer low res.

[Jules-A]

If you're talking about the latest version of the script if you increased PlayerReloadMinimalRequestsTime it will use low res only for that entire duration as that's what that setting does (uses 1 specific backup stream, which is currently set to low res). Otherwise it should be able to get higher resolution after PlayerReloadMinimalRequestsTime, would always recommend setting specific quality in the player settings rather than auto quality as it can prefer low res.

Yeah, I was talking about the latest version and it was occurring default options with the position > 5 check removed.
I only had success changing PlayerBufferingDelay, I saw too many other issues changing other values. Well, technically as a diff option:

const bufferDelay = playerBufferState.numSame == 0 ? PlayerBufferingDelay : PlayerBufferingFoundDelay;
setTimeout(monitorPlayerBuffering, bufferDelay);

[djg007]

Still getting buffering on latest Firefox. Before there were times where during some mid-roll ads, a certain portion of the stream would loop and would need a refresh.

[pixeltris]

@djg007 repeating segments is definitely one of the bigger issues as it's difficult to detect https://github.com/pixeltris/TwitchAdSolutions/blob/master/issues.md#freezing--buffering--repeating-segments--audio-desyncs

As mentioned I'm not currently watching Twitch so it's extremely unlikely I'll be fixing this myself. PRs are welcome if you'd like to put in the work to fix this.

One thing that might work is reloading the player or triggering pause/play as it switches the active m3u8. Might need to be done at a delay like 1-2 second after it occurs.

TwitchAdSolutions/vaft/vaft.user.js

Lines 584 to 587 in 5a85380

	if (streamInfo.ActiveBackupPlayerType != backupPlayerType) {
	streamInfo.ActiveBackupPlayerType = backupPlayerType;
	console.log(`Blocking${(streamInfo.IsMidroll ? ' midroll ' : ' ')}ads (${backupPlayerType})`);
	}

After the console log do one of the following:

• postMessage({key: 'ReloadPlayer'});
• postMessage({key: 'PauseResumePlayer'});
• setTimeout(() => postMessage({key: 'ReloadPlayer'}), 1000);
• setTimeout(() => postMessage({key: 'PauseResumePlayer'}), 1000);

Timing might need to be adjusted. Try it out.

Ref #199

[Jules-A]

After the console log do one of the following:

* `postMessage({key: 'ReloadPlayer'});`

* `postMessage({key: 'PauseResumePlayer'});`

* `setTimeout(() => postMessage({key: 'ReloadPlayer'}), 1000);`

* `setTimeout(() => postMessage({key: 'PauseResumePlayer'}), 1000);`

All but postMessage({key: 'PauseResumePlayer'}); just made things worse. There was still about 12 buffers during the midroll but I was able to at least get through them without permanent buffer. It failed on the midroll after that though.
Reload was causing it to keep switching between black screen and the screen which is super broken then got perm buffer anyway.
Maybe if I were set it to reload after a minute it might fix the perm buffer.

EDIT: So far setting it to 60s seems to stop the infinite buffering but I think there should be a better way to detect if the ad was a midroll when it finishes and wait a second after it ends to pauseresume instead of doing it instantly.

[pixeltris]

I think there should be a better way to detect if the ad was a midroll when it finishes and wait a second after it ends to pauseresume instead of doing it instantly.

You could add a delay to it just like the above code. The code for when the ad ends is here:

TwitchAdSolutions/vaft/vaft.user.js

Lines 594 to 611 in 5a85380

	} else if (streamInfo.IsShowingAd) {
	console.log('Finished blocking ads');
	streamInfo.IsShowingAd = false;
	streamInfo.IsStrippingAdSegments = false;
	streamInfo.NumStrippedAdSegments = 0;
	streamInfo.ActiveBackupPlayerType = null;
	if (streamInfo.IsUsingModifiedM3U8 || ReloadPlayerAfterAd) {
	streamInfo.IsUsingModifiedM3U8 = false;
	streamInfo.LastPlayerReload = Date.now();
	postMessage({
	key: 'ReloadPlayer'
	});
	} else {
	postMessage({
	key: 'PauseResumePlayer'
	});
	}
	}

It's currently configured to reload the player when this happens rather than pause/play. But you can change that setting here:

TwitchAdSolutions/vaft/vaft.user.js

Line 36 in 5a85380

scope.ReloadPlayerAfterAd = true;// After the ad finishes do a player reload instead of pause/play

[Jules-A]

You could add a delay to it just like the above code. The code for when the ad ends is here:

I tried that, even tried to only delay it for midrolls but it didn't work.

ReloadPlayerAfterAd

I want to avoid that if possible as it's incredibly frustrating if you are listing to audio from the stream since it can occur very frequently...
Also, the fixbuffer option is 100% broken, even removing that <5 it doesn't log the attempts to fix so it's not even running the part that's supposed to fix it.
EDIT: ReloadPlayerAfterAd doesn't even fix the infinit buffering anyway.