VistaLover

https://github.com/ytdl-org/youtube-dl#video-selection --playlist-start NUMBER Playlist video to start at (default is 1) --playlist-end NUMBER Playlist video to end at (default is last) --playlist-items ITEM_SPEC Playlist video items to download. Specify indices of the videos in the playlist separated by commas like: "-- playlist-items 1,2,5,8" if you want to download videos indexed 1, 2, 5, 8 in the playlist. You can specify range: " --playlist-items 1-3,7,10-13", it will download the videos at index 1, 2, 3, 7, 10, 11, 12 and 13. ... Then make sure you have perused ALL available CLI options (aka switches) for BOTH; for youtube-dl (often abbreviated as just yt-dl), the place to start is: https://github.com/ytdl-org/youtube-dl#options FWIW, yt-dlp is a more "advanced" tool (with more complex syntax and options), that requires some additional expertise on the part of the user ; yt-dlp is not guaranteed to continue to work under XP (and Vista) after this October, when its devs drop py3.9 support (to this day, no py3.10+ fork has been made public that can run on NT 5.x/6.0 ) ....

( Happy Easter to all those who observe it ! ) New r3dfox releases have appeared on its GitHub repo : https://github.com/Eclipse-Community/r3dfox/releases/tag/v128.9.0 ... and: https://github.com/Eclipse-Community/r3dfox/releases/tag/v136.0.4 Many thanks to the maintainer! ...

FYI: https://forum.videolan.org/viewtopic.php?f=14&t=141939 https://forum.videolan.org/viewtopic.php?p=460965#p460965 https://forum.videolan.org/viewtopic.php?f=14&t=160467 The "portable" directory will be populated with below content (settings): ./vlc.exe/portable/vlc/vlc-qt-interface.ini (GUI related settings) ./vlc.exe/portable/ml.xspf (playlist) ./vlc.exe/portable/vlcrc (app related settings) The "portabilised" (nightly) VLC instance will load its settings from said "portable" folder and won't ever touch (mess with) VLC settings extant in %APPDATA% ... Regards.

... I'm well aware , so that's why you weren't quoted ...

aka & nesting selector ... Partial (or full) support is behind custom (experimental) flags on earlier versions of both browsers: Probably useful info for people still on Win7 (where Cr109/Fx115esr are the last officially supported versions) ... https://repo.palemoon.org/MoonchildProductions/UXP/issues?q=CSS&type=all&state=open doesn't display an open issue for this CSS feature under UXP ... Additionally, the footer on https://techcommunity.microsoft.com/ (as well as other content after the "Additional Help & Learning Resources" bit) isn't rendered properly (it renders as a vertical left-hand column) in UXP, possibly the same issue, too ... FWIW, "Microsoft pages" do not contain only stuff exclusive to Win11 , once the nesting selector makes its way onto other web "frameworks" and sites, the breakage on UXP browsers will become more common ...

... Not to jinx things or anything , but you better finish your tests soon ; at the rate we're going, Google have been able to "break" youtube-dl (by serving "specially" crafted JS yt-players) every other day or two ...

126-r7 spoofs v132, for better webcompat :

... Please, STOP spreading untruths! The code is there on GitHub for those willing to read it; after all, Supermium is still OPEN source (minus the wrapper DLLs, that is): https://github.com/win32ss/supermium/issues/1290#issuecomment-2764577016

... Yes, this is really insane of them ; it's not as if discourse-based forums, mostly containing text, need the top-of-the-line JS/CSS features released with "yesterday"'s Google Chrome version ... ... Mozilla have extended Win7's support with Fx115esr until September, but discourse will cut this support 4 months prior, on May 1st! I soon got bored reading the linked announcement and the comments that followed it, their basic reasoning couldn't hold water if it wanted to: (and, correct me if wrong, but "they" can't use English properly, I think "including" should've been "include"); what "improved experiences" for crying out loud? People just post questions (in plain text), sometimes they attach a screengrab, and they expect a helpful reply (also mostly in text); why discriminate against older rendering engines? https://meta.discourse.org/t/dropping-ios-15-other-old-browsers-in-may-2025/358131/33 Will have to wait and see how much "broken" UXP will be after May 1st on discourse-based forums/"communities" (quite a lot of them, actually) ... (above is St52 with the ! Discourse-based forums ||*/browser-detect-$script,important custom uBO-legacy filter...) EDIT: Discourse's browser-feature-checking script is, apparently: https://d11a6trkgmumsb.cloudfront.net/assets/chunk.e772cb6376a12f35fc11.d41d8cd9.br.js:139:266343

