Extract additional playlist page type & related video link

[imrehg]

From your comments on the previous version of this pull:

Er... wait a second. These are a few more changes. The thing is a playlist can be given in grid or play format. If you go to
http://www.youtube.com/user/stanforduniversity#g/c/9D558D49CA734A02
And click on the button that has a play sign in the bar with "All Uploads Favorites Playlists", the list changes to a different format, and the URL changes to
http://www.youtube.com/user/stanforduniversity#p/c/9D558D49CA734A02
Which is what I was trying to handle when I suggested you the previous change.

My bad, I missed it somehow, now it is done properly.

Now, if you click on any video from the playlist, the URL turns to the form you describe here, but it's not worth handling all that and, in case of handling it, we should handle that URL form from the YoutubeIE, not from the playlist InfoExtractor, IMHO. In any case, we're not going to handle the specific video URL for now. If a user wants to download one specific video, say
http://www.youtube.com/user/stanforduniversity#p/c/9D558D49CA734A02/1/jTSvthW34GU
They can simply copy the video id from the address bar, or copy the video URL from the list to the right of the video. You see the current video you're watching is highlighted. If you right click on its link and copy the URL (Copy Link Location in Firefox), you get
http://www.youtube.com/watch?v=jTSvthW34GU
Which you can pass directly to youtube-dl, so it's a non-issue for now. Maybe we'll handle that type of URL properly, but that will be later. So let's get back to your simple change, made the small modification and be done with it for now. :)

I want to be done with this as well. :) As for the copy/paste: the very reason why I'm trying to write this code so I don't have to do that ever again.

How about a middle road? This patch handles all three formats - for now. Incorporate it at the moment and open an issue about doing it properly. I would feel weird if there is a known case that the code could understand but instead breaks on it, which would be the case if the single video link is not explicitly handled.

As I tried, if I remove the single video special case and pass it the third kind of link, it would start downloading the "newest videos" or something like that (completely unrelated to the original video/playlist), so wouldn't even malfunction properly but unexpectedly from the user's point of view. The check to make it fail the right way (as I can see) would look exactly like this patch, just returning with some excuse instead of the single video download...

What do you think? :)

[rg3]

I felt the code was getting too complex and did it myself. Check the latest commit in my master branch.