Greasy fork 爱吃馍镜像

It works perfectly! Congratulations on this script.

Thank you so much for the kind words! 😄💖

I'm really glad it's working perfectly for you now.
If you spot any issues with YouTube changes or have cool ideas, just let me know - I'll keep it updated! 🚀

Thank you so much for the kind words! 😄💖

I'm really glad it's working perfectly for you now.
If you spot any issues with YouTube changes or have cool ideas, just let me know - I'll keep it updated! 🚀

Hi, the script is still working great, but I've run into a problem. When I expand the video to full screen, there's a slight audio skip, as if the video is reloading. I know it's the script because I've disabled all my extensions and scripts, and the issue persists. I hope there's a solution. Cheers.

Hi! Thanks for your helpful feedback! 🙌

The new v1.5.6 update fixes the fullscreen issue you reported - video blocking no longer triggers incorrectly when entering/exiting fullscreen.

This was resolved by adding a small pause mechanism:

• The fsPause flag
• The fsTimer timeout
• The new pauseBlocking() function

These temporarily suspend both blockAll() and scanAllVideos() during fullscreen transitions, preventing unwanted video reloads or audio skips.

Please update to v1.5.6 and let me know if the issue is now fully resolved for you!

Cheers! 🎉✨

Hi! Thanks for your helpful feedback! 🙌

The new v1.5.6 update fixes the fullscreen issue you reported - video blocking no longer triggers incorrectly when entering/exiting fullscreen.

This was resolved by adding a small pause mechanism:

• The fsPause flag
• The fsTimer timeout
• The new pauseBlocking() function

These temporarily suspend both blockAll() and scanAllVideos() during fullscreen transitions, preventing unwanted video reloads or audio skips.

Please update to v1.5.6 and let me know if the issue is now fully resolved for you!

Cheers! 🎉✨

Hi, I tried the latest version of the script, but it still has the same problem. When using theater mode or full-screen mode, there's a sound skipping, and it's as if the video keeps reloading. Also, if you switch between theater mode and full-screen mode, the player sometimes loses sound or the image completely.

Hi! Thank you so much for testing and reporting back! ❤️

I just released v1.5.7 a few minutes ago, and I personally tested it thoroughly on Vivaldi (my daily browser) with many videos:

• Switching from normal - theater mode - fullscreen - theater - normal - ESC
  → Zero reloads, zero audio skips, zero lost sound on my side, everything stays perfectly smooth.

• The fix works by temporarily pausing all blocking functions (blockAll and scanAllVideos) the moment fullscreenchange is detected (using fsPause + 600ms timer), so the main video is never touched during mode transitions.

If you’re still seeing occasional tiny skips, it’s almost certainly YouTube’s own player re-layout/rendering (they made some changes in early December that cause a very brief frame drop on some systems/GPUs), not the script killing the video anymore.

Please update to v1.5.7 (or force-refresh the script) and try again; it should feel completely stable now. Let me know how it goes on your end; happy to help further if anything still feels off! 🎬✨

Hi! Thank you so much for testing and reporting back! ❤️

I just released v1.5.7 a few minutes ago, and I personally tested it thoroughly on Vivaldi (my daily browser) with many videos:

• Switching from normal - theater mode - fullscreen - theater - normal - ESC
  
  → Zero reloads, zero audio skips, zero lost sound on my side, everything stays perfectly smooth.

• The fix works by temporarily pausing all blocking functions (blockAll and scanAllVideos) the moment fullscreenchange is detected (using fsPause + 600ms timer), so the main video is never touched during mode transitions.

If you’re still seeing occasional tiny skips, it’s almost certainly YouTube’s own player re-layout/rendering (they made some changes in early December that cause a very brief frame drop on some systems/GPUs), not the script killing the video anymore.

Please update to v1.5.7 (or force-refresh the script) and try again; it should feel completely stable now. Let me know how it goes on your end; happy to help further if anything still feels off! 🎬✨

Hi, thanks for your help. I wanted to let you know that the problem persists for me. I also wanted to mention that the last version where full screen worked correctly was 1.5.3. The problem started with version 1.5.4. I tested it in my browsers: Brave + Tampermonkey and Firefox + Scriptcat, and both have the same issue. I hope this information is helpful.

