Euro20179
commented
1 year ago You could try using --thumbnail-quality=hqdefault, however using high works for me.
Open kevenwyld opened 1 year ago
Euro20179
commented
1 year ago You could try using --thumbnail-quality=hqdefault, however using high works for me.
kevenwyld
commented
1 year ago Could it be that this was a misunderstanding of the supported thumbnail types in invidious? There is no high url, but the name of the high thumbnail is hqdefault here: https://github.com/iv-org/invidious/blob/6837e4292829ee0891c73108096b806b63ab1506/src/invidious/videos.cr#L425
I've tried every instance I can find and none of them return anything for https://
This makes me think the default quality should be hqdefault instead of high. But I'll gladly admit that I don't have a complete understanding of this codebase and could be completely wrong =] .
Also I can reproduce this very consistently with ytfzf --thumbnail-quality=high -t -f -c SI
Euro20179
commented
1 year ago tbh, high works for me 99% of the time, if this becomes a bigger issue i'll change the default to hqdefault. In the meantime, i'd suggest added thumbnail_quality=hqdefault to your config file.
edit:
Im kinda dumb, I didn't realize this only really affects subscriptions for some reason, and when scraping SI this bug appears a lot more often for me.
kevenwyld
commented
1 year ago I think it's because scrape_SI... or maybe scrape_subscriptions doesn't call _get_invidious_thumb_quality_name but the other functions like scrape_invidious_playlist do?
You are converting high to hqdefault in that function but without it the thumbnail_quality variable is just high which is what's being passed to invidious in the url as far as I can tell.
_get_invidious_thumb_quality_name () {
case "$thumbnail_quality" in
high) thumbnail_quality="hqdefault" ;;
medium) thumbnail_quality="mqdefault" ;;
start) thumbnail_quality="1" ;;
middle) thumbnail_quality="2" ;;
end) thumbnail_quality="3" ;;
esac
}PS. I have no idea how you stay organized in a 3565 line long file.... And also sorry if I'm way off here.
EDIT: I tried adding _get_invidious_thumb_quality_name to the scrape_SI function and it seems to have fixed it. Though not sure if that's the best solution.
Euro20179
commented
1 year ago I have no idea how you stay organized in a 3565 line long file
Its hard lol.
I think it's because scrape_SI... or maybe scrape_subscriptions doesn't call _get_invidious_thumb_quality_name
I think you're right. I will add this patch when I get home. I believe adding the function call is the best solution, but it might be better if it gets called automatically somewhere.
Euro20179
commented
1 year ago This should now be fixed in the development branch.
kevenwyld
commented
1 year ago Thanks! Just tested and it's working great now.
Describe the bug
When running
ytfzf -t -f -c SIthumbnails are not downloaded and some curl 404 errors go to stderr:To Reproduce
run ytfzf -t -f -c SI with the following subscriptions file:
Expected behavior
Thumbnails similar to those displayed when using the
invidious-channelfeatureScreenshots
Information
alacrittyytfzf: 2.5.5(from aurytfzf-git r1963.ac4cc79-1)ls -l "$(which sh)"(if you're using fish:ls -l (which sh)):lrwxrwxrwx 1 root root 4 Jan 8 2022 /usr/sbin/sh -> bash*ytfzf --thumbnail-log=log.txtand post the file: The file is emptyAdditional context
I did some testing using
bash -xto get debug output. Here's download log output from a working invidious-channel scrape:and here's one from a not working
-cSIscrape against my subscriptions file:I tried downloading the image from both.
https://invidious.baczek.me/vi/1qtg1z5V1ss/hqdefault.jpgcontains an image whilehttps://invidious.baczek.me/vi/1qtg1z5V1ss/high.jpgdoes not. Though I cant figure out why the two types of scrapes request different quality images. I think this may not be related though since neither URL is a 404. I hope this is helpful though.This is the only place thumbnails are broken for me. They work with all other searches and scrapes.
Thanks!