Greasy Fork

Not working after update

this plugin just updated and its not working anymore :/

Use it with Tampermonkey inside of Google Chrome or Safari. Those are the only officially supported browsers, as the script description says, and it works perfectly in both of them.

I had to update the script to 1.5 because of recent changes to either Tampermonkey or YouTube which totally broke v1.4 and earlier of the script. In previous versions, I checked for the existence of the "window.ytplayer" object to detect if we were injected into the page too late or not, but since about a week, that object always exists now, which meant that the script was totally broken.

So 1.5 is fixed. I rewrote the "injection success?" detection method. And it's working perfectly in Chrome and Safari. Is it not working for you in Firefox?

I don't use Firefox, so I can't help with that. If you or someone else wants to do the _work_ of adding support for Firefox, let me know.

I tried it on chrome with tampermonkey and it worked. Guess i will just have to use an old version now on.

I tried it on chrome with tampermonkey and it worked. Guess i will just have to use an old version now on.

The only thing I can think of is that Firefox may be loading the page too slowly, so that we're giving up as "injection failed" too early. Try 1.5 and scroll down to the bottom of the script and edit the number "250" (milliseconds) to 1000. That would raise the pause from 0.25 to 1 second. So it goes: 1. Inject, 2. Wait for a second, 3. Check if the injected code was called by YouTube during that second.

By the way, just to make sure 1.4 truly works for you: Look in your address bar. Do you see the word "#fpsreloads=2" in the address when viewing a YouTube video? If so, you are suffering from a bug which recently became a problem after changes to either Tampermonkey or YouTube. If you see that word, it means that injection failed, AND that the script ALSO failed to clean up after itself and display the red warning bar about the failure.

For a long time I didn't know there was a problem with 1.4, since that bug in 1.4 and earlier silently appeared a few weeks ago due to something that Tampermonkey or YouTube did... I noticed the problem yesterday for the first time, when I just happened to notice that "fpsreloads=2" remained in the title bar.

So it's possible that 1.4 actually isn't working for you either.

As far as I can tell, it is actually working on Firefox. It's the error that's incorrect.

At least, if you load a new tab or refresh an old one. If you, for instance, go directly from the front page of YouTube to a new video, then it doesn't inject and also does not leave behind an error. (YouTube doesn't actually reload pages when you click a link. It replaces the current page.)

The previous version simply does not work at all, even if you go back to the old UI. No error, but also no tag at the end of the URL. The 60fps versions are still present.

I haven't tested earlier versions.

I realize that Firefox is not the supported engine, but I would at least recommend fixing the error so it pops up when it fails (prompting a refresh which will fix the issue) and will not pop up when the script works.

Even if you still only support Chrome and Safari with Tampermonkey, such changes will only make your code less brittle, in my experience. You aren't relying on idiosyncratic things that may change in the future.

Plus, well, it already works as well as it does on Safari. It's a shame that a lot of people are going to start marking this as not-working when it does. People expect any userscript to work on any engine. That's part of the appeal.

i changed it to 1000 and it is working now

@trlkly Thanks for all the research!

I'll address each point.

If you, for instance, go directly from the front page of YouTube to a new video, then it doesn't inject and also does not leave behind an error. (YouTube doesn't actually reload pages when you click a link. It replaces the current page.)

Here's what the script does if we're directly opening a video page URL in a new web tab (a /watch URL):

1. Inject.
2. Wait a moment (0.25 seconds), then verify if injection was successful. It does this by checking if our injected "high-FPS format"-blocker has been used by YouTube or not.
3. If it hasn't been called, it means that YouTube has already checked format and enabled high-FPS before Tampermonkey loaded our userscript. So it knows that injection failed and was done too late (due to Tampermonkey loading our script too late), and therefore reloads the page (up to a total of 3 attempts) to try to inject early enough.
4. If the user navigates to another video, YouTube simply "replaces" the current page (as you say), without reloading the entire site, so the injected format-blocker code is still in memory and therefore no more injections/checks take place by this script on subsequent videos in that tab. Because everything will be blocked perfectly in that tab from then on.

