YT-DLP: a new problem

The YT-DLP_2024/08/01-1 upgrade worked fine here for a couple of days, but yesterday a new error message consistently terminated the launch process before the clip played, whether mplayer or ffplay was selected as the player:
“ERROR: [youtube] vRlpemLBh6I: Requested format is not available. Use —list-formats for a list of available formats”. I’m using 18 (360p) as the default format.

Has anyone else encountered this after upgrading?

Hi George,

Yes getting the same error problem as you now and though mplayer launches nothing plays.

The youtube goal posts have moved again.

New version here.

Just drop onto the PackMan iconbar icon after deleting the existing yt_dlp folder in !Boot.Resources.!PythonSite38.Site-Packages.

*yt-dlp --version
2024.08.06

Hi Chris,

Thanks for the quick update which has cured the issue here.

Google must be upset about their recent court case :-)

Google must be upset about their recent court case :-)

Which one? ;)

New version here.

FWIW, don’t try accessing Chris’s updated file using Netsurf on RO: the resulting download will not work for some reason, if my experience is any guide. Downloading via Iris on RO, or Firefox on a PC will result in a usable zip file OTOH – I haven’t tested any other non-RO platform.

PS: and thanks to Chris G from me too!

the resulting download will not work for some reason

Will not work how?

Downloads (to RAMdisc) and extracts (ditto) just fine with NetSurf 3.11/5312 (what’s on this machine).

Can’t run it, don’t have Python.

Will not work how?

Instead of initiating the upgrade dialogue when dropped on the PackMan icon, the (Netsurf) downloaded zip triggers a Find Components/Installed File dialogue box offering three options, none of which work, i.e. the file for installation is not found. Don’t ask me why this happens as I have no idea, but it /has/ happened identically with both of Chris’s recent upgrades when downloading via Netsurf. I’m happy to leave it to more knowledgeable persons to discover the reasons if they feel so inclined. The download procedure works fine using Iris on RISC OS, so it is not mandatory to use an alien platform.

PS.: this is the first time I’ve had any problem with Netsurf downloads; they normally behave exactly as they should.

Something looks to be corrupting the zip file. Have you got DiscKnight to check your drive for errors.

but it /has/ happened identically with both of Chris’s recent upgrades when downloading via Netsurf.

Can you download the archive with each browser and diff them against each other?

I don’t understand why the archive, as offered, would behave differently within Packman, yet doesn’t get faulted as a broken archive or somesuch. It ought to be downloading the exact same thing.

triggers a Find Components/Installed File dialogue box offering three options, none of which work

I get a Package configuration dialogue, it looks like it wants to make 12 downloads totalling 21MB in order to correctly install this. But, then, I have no installed it prior.

Something looks to be corrupting the zip file.

Shouldn’t PackMan say so?

Have you got DiscKnight to check your drive for errors.

DiskKnight reports Disc Good. In any case, I was downloading to RAM.

Can you download the archive with each browser and diff them against each other?

All three freshly-downloaded options (Netsurf/RO, Iris/RO, Firefox/PC) produce identical counts, 2,955,326 bytes. And when I retested all three this morning they all produced a valid response: ‘Version YT-DLP_2024/08/06_1 is already installed’. So in short, the issue has not proved to be reproducible, and my earlier comment re Netsurf is therefore not valid.

PS: I also tried unzipping the three test downloads; all worked using SparkFS 1.46: previously both Netsurf YT-DLP update downloads had failed to open. They were clearly corrupted, but I have no idea how or why.

I was downloading to RAM.

When you start a download using NetSurf it initially creates a temporary file in !Scrap until you drag the icon somewhere else to save it.

Also. When you drag a file that isn’t recognised as a PackMan package PackMan opens a find dialogue to be able to search for where the file is installed.

So basically what happened was the file was so badly corrupted that PackMan didn’t recognise it as a Package so opened the search dialogue.

Thanks for clarifying, Chris.