The "playlist_prefix" parameter was missing when parsing playlist urls
that match the recently added format, e.g.:
http://www.youtube.com/user/stanforduniversity#g/c/9D558D49CA734A02
For these URLs (basically, for every playlist type so far, except the
artist list) playlist_prefix has to be equal to "p" for correct
exctraction.
Artist playlist pages have different format compared to user playlists,
thus more format checking is needed to construct the correct URL.
From the artist playlist this method downloads all listed below the
"Videos by [Artist Name]" header, plus usually there's one more
video on the side, titled "Youtube Mix for [Artist Name]", which
has a link format that currently cannot be distinguished from the other
videos in the list.
This file stamp setting is very relaxed. If there's any problem
along the way (no last-modified header, bad time string format,
no time set privileges,...) or if nothing is downloaded (e.g. using
resumed download but the file was already complete) then nothing
is done.
When using youtube-dl within scripts, it is very useful to know
what will be the final output filename with all the title settings and
filename templates applied. Add option to the quiet mode operations
to print that info.
For this I had to move the filename-generation into its own function.
As much as I can tell it should work almost always well, ie. not to
break things if one not actually interested in the title, like in
case of other forced printing. That is, unless there's an invalid
system charset or the user specified a wrong output template. In that
case probably could be assumed that the user does have a problem
(the former) or did want to mess with the filename (the latter).
Signed-off-by: Gergely Imreh <imrehg@gmail.com>
Following error happen while at the end of _do_download called try_rename
WindowsError: [Error 32] The process cannot access the file because it is being used by another process
Fixed several problems courtesy of jamiejones:
The parsing for the SWF url was wrong (the "//" are now escaped and the
initial .*match needs to be 'ungreedy'), so the -W setting to rtmpdump
was not set, causing the decryption of the video to be wrong.
Finally, add "&has_verified=1" to the fetch of the HMTL page to
allow fetching of age-restricted videos.