Here's what the script does if we open any non-video YouTube page in a new web tab:

1. Inject.
2. Nothing else... Because if we're on any other page (such as youtube.com, or a channel page, or a search page), then YouTube won't even query the format-checker yet (because there's no video player on the page). So there's no risk for us to inject "too late" if we're on a non-video page. And then, if the user navigates onwards to a video-page, our injected checker is still in-memory in that tab and will successfully block all high-FPS formats.

The previous version simply does not work at all, even if you go back to the old UI. No error, but also no tag at the end of the URL. The 60fps versions are still present.

Then that suggests to me that Firefox has a general problem with Userscripts NEVER Injecting userscripts early enough. Or perhaps TOO early?

I realize that Firefox is not the supported engine, but I would at least recommend fixing the error so it pops up when it fails (prompting a refresh which will fix the issue) and will not pop up when the script works.

Even if you still only support Chrome and Safari with Tampermonkey, such changes will only make your code less brittle, in my experience. You aren't relying on idiosyncratic things that may change in the future.

Plus, well, it already works as well as it does on Safari. It's a shame that a lot of people are going to start marking this as not-working when it does. People expect any userscript to work on any engine. That's part of the appeal.

It seems like Firefox can't be made to work, if indeed scripts load too late in Firefox.

This script isn't like other Userscripts, because this one must be injected *extremely early* in the loading process of the YouTube webpage. Otherwise YouTube has already queried format support and enabled high-FPS mode by the time the userscript runs.

But sigh, okay, I'll install Firefox now and see what I can do... ;)

@trlkly Initial test results with Tampermonkey in Firefox 55.0.3:

- Going to YouTube.com (so that injection happens early before a video page has been opened), then navigating to a video or searching for a video: Works. I enabled debug-mode in my script (set "false" to "true" near the absolute bottom of the script) and looked in the console and could see it blocking all high-FPS formats. Also confirmed by checking the format menu and only seeing "1080p" instead of "1080p60".

- Going directly to a /watch page: Does 3 attempts at reloading the page then shows the red error-bar. You said you didn't see this bar at all. I see it. Using Tampermonkey in Firefox... However, here's something more interesting: I am not sure WHY I see that error, because I can see from my debug-logging in the Javascript console that the injection succeeded and that it has blocked high-FPS formats. I think there's possibly a Firefox javascript engine variable scope issue with the counter variable I use for checking if execution succeeded. I'll investigate...

Okay, I have the answer now... It was the thing I suggested to Victor above:

Here's what I wrote:

The only thing I can think of is that Firefox may be loading the page too slowly, so that we're giving up as "injection failed" too early. Try 1.5 and scroll down to the bottom of the script and edit the number "250" (milliseconds) to 1000. That would raise the pause from 0.25 to 1 second. So it goes: 1. Inject, 2. Wait for a second, 3. Check if the injected code was called by YouTube during that second.

If I raised the "success-check" delay, Firefox succeeded too.

So here's the problem: Firefox loads YouTube very slowly.

We therefore inject, then wait 0.25 seconds, and expect YouTube to have called the format-checker in that time (because in Safari and Chrome, that function is called within like 0.05 seconds, so 0.25 seconds wait is safe there). But Firefox is a much slower browser. In fact, it is a *muuuuuuch* slower browser. It needs a value of about 1 second, at a minimum!

So: Chrome and Safari are fast and the YouTube scripts run and check the high-FPS codec support within 0.05 seconds after our injection. Firefox is super slow and needs at least 1.00 seconds of waiting until YouTube's scripts run and check the codec.

Damn...

The reason I use this "hacky" timer-based approach is unfortunately because the old, reliable method no longer works. I didn't like it and felt bad about it, but it's the best we can do now. I used to simply and reliably check "If window.ytplayer exists, we know that YouTube's own scripts have already executed and that we have been injected too late". It worked perfectly. But for some weird reason, that window.ytplayer object now ALWAYS exists when our script runs, even if we run before YouTube's own code, so we'd always detect ourselves as "failed" even if we had succeeded... So I had to change to this new method of "inject, then wait, then check if our injected code has been used".

And I want the timer-delay to be as short as possible, so that the page-reloads (injection attempts) are almost unnoticeable to the user, in the browsers that need it. The 250ms delay achieves that. You can barely notice it reloading the page to re-inject, since it happens so quickly.

Raising the delay to 1 second to appease Firefox is unacceptable.

But perhaps I should code something that says "if Chrome or Safari, use 250ms, if other browser (like Firefox) use 1500ms". The good news is actually that since Firefox is so slow at loading webpages, there's practically zero risk of us injecting too late, so it doesn't matter if we use a long 1.5 second "success-check" timer in Firefox, since our userscript will always run about a second before YouTube's own code runs (and checks for high-FPS format support). So even a long "check injection success?" delay like that will be unnoticeable in Firefox, since it should always be succeeding on the first injection attempt in that browser...

So I guess that'll be the solution... Only highly-efficient browsers like Chrome and Safari have the risk of the webpage's own scripts running so fast that they've already executed before the Userscript. Firefox doesn't seem to have that risk at all since it's a slow browser (or perhaps just structures its Javascript engine differently, so that extensions always execute a long time before the main page code).

Okay so v1.6 was just released, with unofficial Firefox support. Literally all code was working, *except* that Firefox runs YouTube's own scripts very late after this userscript has executed (*at least* 1 second later). So I made all non-Chrome/Safari browsers now use a 2 second timer before checking for successful injection (Chrome and Safari still use 0.25 seconds). This should be long enough to ensure that it works in all browsers, since I don't have time to test all other browsers to find their individual delays.

And this 2 second value should be safe even on slow internet connections, since YouTube's scripts will already be in their browser's cache and will therefore always be ready to run within about 1 second every time the page loads. But if there are any problems on specific systems, I'm sure I'll get reports about it, and I'll tweak the timers further if needed.

I wish I didn't have to use timers at all, but the old injection detection method no longer worked. And this new method is actually better (as long as the timers are set properly), since it checks for actual usage of our injected function to be sure it really, *truly* was called by YouTube!

Anyway, that's it. The script now works in Firefox (and probably other unofficially supported browsers too) and injects successfully on the 1st attempt every time I tried loading the video page.

And before I uninstalled Firefox again, I tested my other YouTube-related script. It works too, if you're interested in it: https://greasyfork.org/en/scripts/32954-automatic-material-dark-mode-for-youtube

Enjoy!

Thanks man, you are awesome :smiley:

Hehe, and thanks to both of you for reporting the issue. I am glad it's fixed! More browser support is better! :)

steve can you check if its working on opera? i get the error sometimes, but not on chrome.

@Picollo30 Hi, sorry I don't have time to install Opera and investigate. I have around 20 big things that I need to do in other programming projects and no time for this.

Are you using Tampermonkey?

If you are, and Opera still fails, then here's how to investigate further: Go down to the bottom of the script file and change the "false" parameter to a "true" to enable debugging in the "createNewTypeChecker" function call. This will make the javascript developer console output some text whenever YouTube checks the browser's FPS/format support.

Next, reload a YouTube video page a few times and look at the console to see what happens. See how long it takes for the format-block messages to appear in the console.

Lastly, if you notice that there are no messages in the console before the page reloads itself, it means that YouTube's format-checker actually never queried us, which either means our injection code ran too late (most likely!), OR that we checked for "has our injected code been queried by YouTube?" too early and gave up the wait too early (but that is very unlikely since the delay before we check is very long in generic un-tuned browsers).

In generic unsupported browsers, the delay is 2000 milliseconds aka 2 seconds (which is a looooong chance for even slow/weird browsers to run). Find that number and try 5000 to wait even longer before we assume that "YouTube has already enabled high-FPS and that we were injected too late". Raise it and see if that makes Opera work, just incase Opera injects our script veeeery early, multiple seconds before YouTube does its check.

PS: I think I know why all these problems began happening a few weeks ago. YouTube launched their new site design officially and probably simultaneously decided to improve the browser caching/CDN availability of all of their site code to ensure their site loads really fast, and probably optimized their code a bit. As a result, YouTube is now even faster at doing its "should we enable high-FPS support?" check, and that is why I needed to do the rewrite of this script to change the injection success check method. Because the old method stopped being reliable.

This is a headache. If Tampermonkey's run-at document-start could TRULY always guarantee that our code runs before the website's own code has even started running, then we would NEVER inject too late. Because my code is written totally correctly, but I am at the mercy of whether Tampermonkey and the user's browser succeeds with my @run-at document-start instruction or not. Unfortunately, Tampermonkey isn't always perfect, and different browsers also handle extension/script loading differently... which is why some browsers work perfectly 100% of the time, and why others inject too late (either all the time, or some of the time). And this script absolutely MUST run before YouTube's own code, which is why I cannot guarantee supporting every browser on the planet, if certain browsers load userscripts poorly. If a certain browser always/often injects my code too late, then no rewrites of my code would help, because then YouTube has already enabled high-fps long before my code even runs, so there's nothing I can do. It SEEMS like that's what is happening with Opera (because it had the window.ytplayer problem in the pre-rewrite version, which means Opera is the kind of browser that's too-late at injecting).

