Add an option to filter videos with less than 1000 views

[yeolsongarak]

I noticed Revanced just added this option, I didn't think it was needed at first, but I often get those random recommendations from random channels. I wouldn't mind them much but I think I'm wasting a lot of time reading the title of some video I have zero interest of it. Not sure if this is complicated to implement, because most of the videos from my subscription tab have less than 1000 views.

Thanks a lot for all the awesome features of ImprovedYoutube!

[ImprovedTube]

hi! @yeolsongarak
how is it called in re-vanced? At best you can paste the link to the feature's code.

wanna exclude <1000 or exclude the rest? == so your subscriptions are rather popular? or your subscriptions are rather personal / specific and you only want videos below 1000 in https://www.youtube.com/feed/subscriptions specifically?

check: #1451

[yeolsongarak]

Thank you for your answer. I couldn't find the specific code, but it's mentioned in the changelog of inotia's repository here:
https://github.com/inotia00/revanced-patches/releases/tag/v2.196.1

It's the 10th line, "Hide videos with low views".

wanna exclude <1000 or exclude the rest?
The purpose of this would be to filter out recommended videos with less than 1000 views in the main Youtube home page, but only those recommended by Youtube's algorithm. I personally like what I get recommended, except those low views videos.

(Btw I'm not sure if 1000 would be the best threshold for everyone, it just sounded logical to me after seeing the number of views of the videos I'm seeing)

[ImprovedTube]

hi @yeolsongarak i see! the recommendations must be more experimental then, due to lack of data for these new/unpopular videos

[ImprovedTube]

I couldn't find the specific code

surprisingly enough it only exists in one file here: https://github.com/search?q=LowViewsFilter&type=code
(also called revanced_hide_video_with_low_view in the gui). Hi @inotia00! #1881

[ImprovedTube]

To work in English, it would need to be:

www.youtube.com##ytd-browse[page-subtype="home"] span.ytd-video-meta-block:has-text(/\d+\sviews/):upward(ytd-rich-item-
renderer)

Because our user base is international, I don't want to distribute rules that assume that the display language is English, and that's why I highly discourage matching on display strings.

@xvello

• What about [\d., ]{1,4}\s\w\w\w+ ?
  • could be labeled for most languages/experimental localization
    There can be similarities between languages: https://docs.google.com/spreadsheets/d/1eMKR3WbtMTgiCmZJ7nSt5SZBGMO6r13xfjSRDWK-77c/edit#gid=959300005
    

    youtube/js&css/web-accessible/www.youtube.com/player.js

    Line 86 in bf5b569

    var musicIdentifiers = /(official|music|lyrics)[ -]video|(cover|studio|radio|album|alternate)[- ]version|soundtrack|unplugged|\bmedley\b|\blo-fi\b|\blofi\b|a(lla)? cappella|feat\.|(piano|guitar|jazz|ukulele|violin|reggae)[- ](version|cover)|karaok|backing[- ]track|instrumental|(sing|play)[- ]?along|卡拉OK|卡拉OK|الكاريوكي|караоке|カラオケ|노래방|bootleg|mashup|Radio edit|Guest (vocals|musician)|(title|opening|closing|bonus|hidden)[ -]track|live acoustic|interlude|featuring|recorded (at|live)/i;

    album|Álbum|专辑|專輯|एलबम|البوم|アルバム|альбом|앨범|mixtape|concert|playlist|\b(live|cd|vinyl|lp|ep|compilation|collection|symphony|suite|medley
  • Or one could automatically fetch every language-Version from YouTube for a long regex ( Correct full-screen text in all languages #1752 @Lauviah0622). A specific/rare feature need not save cpu-cycles. Could include all languages in one regex and be made more efficient when (if) it ever finds many users.

limitation of this project ... dedicated extension

Yes, we might come across another reason to check youtube's language sooner or later (localized set of regex), but rather much later if ever. It's efficient also to be able to apply regex in a CSS selector. (Several great features i delayed implementing because our code doesn't do that yet)

[ImprovedTube]

burden of pushing

BTW guys,

@inotia00 #1881

The typical GitHub issues takes several years to be solved if ever.
So we need ways to work together on them (#1881), rank/prioritize them & pay/bounty - or skip them (and later some might solve themselves (AI) or changes in global usage & complications) (that's why our feature request template asks to estimate/predict usage amounts) "why do you care?" @yeolsongarak @TryFIXed @Nomes77 @JohnyP36