For example, this invidious instance offers a download option for a YoutTube video, as that instance does for all YT videos:
~~https://invidious.fdn.fr/watch?v=lU4vv7qCQvg~~ (see update)
Exceptionally, if you opt to download it it merely opens a player to watch realtime. While other downloads from the same invidious instance have no issues. Why is this one getting different treatment?
update Apparently it’s an instance-specific problem with that particular video:
works → https://invidious.fdn.fr/watch?v=lU4vv7qCQvg
broken → https://iv.ggtyler.dev/watch?v=lU4vv7qCQvg
I’ve seen other instances where this particular video download is broken. AFAIK, invidious.fdn.fr is the only place where it works as expected.
This is your browser handling the content disposition wrongly.
Why would a browser handle it incorrectly for one video on one invidious instance, but not for most other videos and other instances?
Note that I’ve seen this broken behavior both in my own Chromium installation as well as Firefox in Windows as a public library.
There are a few reasons this might be the case!
-
The instance’s UI might not be declaring that
aorbuttonelement as a resource meant to be downloaded. -
The instance’s web server might not have declared the downloadable file’s mime type as a resource. (Apache, nginx.)
-
Your operating system might not recognize the file type as a thing to be downloaded, or your browser isn’t telling it to download to a file.
It’s probably 1 or 2 if you’re seeing the same behavior across multiple browsers and OS.
-
yt-dlp works fine.
I tried downloading from the link provided and it started downloading the file for me.
Thanks for pointing that out. It works for me too. I just happened to select a different instance where it actually works. Here’s the instance where it’s broken:
Try right clicking and “save as”? On mobile Safari it pops up with view and download as options.
That’s is how I got around it in the past. For some reason that was not an option where I needed it (perhaps the browser I was using was locked down in some way). In any case, I’m wondering why the variation in behavior. Is this a bug in Invidious?
Still downloading the file for me.
Edit: Tried it in chromium out of curiousity and I was able to reproduce your issue. Not sure why it works normally in firefox.
Ungoogled Chromium indeed reproduces the issue. But so does the public library, which likely was Firefox in Windows. So i guess it might be hasty to conclude that it’s browser specific, particularly when other videos on the same instance behave differently in the same browser.
New Lemmy Post: When /some/ YT videos get special download-resistent treatment but not others (https://lemmy.dbzer0.com/post/9558043)
Tagging: #Piracy(Replying in the OP of this thread (NOT THIS BOT!) will appear as a comment in the lemmy discussion.)
I am a FOSS bot. Check my README: https://github.com/db0/lemmy-tagginator/blob/main/README.md
First time I’ve seen this bot. I would be interested in learning how to cross-post from #kbin to #Lemmy in a way that preserves the original username the way this bot did. Is that possible without 3rd party tools? I can login to a Lemmy instance and then crosspost any Kbin thread to a Lemmy community, but then the author becomes myself, not the original Kbin author.
#askFedi
