AstroSkipper

I have even tested my youtube.luac file in the last XP-compatible VLC beta 3.0.24 (the very last recent versions are no longer compatible with Windows XP 😟) and @nicolaasjan's yt-dlp version from 10.06.2026.

Today, I have tested my youtube.lua script again. And it is working in VLC v3.0.23 without any problems. No errors, no loops and no need to click the Play button more times. On older hardware, the video format h264 is the best option. That's why my script uses this codec. Here is my last code again with the bracket correction mentioned by @Ben Markson: -- YouTube Link Resolver for VLC with Separate Video and Audio URLs -- Place this script in VLC's lua/playlist directory local yt_dlp_path = 'yt-dlp.exe' local yt_dlp_silent_path = 'hidecon.exe' function sleep(s) local ntime = os.time() + s repeat until os.time() > ntime end function probe() -- Check if the input is a YouTube link return (vlc.access == "http" or vlc.access == "https") and (string.match(vlc.path, "youtube%.com") or string.match(vlc.path, "youtu%.be")) end function parse() -- Construct the full YouTube URL local youtube_url = vlc.access .. "://" .. vlc.path -- Extract "quality" query parameter if present local quality = youtube_url:match("[&?]quality=(%d+)[pP]?") youtube_url = youtube_url:gsub("[&?]quality=%d+[pP]?", ""):gsub("[&?]$", "") -- Remove trailing ? or & -- Get the preferred resolution preset by the user in VLC local prefres = vlc.var.inherit(nil, "preferred-resolution") if prefres < 0 then prefres = 2160 -- Best quality set to 2160p to overwrite VLC's native value of -1 end local allowed_qualities = { ["240"] = true, ["360"] = true, ["480"] = true, ["720"] = true, ["1080"] = true, ["2160"] = true } -- Default quality limited to the preferred resolution taken from VLC's settings local format_string = string.format("bestvideo[height<=%i]+bestaudio", prefres) if quality and allowed_qualities[quality] then format_string = string.format("bestvideo[height<=%i]+bestaudio", quality) vlc.msg.info("Using requested quality: " .. quality .. "p") else vlc.msg.info("No valid quality specified. Defaulting to best available.") end local cmd_hidden = 'hidecon &' -- Start cmd hidden and ... -- No better codec than h264 (an important switch for older hardware). This can of course be changed by the users according to their needs. local codec_limit = '-S "codec:h264"' local video_url = '' local audio_url = '' local yt_dlp_silent_exists = io.open(yt_dlp_silent_path, "r") ~= nil if not yt_dlp_silent_exists then vlc.msg.info(yt_dlp_silent_path .. " not found. Falling back to " .. yt_dlp_path) cmd_hidden = 'PowerShell.exe -windowstyle hidden cmd /c &' -- Start cmd hidden and ... local cmd = string.format( '%s "%s" %s -f \"%s\" -g "%s"', cmd_hidden, yt_dlp_path, codec_limit, format_string, youtube_url ) local handle = io.popen(cmd) video_url = handle:read("*l") audio_url = handle:read("*l") handle:close() else vlc.msg.info(yt_dlp_silent_path .. " found. Running program") local cmd = string.format( '%s "%s" %s -f \"%s\" -g "%s"', cmd_hidden, yt_dlp_path, codec_limit, format_string, youtube_url ) local handle = io.popen(cmd) video_url = handle:read("*l") audio_url = handle:read("*l") handle:close() end video_url = video_url and video_url:gsub("^%s+", ""):gsub("%s+$", "") or "" audio_url = audio_url and audio_url:gsub("^%s+", ""):gsub("%s+$", "") or "" vlc.msg.info("[YouTube Resolver] Original URL: " .. youtube_url) vlc.msg.info("[YouTube Resolver] Video URL: " .. video_url) if audio_url and audio_url ~= "" then return { { path = video_url, name = vlc.path .. " (Video)", options = { ":input-slave=" .. audio_url } } } else return { { path = video_url, name = vlc.path .. " (Video + Audio)" } } end end And today I reduced and optimised my code again and compiled it to a LUAC file. Here is my most recent version for old, weak computers (using h264): https://www.mediafire.com/file/olbadgp55gzn6aj/youtube.luac/file Cheers, AstroSkipper

Thanks for your reply and hints, @jumper! Yesteday, I checked all prefs related to memory management and performance. And there are a lot. After investigating them, I adjusted my settings, and now New Moon 28 behaves better than before. When starting the browser under same condition as before, the palemoon.exe process decreases its RAM usage from 184 MB to 139 MB. And after surfing some sites and closing their tabs, my automatic memory minimization in the background is now able to release more memory than before. But of course, that doesn’t solve the fundamental problem with browsers that run in single-process mode. But it’s a significant improvement nonetheless. My user.js is now totally optimised for my old P4 processor. Regarding your suggestion, I don't think setting browser.cache.memory to false is a good idea. My IDE hard disk is too slow for that. Although my RAM is SD-RAM, it is much faster.

