Skip to content

add music_playlists_only#81

Open
alexanderadam wants to merge 7 commits into
philippe44:masterfrom
alexanderadam:feat/music_playlists_only
Open

add music_playlists_only#81
alexanderadam wants to merge 7 commits into
philippe44:masterfrom
alexanderadam:feat/music_playlists_only

Conversation

@alexanderadam
Copy link
Copy Markdown
Contributor

In the YouTube Music app it shows only music playlists. I don't know how they did it efficiently but here I cheated a bit and checked only for 5 items. If they're music (category 10), then we assume that it's a music playlist.

Works reasonable fast on my devices. It's an optional filter but probably useful for others too.

prep work. next commits filter My Playlists to only music ones,
like the youtube android app does.
probe the first item of each unknown playlist, check its
videoCategoryId, and only keep category 10 (Music). per-playlist
decision goes into the cache so navigating back is free.

if the video lookup fails (eg. bad api key or quota) we show all
playlists. better than silently hiding everything.
only checking the first item was too aggressive. workout playlists
with a non-music intro got hidden. now we treat a playlist as music
if any of the first 5 items is in category 10.

also skip _pagedCall for the small sample fetch, and bump the cache
key so old single-item decisions dont stick around.
without the token, playlistItems.list gets 404 playlistNotFound for
any non-public playlist. only the public ones (EDM, Konzentration,
Lounge) survived. everything else got treated as non-music.

bump the cache key again, old broken decisions still sit there for
an hour.
up to 50 playlists times 5 sampled ids each = 250 video ids. one
big videos.list call hits the api 50-id cap and 400's. the whole
batch fails so we fall back to "show all playlists", and Kochen,
3D Druck etc come back into the menu.

split into chunks of 50, fire them in parallel, merge categories
from each chunk. only treat as full failure if every chunk fails.
also add a small log line so this is easier to verify next time.
OPML level-2 only fetches one row at a given index. with the filter
on we pulled the first 50 raw playlists, filtered down to 18, then
indexed into that. position 12 ended up pointing at a different
playlist than the menu showed, so Workout opened raining tracks.
position 20 fell off the end, so 💔 looked empty.

now we ask for max_items upstream whenever the filter is on, so
the filtered set is stable no matter which index OPML is asking
for.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant