-
Notifications
You must be signed in to change notification settings - Fork 367
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: youtube: Polymer UI and JSON endpoints for playlists #151
RFC: youtube: Polymer UI and JSON endpoints for playlists #151
Conversation
We already had a few copies of Polymer-style pagination handling logic for certain circumstances, but now we're forced into using it for all playlists since we can no longer disable Polymer. Refactor the logic to move it to the parent class for all entry lists (including e.g. search results, feeds, and list of playlists), and generify a bit to cover the child classes' use cases.
So far this is not tested for many use cases, including ones that we know will be affected (search, feeds, list of playlists). I've only tested it for downloading all of a channel's uploaded videos. |
Will test this fix with these IDs: We now have two fixes released almost at the same time |
See also #150 (edit: some already have while I was typing this, apparently) which appears to be doing essentially the same thing. There's a few things it does better than this one, including noticing that the base extractor already has a |
@wlritchi doesn't work with
|
Ah, yup, that's definitely an artifact left over from refactoring. I had intended to let search just process the initial data without requesting any further pages (which I think matches what it did before), but specifying the number of pages to fetch is probably more useful. I think your change as presented above will cap all playlist downloads to the first page, though. |
yup you are right. Haven't thought about it lol. |
Also drop a few leftover methods in search that are no longer used.
Basically doing this except defaulting to None, and adjusting the counting so it always starts from 1 (convention: page 0 is the initial page and continuations start from 1). This way 0 can be passed to say "only download the initial page with no continuations". Also open to tweaking the counting so the initial page counts as page 1. |
Oh, hmm, search with 0 continuations returns nothing. I thought it would be the first page of results. |
that's why |
Oh I see, YoutubeSearchIE has its own implementation of |
i set it to 5 now. If you plan any more changes hold on for now. Will merge this into master and release it. really have to sleep, can barely keep my eyes open :o |
👍 I'll put anything else on a separate branch since it's more maintenance/refactoring than bugfixing anyway. While I'm at it - thoughts on whether the initial page should be page 0, or page 1 (i.e. do most users prefer 0-based or 1-based indexing)? |
I prefer 0-based index at least, but I'm a programmer, so maybe not very representative. I don't think that there is anything paginated with page numbers left on YouTube, but if there was, it would likely start at 1. Things like "--playlist-start" are already 1-based. |
If things like --playlist-start are already 1 based then it should start at 1. |
@blackjack4494 There is a bug in here. Playlist title for the output format is not set correct and is always NA |
Before submitting a pull request make sure you have:
In order to be accepted and merged into youtube-dl each piece of code must be in public domain or released under Unlicense. Check one of the following options:
What is the purpose of your pull request?
Description of your pull request and other information
We already had a few copies of Polymer-style pagination handling logic for certain circumstances, but now we're forced into using it for all playlists since we can no longer disable Polymer. Refactor the logic to move it to the parent class for all entry lists (including e.g. search results, feeds, and list of playlists), and generify a bit to cover the child classes' use cases.
Fixes #148.