Yesterday, I uploaded files to MediaFire, and the used RAM increased to over 600 MB. After closing the tab, only a very, very small amount of used RAM was freed up. @roytam1, any chance to natively improve that behaviour in New Moon 28?

Update notification! As already reported, the Root Certificates have been updated and are now from 29-04-2026. Here again a screenshot: After a long delay, I have just updated my self-created, offline Root Certificate Updaters in the section 11.2.4. Downloads related to Root Certificate Updates (in the first post of this thread). Cheers, AstroSkipper

The only real issue that all browsers in single-process mode as, for example, New Moon 28, have – and which has always been the case with every version of Firefox – is their inability to free up RAM when tabs are unloaded or closed. The amount of memory that is actually released is pitiful compared to the amount that was originally used. It’s a problem that has remained unresolved since the very beginning, so to speak. And these days, developers no longer worry about wasting RAM, because most of them have plenty of it. But my Windows XP computer doesn't. What is particularly pleasing, however, is that GitHub has been running smoothly in New Moon 28 for some time now and, as far as I can tell, is actually running very well at the moment.

Here's a quick status update on New Moon 28 (32-bit) (2026-06-04) - the current release - under Windows XP running on a single-core 32-bit P4 with 1.5 GB of RAM. I have installed 25 extensions in my profile, 23 of which are enabled, 17 UC.JS scripts, 1 UC.XUL script, 4 USER.JS scripts, and 4 CSS stylesheets. When I launch the browser, it uses 184 MB of RAM, and it takes only a few seconds to load. My browser console shows no errors when the browser starts. If error messages appear, they are caused by websites. The reason for this is that New Moon 28 runs smoothly out of the box – at least as far as the browser console is concerned, thanks to @roytam1 – and I wrote my UC.JS scripts on the premise of running completely error-free. And regarding extensions I either fixed faulty ones myself or, if unfixable, I removed them.

It's good to hear you're doing well. Have you managed to sort out the GitHub issue?

Ok. Thanks!

This is the closed, archived repository of the original uBlock Origin Legacy: https://github.com/gorhill/uBlock-for-firefox-legacy There, you can clearly see that there are no recent patches or updates for it. No more development. @UCyborg started to port patches from the webextension to the legacy version https://github.com/UCyborg/uBlock-for-firefox-legacy. But with long delays in development. His last version is nearly one year ago. And as I already reported, I noticed incompatibilities and higher resource usage when using his version. So, as long as my version is running without any issues, I won’t be making any changes or updates. And if I do, it will only be to the assets, i.e. the filter lists if there are issues. Be that as it may, @Monroe, @Amigafever and @Rod Steel, I'm still pleased to see that there is interest in my uBlick Origin Legacy build.

My main focus was on fixing all the obvious errors caused by a completely outdated XPI file and its incompatibility with the new format of the assets file. That is why I also changed the uBO ID in my version and created my own assets file. As I already said, it’s not easy to implement patches, and that also includes security patches, in legacy extensions that were actually developed for webextensions. So, if you are more interested in security patches of uBO itself, you should use @UCyborg's version and wait for the most recent ones if they are ever implemented. But if you are rather interested in compatibilty and better performance, you should use my version. So it’s entirely up to you.

Everything I reported earlier is already old news. The error has been back in full force for almost a week now. Views are no longer being counted at all. For example:

The @AstroSkipper version is still working. I created it back when nobody was maintaining the legacy version of uBO anymore. This had led to @UCyborg also working on an updated version again. I tested it for a while and actually think any further development is a good thing, but unfortunately I found incompatibilities and higher resource usage. That’s why I’ve gone back to my version. In my opinion, it’s not easy to implement features in legacy extensions that were actually developed for webextensions.

Yes, I used eTools.ch for a while too. But it produced the same rubbish as Google, as it seems to be using Google’s data. I’ve deleted it from my list of search engines.

I’m sorry to hear that, of course. I can well understand how you feel. To put it mildly, I’m not doing too well myself, personally and privately. Especially when it comes to health. I know exactly what you mean. I’m a one-man band in everything I do, too. To be honest, your personal life comes first. So the decision is entirely up to you. Thanks, but I'll decide that for myself. Have a nice night, too!

Since the administrator @xper apparently does not feel it necessary to officially thank his members for their active participation in providing data that led to a precise theory, on the basis of which it was possible to prove the infection of the MSFN server, I shall do so here. @EliraFriesnan, @roytam1, @NotHereToPlayGames, @Ben Markson, @modnar, @deomsh and @nicolaasjan. Thank you for your confirmations with search engine results you generated from all over the world! That was a real community effort at its very best. And since my ‘cloaking’ theory https://msfn.org/board/topic/187801-msfn-and-its-lack-of-search-results-in-google-bing-and-all-search-engines-depending-on-them/page/5/#findComment-1287780, which, although based on many facts, remains a theory until it has been subjected to rigorous, unequivocal and, above all, empirical verification, I would like to once again express my sincere thanks to @nicolaasjan for his clever experiment and for highlighting the malware infestation in this post: https://msfn.org/board/topic/187801-msfn-and-its-lack-of-search-results-in-google-bing-and-all-search-engines-depending-on-them/page/5/#findComment-1287787. This made the culprit clearly visible and made it impossible to continue ignoring or denying an infection of the MSFN server. In mathematics, this signifies the end of a proof, i.e. q.e.d. And that is the most important thing for me. Cleaning it up was then just a formality and, really, a piece of cake for someone with experience, if you already know exactly what you’re looking for and have been given all the necessary information. Unfortunately, it will now take many weeks for MSFN to recover in the Google index. Not to mention the disastrous drop in the rankings of all MSFN threads.

I don't mind a typo. I don't think @VistaLover owns a time machine either :

I don’t need to stroke my ego. I don’t need to do that, as I know exactly what I’m capable of. But it was simply a reminder of all the hard work I’ve put in since 21 May – work for which any expert would be paid, but which I’ve, of course, offered to the forum free of charge. Your comment is therefore inappropriate and unnecessary.

eagyspider webshell? I think you meant EasySpider webshell, didn't you? As I have never heard or read anything about eagyspider. EasySpider Malware: Type: Backdoor / SEO Spam Injector Infection class: Cross-Site Contamination (as it has been carried over from WordPress to the forum) Mechanism: Dynamic Cloaking & User-Agent Sniffing In any case, a form of "Cloaking" as I predicted here in this thread last Saturday https://msfn.org/board/topic/187801-msfn-and-its-lack-of-search-results-in-google-bing-and-all-search-engines-depending-on-them/page/3/#findComment-1287744 and finally last Sunday https://msfn.org/board/topic/187801-msfn-and-its-lack-of-search-results-in-google-bing-and-all-search-engines-depending-on-them/page/5/#findComment-1287780 So, good to see that you've found it. And that you have already started to delete some of these thousands of fake or sniffer accounts I mentioned here: https://msfn.org/board/topic/187801-msfn-and-its-lack-of-search-results-in-google-bing-and-all-search-engines-depending-on-them/page/8/#findComment-1287893 In any case, I'm glad this thread has served its purpose and that everything turned out well.