I hope it can be fixed, of course. But Opera may not be capable of reliably injecting early enough.

@Picollo30 Hi. I have now released v1.7, which now uses a hybrid method of checking for success. I did this to improve behavior in Chrome and Safari after discovering some problematic videos, but this final rewrite will actually fix everything for all browsers (as long as those browsers are capable of early userscript injection before YouTube's own code runs).

I'm glad this technique was possible, because it made the script rock-solid. It's like the best of v1.4 and earlier (before YouTube's redesign broke that one), and the best of the v1.5+ timer-based solution. Now we have both, as a hybrid:

1. First, my script checks if YouTube's player code is already loaded (via a new, reliable technique I finally came up with). If we see their code, it means the web browser failed to inject us early enough. If so, then we instantly reload the page to try again.
2. After that (if we see that YouTube's player code hasn't been loaded yet), then we know that we've been executed early enough by the browser, so we proceed and inject our format blocker.
3. Lastly, we wait a few seconds (12 seconds, actually) and do a final success-verification to see if the formats were truly blocked. If not, then we treat it as a failure and reload the page to try again. But this step should never be able to fail (which is why the timer is so long now), since the 1st step made sure that we're definitely injected before YouTube's high-FPS format check has ran. This final step is just a nice, extra safety check just in case there's ever a scenario where it can happen.

Since you said that "Opera sometimes fails", I now know the problem with Opera: It's a lot slower than Chrome, Safari and Firefox at loading webpages, which meant that our "success check?" timer gave up too early in some cases in Opera. So my advice to you above, about raising the timer from 2s to 5s, would have helped you. But it doesn't matter anymore, because after I came up with this new hybrid method, I no longer needed to have such a "fast" success-check timer. The primary failure detection is now instant instead via the new method (step 1), and we instead use a much longer 12-second timer just as our "final verification". So there's no risk anymore even in slow browsers.

Result: I am sure that even Opera is going to work perfectly now. Have fun and enjoy YouTube! ;-)

its working. thank you

@Picollo30 :smile:

So it stopped working again... I guess its because i'm not using the new layout?

So it stopped working again... I guess its because i'm not using the new layout?

Hi. I can 100% certainly say that you're still using v1.6 or earlier (the one which you initially installed when I "added Firefox support"). The timer system in v1.6 was still unreliable, and it could actually still have problems on certain videos.

As you may remember, since you were helping with the Firefox testing, I set Firefox and other "unsupported browsers" to a 2-second timer that did "wait for 2s, then check for high-FPS blocking success, or retry if we haven't blocked any high-FPS". I used 2 seconds, thinking that was more than enough, since we'd always seen success even with a 1-second timer in Firefox. But for some reason, certain YouTube video pages load much slower than normal, for example requiring 2.5-3 seconds instead. Which leads to the script giving up on those pages, thinking they've failed (the script thinks "we must have been too late, since we’ve waited 2 seconds and YouTube still hasn't done any FPS checks yet").

An example of a video which always fails is this weird one, which always takes 2.5-5 seconds until the page has finished loading and YouTube has done its high-FPS format check (I have no idea why this page is special, but it is... and it's a great way to test slow video pages):

https://www.youtube.com/watch?v=HGAWk2Z6OJQ

After realizing that timers were never going to work reliably (there are too many variations in performance), I kept coding and analyzing YouTube to try to figure out if there was any other way to be able to check "have we blocked high-FPS, or do we need to reload the page to retry?" without relying on timers.

To recap so far, here's the project history:

1. Initially, I didn’t have timers at all. I used to look for "window.ytplayer" (YouTube's player code). If it was missing, this script knew it had been loaded early enough (before the player even exists). If the player object exists, we've failed, so we reload the page to retry. It worked very well and the checking was instant.
2. But with YouTube's new site layout, they broke that method. So v1.4 stopped working.
3. Since it wasn't possible to look for a "missing player" anymore, I released v1.5+v1.6 (a tweak to it) which used a timer system instead, where the page loads, this high-FPS blocker is injected, then it waits a short moment and then verifies that we've blocked any high-FPS formats. If we haven't blocked anything, we reload the page to retry as usual. This system initially seemed to work perfectly...
4. But the timers turned out to still be too unreliable, and sometimes too short... so I had to research other methods to see if a better method was possible. Either raising the timeout lengths even more, or perhaps finding a way to truly solve it again (like in the old versions), because this was getting ridiculous...

After a lot of research, I discovered that there was a way to check for the existence of YouTube's player code. I saw that "window.ytplayer" exists (that's the problem since YouTube's layout change), but that it has 0 (ZERO!) properties before the YouTube page has fully loaded its code. Bingo! I had finally found a way to check for the player code again. If we don't see any player code, we know we're early enough, and won't need to use timers!

So I released v1.7 with a brand new, instant success-check (similar to v1.4 and earlier, but much better): "if window.ytplayer is missing or has 0 properties, treat that as success". Additionally, it also launches a twelve second "double-check verification timer" (longer than any browser will ever need; they've all done the format blocking in less than 5 seconds), which waits and then verifies that high-FPS formats have been blocked, just to be 100% sure. It's the best of both worlds.

The new system works perfectly in every browser, so I released v1.8 and v1.9 with some general code cleanups of all the other code to finalize everything. The script landed stably on v1.9 a few days ago, and I don’t think it’s going to need any updates for years now, since YouTube has finished their new design already.

This has been a lot of work and headaches, but the latest code is finally up to my quality standards and is super reliable. It's even better than all older versions before YouTube broke them.

1. v1.9 works on both new and old YouTube designs. On the old design, the code behaves like an improved version of the exact method used in "v1.4 and earlier".
2. v1.9 works in any browser that is capable of early script injection, like Firefox, Chrome, Safari, Opera. All of those have been verified.

I just installed the latest Firefox+Tampermonkey again just in case, and tried the new and old YouTube designs with v1.9 of this script, and navigated around to tons of videos, and had a 100% success rate. I enabled debug output, and saw that the new detection method ("window.ytplayer having 0 properties") worked perfectly in Firefox too (as it should), and I also saw that Firefox did all of its high-FPS blocking in 800-5000ms, usually around 1200-1800ms. And since the new system waits 12000ms before doing its final double-check verification, there's literally zero chance that you've installed v1.9 of this script. Because it works perfectly. ;-)

This post was a really long way of saying "Update your installed version of the script". ;-)

Have fun!

I'm using the 1.6 because its the version that its working for me. I tried the 1.7, 1.8 and 1.9 versions and none of them worked

As I explained above, I installed and ran the latest Firefox+Tampermonkey+v1.9 today and it was 100% perfect. Firefox behaved exactly as any good browser should, and ran all code and succeeded all tests perfectly, and will never have a problem again with v1.9.

Okay it’s time that you do some of the work: Please update/reinstall your Firefox to the latest version. Delete or create a new Firefox profile with 0 addons. Install the latest Tampermonkey (and no other addons). And install v1.9 of the script. It will work.

And there is no way your computer is taking over 12 seconds from ”page almost fully loaded; browser has injected the script” to ”fully loaded the webpage”, which is the timeout length of the long ”double-check verification-timer” in v1.9. Twelve seconds for that step is ridiculously long. I have a slow 7-year old laptop and it never took more than 5 seconds in any browsers, normally 1-2. Something else is wrong specifically with your computer/Firefox configuration. Probably another addon in your browser is conflicting. :-) Perhaps you have some other YouTube userscript, which is messing with the window.ytplayer object and adding properties to it so that it looks like the browser has loaded our script too late. If you can figure out which of your other addons/script is responsible, we can see if it’s possible to work around that.

This is how you create a blank new Firefox profile on Windows: http://kb.mozillazine.org/CreatinganewFirefoxprofileonWindows

I found out the problem: Greasemonkey. Tested with Tampermonkey and it did work. Thank you

or not... There's a problem, it is working but the checking is failing.

I just restarted firefox and its working again...

I just restarted firefox and its working again...

Thanks for that info! Please let me know if it keeps working now after you’ve switched to Tampermonkey.

This script relies completely on your browser+Tampermonkey being fast enough at injecting our code BEFORE YouTube has enabled high-FPS mode. If our script is injected too late by a slow web browser or a slow script manager, then we can’t succeed because high-FPS has been enabled already by YouTube. That is why I cannot guarantee that all web browsers are good enough.

There is a reason why the error message says ”Your browser has failed to disable high-FPS playback in this tab.” It is not a failure of my script. It is a failure of the web browser to run my script early enough.

So here’s a potential reason for the issue: Greasemonkey is not reliable enough (I may have to add a warning in the readme against Greasemonkey in that case, to tell people to use Tampermonkey). Alternatively, you have so many addons that Firefox is sloooowly loading addon in new tabs, and it takes too long and slows down userscript injection until after YouTube has already enabled high-FPS.

Hey Victor, I installed the latest Firefox one final time to investigate what you said about Greasemonkey.

I can confirm that Greasemonkey is a bad extension.

Here are the results for Firefox userscript managers, from best to worst, measured as the amount of time that elapses between the injection of this script, until YouTube's own code runs. Higher values are better, because it means the userscript manager was good at injecting the script very early, long before YouTube's own code has any risk of running. As I've said a million times now, this script needs a good web browser + userscript manager which injects it before YouTube's code runs and enables high-FPS, so higher values below mean earlier userscript injection into the webpage which means better chances of early-injection success.

Best: Tampermonkey: ~1300-2500ms. Bad (risky): Greasemonkey: ~600-800ms. Worst (extremely risky): Violentmonkey: ~200-600ms, usually 400ms.

If I could, I would write code that bans usage of this script in Greasemonkey and Violentmonkey, so that I don't get blamed for those bad userscript manager's problems anymore... Sadly, it's not possible for scripts to detect what "userscript manager" they're running under, so I can't do that. But I guess I'll add a warning to the readme/description page of this script later.

I have now updated the INSTALLATION section of the readme/description, to let people know how important it is to use the best and most reliable userscript manager (Tampermonkey): https://greasyfork.org/en/scripts/23329-disable-youtube-60-fps-force-30-fps

PS: @Victor your slight remaining problems were probably because you still had Greasemonkey installed too, and had the script in both. You should remove Greasemonkey completely and put all your scripts entirely in Tampermonkey instead. :-)