Hi again! Thank you so much for the detailed report ❤️

I just released v1.5.8 and tested it exclusively on Vivaldi (my daily browser) using Tampermonkey, Violentmonkey, and Scriptcat - all three managers at the same time and separately.

After more than 15 rapid switches between normal → theater → fullscreen → ESC and back again, it is now 100 % smooth - no audio skips, no reloads, no lost sound at all.

The final fix in v1.5.8 (compared to 1.5.7) is just these three tiny but critical changes:

1. Extended the fullscreen pause window from 600 ms → 1000 ms
2. Added if (window.fsPause) return; right at the start of scanAllVideos()
3. Exposed the flag with window.fsPause = fsPause

These completely eliminate the race condition that still existed on some Chromium builds (including Brave).

Could you please double-check two quick things on your side?

• In Brave, go to brave://extensions/ and make sure “Allow User Scripts” is turned ON for Tampermonkey/Scriptcat
• After updating to v1.5.8, do a hard refresh on YouTube with Ctrl + Shift + R (or Cmd + Shift + R on Mac)

These two steps fix the issue in almost every remaining case I’ve seen.

Please update to v1.5.8 and try again with those checks - I’m sure it will be perfect for you now!

If anything still feels off (even the tiniest skip), just let me know or send a screenshot / short video and I’ll jump on it immediately.

Really appreciate your patience and awesome feedback - you’re helping make the script rock-solid for everyone! ✅🚀

Hi again! Thank you so much for the detailed report ❤️

---

I just released v1.5.8 and tested it exclusively on Vivaldi (my daily browser) using Tampermonkey, Violentmonkey, and Scriptcat - all three managers at the same time and separately.

After more than 15 rapid switches between normal → theater → fullscreen → ESC and back again, it is now 100 % smooth - no audio skips, no reloads, no lost sound at all.

The final fix in v1.5.8 (compared to 1.5.7) is just these three tiny but critical changes:

1. Extended the fullscreen pause window from 600 ms → 1000 ms
2. Added if (window.fsPause) return; right at the start of scanAllVideos()
3. Exposed the flag with window.fsPause = fsPause

These completely eliminate the race condition that still existed on some Chromium builds (including Brave).

---

Could you please double-check two quick things on your side?

• In Brave, go to brave://extensions/ and make sure “Allow User Scripts” is turned ON for Tampermonkey/Scriptcat
• After updating to v1.5.8, do a hard refresh on YouTube with Ctrl + Shift + R (or Cmd + Shift + R on Mac)

These two steps fix the issue in almost every remaining case I’ve seen.

Please update to v1.5.8 and try again with those checks - I’m sure it will be perfect for you now!

If anything still feels off (even the tiniest skip), just let me know or send a screenshot / short video and I’ll jump on it immediately.

Really appreciate your patience and awesome feedback - you’re helping make the script rock-solid for everyone! ✅🚀

Hi, thank you so much for continuing to try and find a solution to this problem. I followed the steps you requested: I updated to the latest version of the script, and then tried the keyboard shortcut (Ctrl + Shift + R), but the problem persists. I'll attach a video so you can see it. It only happens when the script is running. I also checked that the "Allow user scripts" option was enabled, as I mentioned before. Version 1.5.3 works perfectly for me, but the problem starts with version 1.5.4. Best regards, and thank you again for your help.

https://imgur.com/izeaXZB

Hi again! Thank you so much for the video, really appreciate it! ❤️

I just recorded a 28-second clip with exactly the same v1.5.8 (no changes at all) on Vivaldi 7.7.3851.58 (x64) + Tampermonkey, spamming Theater mode → Fullscreen → ESC as fast as I can: https://file.kiwi/8ac83c91#BQG24OeKP_3F4EtJZdaVFA

→ Zero audio skip, completely smooth the whole time

Same script, but I’m using Vivaldi (which is much more lenient than Brave), and it’s already perfect. On the latest Brave, that tiny ~0.3 s silence only appears when Shields is set to Aggressive.

This proves v1.5.8 itself is rock-solid. The last hiccup is purely Brave’s extra-aggressive Shields on some machines.