Works in Mypal 78, but not in New Moon 28 and Serpent 52. The reason lies in this poorly written function performDownload (line 26, column 119) within the download.js script on the sooftware.com server: function performDownload(num) { event.preventDefault(); ... Strictly speaking, of course, the variable `event` (line 26, column 140) is not defined that way. But Mypal 78 and Supermium seem to be able to handle it. The function performDownload should actually have been constructed this way: function performDownload(event,num) { event.preventDefault(); ... New Moon 28 and Serpent 52 are very sensitive to things like that.

As already mentioned, the next problem I have investigated is the large number of 0-post accounts without any activity created up until 16 January 2026 and one from today. It must be thousands as far as I could see. These were created automatically using a script or other methods over the last years. Maybe, some of them are genuine but most of them aren't. A key indicator for those accounts is whether they have never been visited or only once when creating. Fake accounts, or so-called ‘sleeper’ accounts, could be all those where it says: ‘Last visited: Never’ or ‘Last visited: [Date of creation]’ if looking into them. A genuine account is usually visited in the moment of creation and later from time to time. Real, new members set up all necessary things and take a look into their accounts. Anyway, those accounts are the ‘sleeper cells’ of the attack. They were not used to carry out the infection itself (the malicious code was introduced onto the server via a security vulnerability), but serve as infrastructure to make the spam appear legitimate to Google. Here are two typical examples – accounts that really stand out because of their names and status ‘Last visited: Never’ which does not make any sense at all : 1. Building ‘domain trust’ (initial trust) Large forums such as MSFN have safeguards in place against brand-new accounts. If a bot registers today and immediately posts 50 links, the system raises the alarm and blocks it. Attackers therefore use automated scripts to register thousands of accounts in advance and simply leave them dormant for months. To the forum software (and to Google), the account ages. An account that has existed since “January 2026” will enjoy much greater trust in June 2026 than an account that is only 5 minutes old. 2. The profile spam method (hidden profile links) This is probably the most common use case: every forum member has their own profile page (msfn.org/board/profile/XXXXX-username). A normal user fills in their biography there. A spam bot uses the ‘Website’, ‘About me’ or ‘Signature’ fields to insert Thai keywords and casino links there. The key point: as these accounts have 0 posts, they never appear in active threads. No moderator and no member ever sees them in normal forum activity. But for the Google bot, these profile URLs do exist! The malicious code on the server (our cloaking parasite) now ensures that it feeds the Google bot internal lists of all registered profiles. Google crawls these profile pages, finds the Thai links and indexes them. 3. Exploitation of internal messaging systems (PM spam) or hidden drafts Some sophisticated forum bots use dormant accounts to send spam messages (PMs) to other members in the background (which would, of course, have been noticed), or they create hundreds of posts in the ‘Drafts’ section. These drafts are never published, but exist as data fragments in the database. If the server-side malicious script specifically accesses these tables, it can trick the Google bot into believing that this content is public. 4. Why did the wave of registrations come to an end in January 2026? The fact that no further accounts of this kind were created after January 2026 suggests two possible scenarios: 4.1. The loophole was (unintentionally) closed: The administrators may have installed an update to the forum software in January, for example, blocked registration for certain IP ranges or email providers. 4.2. The quota was full: By January, the attackers had generated enough ‘sleeper’ accounts to run their campaign for 2026 and withdrew the registration bots, as the accounts now simply had to ‘mature’. These accounts are used for what is known as profile injection spam. They do not harm the forum database itself, but they serve as a ‘host’ for the hidden links that the server parasite then sends exclusively to Google. For the administrator @xper, this means: not only he has to delete the malicious code, but he must also use a simple database command (SQL) to completely eliminate all accounts with 0 posts that were created over the last years and never visited or visited on the date of creation only, or contain dubious links in their profiles. Or much better, delete them all if there is no genuine activity, as they are then superfluous anyway, apparently not needed and pose a potential risk.

And to complete the puzzle, there’s still one key piece missing. And that’s the 0-post accounts, which were created in large numbers during a specific period, or periodically, or stand out because of their name or other unusual characteristics. I’m currently looking into this in more detail, as far as I am able, and trying to identify any obvious connections.

There is a significant difference compared to February. We have proven here, unequivocally and beyond any doubt – with mathematical precision, so to speak – that the MSFN server has been compromised by malicious code. This can no longer be denied. Any attempt to deny this would be embarrassing and would call into question the server operator’s technical competence. And it is, of course, perfectly clear that the infection was already present in February and that @LoneCrusader was already seeing it at that time: It could therefore have been nipped in the bud back in February, had it been investigated professionally, deeply and thoroughly. That is very regrettable and is completely beyond my comprehension.

I have most installers in my archive. But try first this site: https://panda-free-antivirus.sooftware.com/windows/download/401339

@nicolaasjan This is an attempt to explain what happens when the contaminated MSFN server meets other search engine bots than Googlebot or bingbot. For everyone else, it refers to @nicolaasjan's test and observation: Why alternative bots (like MojeekBot) trigger the "Welcome Loading ..." freeze 1. The mechanics of the attack: The server-side user agent sniffer The malware installed on the server uses a conditional script (usually written in PHP within core files like index.php or .htaccess rewrites). This script scans the incoming request for specific keywords in the User-Agent string to determine whether to serve the clean forum to a human user or the spam payload to a search engine. 2. The Googlebot trigger vs. the MojeekBot catch-all fault With Googlebot: The malware has a fully defined template. When it detects Googlebot, it successfully injects the hidden HTML container containing the Thai spam, links, and keywords, allowing the page to render fully for the crawler. With MojeekBot (and potentially other secondary search bots): The malware's sniffing routine recognizes the word Bot or Bot/ (via a regular expression or wildcard check like *bot*), flagging it as a search engine. However, the malware's backend does not have a valid spam-template or correct database-routing configured for this specific bot identifier. 3. The cause of the freeze: Broken Document Object Model (DOM) & JavaScript execution The string "Welcome Loading ..." is part of the forum’s native lazy-loading or initialization layout (often used during the initial handshaking phase between the server and the browser's JavaScript engine). When MojeekBot hits the server, the malware triggers, intercepts the request, but then crashes or terminates prematurely (e.g., throwing a silent PHP Fatal Error or an unhandled exception because the variable for the payload is empty or undefined). The backend script crashes mid-execution: It completely fails to fetch and load the actual forum database content (the threads, posts, and UI). It leaves the HTML document incomplete and broken, trapping the page forever in the initial "Welcome Loading..." state. This observation proves that the infection is not a static HTML injection into old threads, but an active, dynamic routing script on the server. It intercepts all automated crawlers based on a broad User-Agent filter, but breaks completely when encountering bots it wasn't explicitly optimized for (like Mojeek). To fix this, the administrator @xper or supervisor @Tripredacus needs to look for malicious conditional statements filtering user agent keywords inside the server configuration or core PHP initialization scripts.