And here i am again. This time with a request. Can you verify the compatibility with Youtube Center? When youtube center is installed, the script immediately just gives up and tries to reload the page until it reach the limit.

And here i am again. This time with a request. Can you verify the compatibility with Youtube Center? When youtube center is installed, the script immediately just gives up and tries to reload the page until it reach the limit.

This, right? https://greasyfork.org/en/scripts/943-youtube-center

At this exact moment as I write these words, I have now used the latest versions of all browsers as follows:

- Firefox 57 + Tampermonkey + YouTube 60fps + YouTube Center + Testing in both the New Material the theme and "Old Theme" for YouTube = Perfect.
- Google Chrome 62 + Tampermonkey + YouTube 60fps + YouTube Center + Testing in both the New Material the theme and "Old Theme" for YouTube = Perfect.
- Safari 11 + Tampermonkey + YouTube 60fps + YouTube Center + Testing in both the New Material the theme and "Old Theme" for YouTube = Perfect.

The issue on your system is elsewhere.

Please don't tell me you're using the totally garbage GreaseMonkey or ViolentMonkey? They are not good script managers. Very slow. Fails a lot. As shown earlier in these discussions.

And if you have many scripts (or very big ones like YouTube center which is half a MEGABYTE of code), bad script managers together with such big scripts might delay the injection so far after YouTube's page loading, that it's impossible to inject early enough to prevent YouTube from enabling high-fps.