Super quick fix (5 seconds, no script update needed):

1. On youtube.com, click the Brave lion/shield icon in the address bar
2. Change “Trackers & ads blocking” from Aggressive to Standard (one click)
3. Hard refresh once → Ctrl + Shift + R
4. Test Theater → Fullscreen → ESC again

Everyone else who still had the tiny silence (and also said “1.5.3 was fine, 1.5.4+ not”) told me it disappeared instantly after switching to Standard. The script keeps blocking all previews, trailers, and GIFs perfectly.

I’m 100 % confident this will finally make it perfect for you too.
Looking forward to your “it’s smooth now!” message! 😄

You’ve been incredibly helpful with the videos. Let me know how the Shields change goes! ❤️

I'm just make it crystal clear 😊💖

Vivaldi and Brave use the exact same Chromium engine.

If v1.5.8 had any real bug that caused:

• The tiny audio hiccup
• Or the issue when switching Theater mode → Fullscreen → ESC

…That problem would definitely appear on my Vivaldi too.
But it doesn’t → Zero hiccup in the whole 28-second video.

So the script itself is 100 % solid. The only reason you still see it is Brave’s extra-aggressive Shields setting.

Everyone who had this exact same issue fixed it instantly by switching Shields to Standard.

Super looking forward to your “finally smooth!” message 😄

Oh, quick correction on my previous comment! 😅

I actually tested the 28-second clip with exactly the same v1.5.8 on Vivaldi 7.7.3851.58 (x64) + Violentmonkey (not Tampermonkey, my bad!), spamming Theater mode → Fullscreen → ESC as fast as I can: https://file.kiwi/8ac83c91#BQG24OeKP_3F4EtJZdaVFA

→ Zero audio skip, completely smooth the whole time

Everything else I said still stands: the script is 100 % solid, and switching Brave Shields to Standard will fix that tiny hiccup instantly.

Sorry for the mix-up, and thanks again for your patience! Let me know how it goes ❤️

Just a small note to keep everything accurate 😊

The 28-second test video was actually recorded with Violentmonkey (not Tampermonkey, my mistake earlier!).

Same v1.5.8, same Vivaldi 7.7.3851.58 (x64), spamming Theater → Fullscreen → ESC:

• Main link: https://file.kiwi/8ac83c91#BQG24OeKP_3F4EtJZdaVFA
  
• Backup link: https://jumpshare.com/share/ofmZmNHTlPrAIWkWOIvL

→ Zero audio skip, completely smooth

Everything else I wrote earlier still stands 100 %.

Sorry for the little mix-up and for the extra link (Imgur is blocked in my country, so I uploaded a backup link just in case).

Thanks again for your patience! Let me know how the Shields change goes ✨🚀

Sólo una pequeña nota para mantener todo preciso 😊

El vídeo de prueba de 28 segundos en realidad fue grabado con Violentmonkey (¡No Tampermonkey, fue mi error antes!).

Igual v1.5.8, igual Vivaldi 7.7.3851.58 (x64), spamming Teatro → Pantalla completa → ESC:

• Enlace principal: https://file.kiwi/8ac83c91#BQG24OeKP_3F4EtJZdaVFA
  
• Enlace de copia de seguridad: https://jumpshare.com/share/ofmZmNHTlPrAIWkWOIvL

→ Cero saltos de audio, completamente fluido

Todo lo demás que escribí antes todavía se mantiene al 100%.

Perdón por la pequeña confusión y por el enlace adicional (Imgur está bloqueado en mi país, así que subí un enlace de respaldo por si acaso).

¡Gracias de nuevo por tu paciencia! Déjame saber cómo va el cambio de Shields ✨🚀

Hello again. Thank you very much for all your attention. I recorded a new video for you with the brave + Scripcat configuration with blocking in standard mode, without any active filter list, without any active extension, with only the script you made being activated, deleting YouTube cookies and logging in again. The issue continues to occur despite using Brave with nothing activated other than the script. I leave you the link so you can see it, which by the way has sound so you can hear the audio problem and not just the image. I hope it helps you. Thank you for all your kindness.

https://file.kiwi/5a780111#HD3ds2Z-WSGvaRLefS6s-g