A Supermium enthusiast has setup a "mirror" of the original site on GitHub: https://techguy16.github.io/supermium-website/ This should serve as an "interim" solution (fetching files directly from GitHub), until the main site has been properly fully restored (file downloads and the "file directory" are NOT working currently) :

... Has come back here, as of several minutes ; the maintainer wrote: Clearing your computer's DNS cache might help, too ; the site itself is useful for people on very old browsers (e.g. Opera 12), not able to handle Microsoft's GitHub Releases section...

... Very sad development , indeed: https://github.com/win32ss/supermium/issues/1252 https://github.com/win32ss/supermium/discussions/1251 ... I'm quite sure the Supermium naysayers, several of whom frequent these forum(s) , will be now throwing parties...

@Dave-H : https://github.com/win32ss/supermium/commit/fa695faf3889deb57b1e247293c7ceee10161172 ... "Experimental" features, by their nature, do entail the probability of "breaking" some sites, so that's why they're initially launched behind disabled prefs ; this has been happening for years now; adventurous users and/or testers are encouraged to enable those features (preferably on test profiles) and report any breakage experienced either to the browser vendor or the affected site admin(s) - this is how things work; if an obscure site breaks due to such a feature but Google has been left unaware, then that "feature" will make it onto a future Chrome update; Google very seldom revert Chrome changes (unless they're about very prominent sites/services), so in that case the onus will again be on the site admins to "comply" with latest Chrome (and that is why our "legacy" browsers often break) ... Noone here or on GitHub has reported how the BG site currently behaves on latest official Google Chrome (v134), without (the default) and with the offending flag enabled ; maybe the experimental feature in M126 that breaks the site got dropped by the Google Devs, or it's still there behind a disabled pref; if it "makes it" to, say, Chrome 136 (i.e. separated from experimental features and promoted into a default, standard, feature), then BG will render broken in M136 and they will have to fix the issue themselves ... This appears to have been your strong argument both here and in GH, but allow me to say this is NOT a given ; it all depends on how an individual site has been coded; 126-r6 was released on Dec 17th, followed by 126-r7 on Jan 23rd and 132-r0 on Mar 1st; yet you were the first (unlucky?) person to report a breakage almost 3 months after r6's initial public release... Other site admins may be already "tailoring" their site's code under the hood to "foolproof" it against future Google Chrome releases (dev channel is already at version 136), so "other sites" might not break in Sm-132, even if BG currently does ... In any case, "your" issue will get hopefully fixed in Sm-v132-r1 (provided one doesn't touch the "#enable-experimental-web-platform-features" internal flag there) ... Should you wish to keep using 126-r6/r7, you know by now what to do... Cheers ...

... Might be related: https://forum.palemoon.org/viewtopic.php?f=17&t=32150 ... or not ; FWIW, it works here right now, so you may need to resort to a Europe-based VPN node, if available of course ...

... Going to: https://yd.3dyd.com/changelog/ and reading the details of v1.21: I get the distinct impression that yt-dlp is only being used for the initial discovery of available YT formats ; the actual stream downloading (including thumbnail) is delegated to/performed by curl (via "libcurl_openssl.dll") and the muxing delegated to the embedded, shared, ffmpeg module; for picture embedding to take place, either ffmpeg (if recent enough), atomicparsley (non-existent here) or yt-dlp's mutagen Python module needs to be invoked post stream (re-)mux; this is something (according to posted logs) that's not taking place right now; perhaps if the dev was made aware, (s)he could code the app accordingly... FWIW, these frontends are just being coded for the average Windows user, most of the time oblivious to the existence of the Windows Command Prompt and the way CLI apps work; trust me, I get despaired from countless GitHub issue reports, where the OP cites that "the .EXE is broken", because it only blinks and closes upon double-clicking it ...