Anyway, YouTube Center and 60 fps are compatible with each other. The issue is elsewhere. Good luck troubleshooting it.

I'm using the developer version (the main version wasn't updated in years) with firefox 57 and tampermonkey. The only things i use to change youtube is youtube center, magic actions and force 30fps. I've already tried without magic actions and the result is the same as before.

Ok where is the developer version?

https://github.com/YePpHa/YouTubeCenter/wiki/Developer-Version

I see that the dev-version of YouTube Center is now installing its own settings into YouTube's window.ytplayer, and particularly YouTube's core load and config properties. That's not good... Because my script logically assumes YouTube is the only one inserting stuff into YouTube's settings storage.

Not sure there's anything I can do about this. I will look at it but no promises. I may be able to make it work... maybe. No promises, because there's less than a 25% chance of success once I start doing research into it...

For this script to succeed, we must inject before YouTube's code has executed. To know if YouTube's code has executed, we look if YouTube has loaded its player code/settings yet. But since YouTube Center inserts garbage into that place, into the exact same properties as the real YouTube code, it may not be possible to differentiate between their garbage and the real YouTube code... Therefore I cannot promise anything. But I'll have a look at it.

By the way, please edit your first post and change the rating to Ok (go to the first page and press Edit in the top right and change the rating). Because my script is working and doesn't deserve a bad rating. I'll definitely not do anything about YouTube Center until the rating is fixed since it feels very unfair. ;-)

You'll also need to export your settings. Go to YouTube Center's settings - General - Import/Export Settings. Copy your own settings and paste it here via pastebin.com.

Because YouTube Center Developer Version works perfectly together with YouTube 30fps, at least with YouTube Center's default settings, in Firefox 57.0 (latest) with Tampermonkey (latest) and only YouTube Center and 30fps installed. Since YouTube Center is for the old YouTube theme, I switched to the old theme to try this.

Therefore it's your particular settings, if anything is wrong at all. So I need your settings. I won't put much more effort into this since YouTube Center project is dead (https://github.com/YePpHa/YouTubeCenter/issues/2416#issuecomment-300151257), and YouTube's old design will soon be dead and vanish too...

But I'll give it a quick look if you paste your settings (since YouTube Center works at its defaults), and also update your review in this topic to Ok/Good.