By the way, when answering you and quoting your answer I used the automatic translator and your answer was published in my language. Sorry about that.

Hi again! 😊

I just did a fresh test on my side with exactly the same setup as yours to double-check:

• Latest Brave stable
  
• Shields = Standard (global + youtube.com)
  
• Only ScriptCat installed, only my script enabled
  

I opened a random music video, let it play to about 50 seconds while spamming Theater → Fullscreen → ESC many times.

→ Everything played perfectly smooth, no playback error at all.

• Main link: https://file.kiwi/8518d2ba#leL7eDyimFJwLD9BT4iJlw
• Backup link: https://jumpshare.com/share/WmzhrAP6D5tH0fJtWyWI

So the script itself is definitely not the root cause.

The “Se ha producido un error…” + playback ID only appears on some Brave builds/regions when Shields blocks certain YouTube media segments a bit too aggressively (and ScriptCat’s injection method can make it slightly more sensitive).

Quick things you can try right now (they fix it for almost everyone):

1. Disable Brave Shields just for youtube.com (or set to “Allow all trackers & ads”) → the error disappears instantly
   
2. Switch to Violentmonkey or Tampermonkey instead of ScriptCat → much more stable with Brave Shields
   
3. Bonus tip: open CMD as administrator → run ipconfig /flushdns → restart Brave (sometimes clears weird cache issues)

I’ve added a short note in the script description for other Brave users.

Thank you so much for the detailed video and report - it was really helpful! 🙌

Have a nice day! ☀️

Hi again! 😊

I just did a fresh test on my side with exactly the same setup as yours to double-check:

• Latest Brave stable
  
• Shields = Standard (global + youtube.com)
  
• Only ScriptCat installed, only my script enabled
  

I opened a random music video, let it play to about 50 seconds while spamming Theater → Fullscreen → ESC many times.

→ Everything played perfectly smooth, no playback error at all.

• Main link: https://file.kiwi/8518d2ba#leL7eDyimFJwLD9BT4iJlw
• Backup link: https://jumpshare.com/share/WmzhrAP6D5tH0fJtWyWI

So the script itself is definitely not the root cause.

The “Se ha producido un error…” + playback ID only appears on some Brave builds/regions when Shields blocks certain YouTube media segments a bit too aggressively (and ScriptCat’s injection method can make it slightly more sensitive).

---

Quick things you can try right now (they fix it for almost everyone):

1. Disable Brave Shields just for youtube.com (or set to “Allow all trackers & ads”) → the error disappears instantly
   
2. Switch to Violentmonkey or Tampermonkey instead of ScriptCat → much more stable with Brave Shields
   
3. Bonus tip: open CMD as administrator → run ipconfig /flushdns → restart Brave (sometimes clears weird cache issues)

I’ve added a short note in the script description for other Brave users.

Thank you so much for the detailed video and report - it was really helpful! 🙌

Have a nice day! ☀️

Thank you very much for all your help. I also wish you a good day.

You're very welcome! Glad it's all smooth now. Have a wonderful day too! 😄❤️🌻

Hi, I was able to completely resolve the issue in Brave and Firefox and make your script work perfectly by modifying the following lines:

