Currently you are trying to configure updates in your UserScript metadata block using the script homepage with:

// @updateURL   https://openuserjs.org/scripts/Russtronic/ICE_Quick_Stream
// @downloadURL https://openuserjs.org/scripts/Russtronic/ICE_Quick_Stream

It is best to omit these keys as GM and most other .user.js engines will pick these for you. If you still choose to do this for older version compatibility, or just general consolidation to one site, please use the script source URI with the corresponding metadata routine URI and not the script homepage URI e.g.:

// @updateURL   https://openuserjs.org/meta/Russtronic/ICE_Quick_Stream.meta.js
// @downloadURL https://openuserjs.org/install/Russtronic/ICE_Quick_Stream.user.js

Thanks.

Test #350

Testing

The url at //apps.bdimg.com/libs/jquery/2.1.1/jquery.min.js isn't much better. You might give this site a read regarding appropriate official CDNs.

It is a little questionable that this script isn't using jQuery's site directly instead of the current at https://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.11.1.min.js

Re: @Dexmaster:

... I just didn't think it was needed.

If it's just two comments in the UserScript metadata block then I wouldn't worry with the @contributor key ... Since I was able to validate your identity from USO to here I corrected our OUJS "paper trail" with the fork links. Thanks again for a superb and nice notification. :)

@laminblur
Also a thank you to you for keeping the trail clean to the best of your knowledge. :)

Re: @Dexmaster:

Your original script mirrored is at http://userscripts-mirror.org/scripts/show/171749 and this "fork" of that USO script references it as well... so I reversed the fork source link since that script on USO predates both of the scripts here on OUJS.

If you used or derived from some of laminblur's code (which may be indicated by your original fork of his OUJS code which is a fork of your USO code... confusing I know ;) I would recommend being polite and giving a @contributor UserScript metadata block item or @attribution... or perhaps some note on your script page with some courtesy attribution back here.

Force closing this issue momentarily.

P.S. Thank you for being courteous of forking here and being professional on your notice. :) This is what OUJS would like to always see rather than "stolen this or stolen that" ... e.g. THANK YOU! :)

It is a little questionable that this script isn't using jQuery's site directly instead of the current at https://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.11.1.min.js

You also have this issue on your other published script.

It is a little questionable that this script isn't using jQuery's site directly instead of the current at https://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.11.1.min.js

You also have this issue on a few other scripts as well.

It is recommended to utilize the @license key in your UserScript metadata block and also you need to point it to the correct GH url at https://raw.githubusercontent.com/HodofHod/Userscripts/master/LICENSE instead of https://raw2.github.com/HodofHod/Userscripts/master/LICENSE

Thanks.

Re: @yasingedik:

... did not work either ...

Found a reason for SeaMonkey and Firefox that it won't work... because some of your CSS rules don't have a closing } on a few lines. e.g. the CSS is being dropped due to syntax errors in the styling. Try the fork I did in TamperMonkey and let me know how it goes for you. Thanks. :)

Re: @yasingedik:

... did not work either...

Now you've really peaked my curiosity here...

• First off do you have a public link to a page where this script is supposed to make a large visible alteration so I can see what kind of style you are applying? e.g. not just http://reader.aol.com/
• Secondly... for grins I did a temporary fork of your project here to test in TamperMonkey versus your individual ones in this one.

Let me know at your earliest convenience for the above.

Nothing to see just testing issue creation on production.

Re: @yasingedik:

I would be glad if you can point me to a resource to learn how to fix that.

It should be supported in JavaScript and the Array method of join is also base JavaScript so shouldn't need to be dependent upon Tampermonkey. shrugs

You might try the line continuation character of \ instead of these functions too if there is some issue in those browsers not supporting standard JavaScript methods:

GM_addStyle("\
  .header-search-wrap { margin-top: 0px !important;}\
  .dropdown-menu-add .page-container {height: 498px !important;}",\
  .dropdown-menu-add {height: 500px !important; left: -50px !important; max-height: 500px !important;}\
"})();

This is not as pretty and readable I think but will also simplify the DOM a bit since GM_addStyle can create style tags at every use... if you find a way to put it as one big string then utilize that GM API once you'll be speeding up the page a bit. :) Thanks for the consideration.

This script is "unlicensed" which doesn't fall within the Terms of Service here on OUJS.

Please correct soon or it will be removed.

Re: @Ede_123:

It's pulling the meta.js from https://openuserjs.org/install/Ede_123/OpenSubtitles_Direct_Downloads.meta.js

Have you actually tried clicking that link directly? GM and other engines will use that and it 404's because you didn't use the OUJS form, which for this script is:

https://openuserjs.org/meta/Ede_123/OpenSubtitles_Direct_Downloads.meta.js

Some of the engines fallback on error to the install path, in OUJS case that would be https://openuserjs.org/install/Ede_123/OpenSubtitles_Direct_Downloads.user.js ... so you aren't using the update mechanism in some engines and making your users use full source instead of meta.js... thus you are breaking the update mechanism. Not to mention if the engine isn't smart enough to store the failure and never request it again... e.g. generating more traffic than may be necessary. On any engine that doesn't support the request header, e.g. older GM versions for example, you are sending out a request that fails to update.

All of this is usually why it's recommended to let the engine handle it to avoid confusion. Consolidation is okay and a feature available but if you want OUJS to handle it for GH installs... then you need to use the proper route (path) to the meta.js routine. :) Does this all make more sense now?

Re: @Ede_123:

strips @updateURL and @downloadURL for uploaded scripts

Different and questionable methodology that OUJS doesn't support nor any of the known .user.js engines. OUJS attempts to offer the same choices that the engines do instead of no choice.

I had hoped updates would automatically be pulled from OUJS?

If you want to force update checks, or consolidate, from OUJS (or another site) you can specify it manually. The .user.js engines default from whatever site it is installed from, which that methodology is demonstrated at oujs - Meta View, and that breadcrumb trail leads to #105 (comment) for the manual route (a.k.a the @updateURL).

GitHub where no meta.js is available

Some authors create one manually or with script processing before committing to GH to make one.

The choice is yours on how to handle this correctly. Just thought I'd pipe in that I saw you were assuming USO standards not OUJS... and breaking updates with all .user.js engines that support updating e.g. your users won't get updates on a url that returns 404 from us. :)

You appear to have this issue on multiple scripts as well.

While we at OUJS do have meta.js your implementation is incorrect. Modern .user.js managers already support these automatically so technically they can be omitted.

Target code:

// @updateURL   https://openuserjs.org/install/Ede_123/OpenSubtitles_Direct_Downloads.meta.js

Thanks.

This script is "unlicensed" which doesn't fall within the Terms of Service here on OUJS.

Please correct soon or it will be removed.

You've been warned multiple times on this before. Termination of this script is in effect.

Re: @decembre:

No news.

This has an official home issue now at #601