Leaderboard

Fixed.

Wise choice; and you should probably stay there, too... Based on my most recent tests, the only logical conclusion. Words of wisdom ! This kind of "wisdom" is due to the fact that newer versions are no longer tested for performance to the same extent, and certainly not on older operating systems, as everything has become very fast-paced and there is no real interest in real optimisation, given that most users have such powerful hardware that they no longer even notice such software flaws. Yep, very hot here but I think that’s nothing compared to the temperatures you usually get in Greece. Kind regards

FYI, from now on, you can find links to all my YouTube projects in the third post of this thread.

Many thanks for your tests and confirmation ; with some more free time on Saturday, I decided to explore how ALL stable VLC versions after 3.0.8 behave when fed the above audio HLS live stream; one can find older stable VLC releases in their "download" server: https://download.videolan.org/pub/videolan/vlc/ FTR, v3.0.7.1 (immediately previous to 3.0.8) behaves almost identically to 3.0.8; HLS streams (at least the demuxing part) are handled by the libadaptive_plugin.dll module; here's the CPU usage history of my Core2 Duo with ONLY VLC v3.0.8 streaming BBC R2: libadaptive_plugin.dll versions 3.0.9.2 and 3.0.10 are actually BROKEN when it comes to handling the BBC R2 HLS stream; I can hear the audio for ca. 30-40s, but then the stream turns muted (continues to play otherwise) ... From v3.0.11 onwards, the BBC R2 HLS audio stream does play consistently, but at elevated CPU consumption ; with each newer VLC release, the file size of the above DLL increases, but the CPU it uses remains constantly high; below is the CPU usage history of my Core2 Duo when ONLY VLC v3.0.23 is running, streaming BBC R2: I'm sure you can see the CPU spikes there ... If you're using yt-dlp.exe without a JS runtime (quickjs is the only option under XP SP3 x86), then the default player client there is android_vr (aka ANDR-V) and the formats it returns are ALL "https", not "m3u8" (PROTO column): yt-dlp -F "ffcitRgiNDs" [youtube] Extracting URL: ffcitRgiNDs [youtube] ffcitRgiNDs: Downloading webpage WARNING: [youtube] No supported JavaScript runtime could be found. Only deno is enabled by default; to use another runtime add --js-runtimes RUNTIME[:PATH] to your command/config. YouTube extraction without a JS runtime has been deprecated, and some formats may be missing. See https://github.com/yt-dlp/yt-dlp/wiki/EJS for details on installing one [youtube] ffcitRgiNDs: Downloading android vr player API JSON [info] Available formats for ffcitRgiNDs: ID EXT RESOLUTION FPS CH | FILESIZE TBR PROTO | VCODEC VBR ACODEC ABR ASR MORE INFO --------------------------------------------------------------------------------------------------------------- sb3 mhtml 48x27 0 | mhtml | images storyboard sb2 mhtml 80x45 1 | mhtml | images storyboard sb1 mhtml 160x90 1 | mhtml | images storyboard sb0 mhtml 320x180 1 | mhtml | images storyboard 139 m4a audio only 2 | 1.33MiB 49k https | audio only mp4a.40.5 49k 22k low, m4a_dash 249 webm audio only 2 | 1.46MiB 54k https | audio only opus 54k 48k low, webm_dash 140 m4a audio only 2 | 3.51MiB 129k https | audio only mp4a.40.2 129k 44k medium, m4a_dash 251 webm audio only 2 | 3.77MiB 139k https | audio only opus 139k 48k medium, webm_dash 160 mp4 256x144 25 | 1.46MiB 54k https | avc1.4d400c 54k video only 144p, mp4_dash 278 webm 256x144 25 | 1.79MiB 66k https | vp9 66k video only 144p, webm_dash 394 mp4 256x144 25 | 1.41MiB 52k https | av01.0.00M.08 52k video only 144p, mp4_dash 133 mp4 426x240 25 | 3.08MiB 113k https | avc1.4d4015 113k video only 240p, mp4_dash 242 webm 426x240 25 | 2.68MiB 99k https | vp9 99k video only 240p, webm_dash 395 mp4 426x240 25 | 2.53MiB 93k https | av01.0.00M.08 93k video only 240p, mp4_dash 134 mp4 640x360 25 | 5.77MiB 213k https | avc1.4d401e 213k video only 360p, mp4_dash 18 mp4 640x360 25 2 | ≈ 9.28MiB 342k https | avc1.42001E mp4a.40.2 44k 360p 243 webm 640x360 25 | 6.80MiB 251k https | vp9 251k video only 360p, webm_dash 396 mp4 640x360 25 | 4.58MiB 169k https | av01.0.01M.08 169k video only 360p, mp4_dash 135 mp4 854x480 25 | 9.80MiB 361k https | avc1.4d401e 361k video only 480p, mp4_dash 244 webm 854x480 25 | 9.37MiB 345k https | vp9 345k video only 480p, webm_dash 397 mp4 854x480 25 | 7.91MiB 292k https | av01.0.04M.08 292k video only 480p, mp4_dash 136 mp4 1280x720 25 | 18.56MiB 684k https | avc1.4d401f 684k video only 720p, mp4_dash 247 webm 1280x720 25 | 17.27MiB 636k https | vp9 636k video only 720p, webm_dash 398 mp4 1280x720 25 | 13.88MiB 511k https | av01.0.05M.08 511k video only 720p, mp4_dash 137 mp4 1920x1080 25 | 49.02MiB 1807k https | avc1.640028 1807k video only 1080p, mp4_dash 248 webm 1920x1080 25 | 30.88MiB 1138k https | vp9 1138k video only 1080p, webm_dash 399 mp4 1920x1080 25 | 24.70MiB 910k https | av01.0.08M.08 910k video only 1080p, mp4_dash I have found the elevated CPU usage (in v3.0.11+) to be specific to the HLS streaming protocol ... Wise choice; and you should probably stay there, too... Words of wisdom ! Kind regards (and protect yourself from the heatwave ... )

Thanks for this detailed info ; in case anyone wants to salvage/archive those builds: vlc-3.0.23-win32-a5b72d67 https://artifacts.videolan.org/vlc-3.0/nightly-win32/20260512-0219/ vlc-3.0.24-beta1-win32-4c608da1 https://artifacts.videolan.org/vlc-3.0/nightly-win32/20260529-0214/ It's unclear why they broke XP-compatibility in 3.0.24b1 after May 29th ; it might've been an inadvertent breakage, like they did with VLC-3.0.21, or as part of a conscious decision to drop NT 5.x support (recent 3.0.24b1 builds continue to work under Vista SP2) ; I guess very few people (especially on "legacy" WinOSes) monitor the "nightly" artifacts, so the XP-breakage, if not remedied in the meantime, will only hit the "masses" when 3.0.24 sees a final/stable release (and there's probably still time for that ) ...

TheOven has been online for months now. There was a forum software error due to an automatic update that took it down in December for a couple weeks while the owner was on holiday, but it was fixed as soon as he got back. If your referring to reboot.pro? I fear it as gone the way of 911fourms and will not return. :(

It is proving somewhat difficult to find a configuration that satisfies everyone. I have added a shared XP build that includes ffplay in the previous post.

I understand, but if someone doesn't want to, they shouldn't download the file. There are also those who use ffplay and the 'shared' version