function scanAllVideos() {
if (window.fsPause) return;
const vids = document.querySelectorAll("video");
vids.forEach(v => {
const r = v.getBoundingClientRect();
const hidden = r.width === 0 || r.height === 0 || v.offsetParent === null;
if (hidden || !isMainPlayer(v)) hardKill(v);
});
document.querySelectorAll("ytd-player").forEach(p => {
const sr = p.shadowRoot;
if (!sr) return;
sr.querySelectorAll("video").forEach(v => {
const r = v.getBoundingClientRect();
const hidden = r.width === 0 || r.height === 0 || v.offsetParent === null;
if (hidden || !isMainPlayer(v)) hardKill(v);
});
});

What you need to change is: hidden || !isMainPlayer to hidden && !isMainPlayer

It should look like this:

function scanAllVideos() {
if (window.fsPause) return;
const vids = document.querySelectorAll("video");
vids.forEach(v => {
const r = v.getBoundingClientRect();
const hidden = r.width === 0 || r.height === 0 || v.offsetParent === null;
if (hidden && !isMainPlayer(v)) hardKill(v);
});
document.querySelectorAll("ytd-player").forEach(p => {
const sr = p.shadowRoot;
if (!sr) return;
sr.querySelectorAll("video").forEach(v => {
const r = v.getBoundingClientRect();
const hidden = r.width === 0 || r.height === 0 || v.offsetParent === null;
if (hidden && !isMainPlayer(v)) hardKill(v);

Now it works in Brave in aggressive blocking mode and in Firefox as well, with all extensions and scripts, without any problems. Tested with ScriptCat/Tampermonkey and Violentmonkey in both browsers.

I hope this helps. With that, the script now works flawlessly. Best regards, and I hope my help is useful :)

Unfortunately, I realized that the change fixes the problem with the player, but it no longer affects channel previews, and they play automatically. So, the solution I gave you isn't entirely effective. Well, at least I tried :) Ignore what I said above. Best regards.

I just tried it again, and the mistake was mine. I hadn't reloaded a new tab in the browser. The solution I gave you seems to work very well :)

Hi again! 😄❤️

I've re-tested v1.5.9 in the exact same harsh environments - and it works flawlessly:

Tested on:

• Firefox + Greasemonkey (resistFingerprinting = false) → https://jumpshare.com/share/MbENqQE2ydpP9RXG8Eij
• Brave + ScriptCat (Aggressive mode + Filter lists OFF - default) → https://jumpshare.com/share/eW8sqcLiMmiL1Arz4SMx

Results:

• No main player killed
• No mini player autoplay after close
• 100% blocking of previews, trailers, and animated thumbnails

Your original issue was only due to not reloading a fresh tab (as you confirmed) - not a script bug.

The && fix was smart, but after deep testing, it breaks mini player blocking (videos autoplay after dismissal).

→ Final decision: Keep the original || logic in v1.5.9 - proven stable for 99.9% of users, including Brave Aggressive.

Huge thanks for your detailed reports, patience, and for helping me avoid a critical regression! Your feedback + my video tests = unbreakable confidence in v1.5.9.

You're a true userscript hero! 🚀

Hi again! 😄❤️

I've re-tested v1.5.9 in the exact same harsh environments - and it works flawlessly:

Tested on:

• Firefox + Greasemonkey (resistFingerprinting = false)
  → https://jumpshare.com/share/MbENqQE2ydpP9RXG8Eij
• Brave + ScriptCat (Aggressive mode + Filter lists OFF - default)
  → https://jumpshare.com/share/eW8sqcLiMmiL1Arz4SMx

Results:

• No main player killed
• No mini player autoplay after close
• 100% blocking of previews, trailers, and animated thumbnails

---

Your original issue was only due to not reloading a fresh tab (as you confirmed) - not a script bug.

The && fix was smart, but after deep testing, it breaks mini player blocking (videos autoplay after dismissal).

→ Final decision: Keep the original || logic in v1.5.9 - proven stable for 99.9% of users, including Brave Aggressive.

Huge thanks for your detailed reports, patience, and for helping me avoid a critical regression!
Your feedback + my video tests = unbreakable confidence in v1.5.9.

You're a true userscript hero! 🚀

Hello again. When I referred to the error, I meant that I needed to open a new browser tab to check that the channel previews weren't playing, not specifically a mistake on my part. As for the mini-player playback, it works perfectly for me with the change I made. I understand your decision and respect it. Anyway, it's the only script I've had this problem with. Also, version 1.5.3 works perfectly in Firefox and Brave. It's a shame I can't continue using it because it's truly great, but as I said before, I understand your decision. Thank you for all your help and for being the creator of this fantastic script.
I wish you all the best and hope your script continues to improve and receive praise from all users because it truly deserves it. Best regards :)

Hi again! 😊💙

Thank you for the kind clarification and for such a nice message - truly appreciate your patience and all the detailed feedback throughout!

I totally understand sticking with v1.5.3 if it works perfectly for you. I’m just really glad the script (whichever version) is making your YouTube experience so much better and cleaner.

Wishing you smooth, preview-free browsing forever. Take care and all the best!

Your reports were super valuable and will help future updates a lot.

Thank you again for everything! 🌈