Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.
Sign upGitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
Pad %(playlist_index)s with zeroes 2 #5185
Comments
|
FYI, not related to this issue: 2015.03.09 is out |
|
I've just tested with version 2015.03.09, and there is still the same problem. Try the 2 following commands (provided there are still 121 vidéos in the palylist and not any new one): |
|
Instead of deciding automatically how many zeros to use, we could just allow in the output template |
|
download the source and open file "youtube_dl\YoutubeDL.py" add code template_dict['playlist_index'] = template_dict['playlist_index'].zfill(2) after the line |
|
I think the approach by @jaimeMF would be better than mine in #9929. The string formatting in python 3 doesn't support it directly. Do I see it correctly, that currently -o directly specifies the format string used, without modification? I guess we'd have to parse it ourselves, or does someone have an idea how that can be done in a better way? Edit: I just noticed I misread the comment, as I was thinking about supporting the |
I am reopening this issue because not fixed entirely:
#4157
(Tested with version 2015.03.03.1)
Here is a context where a padding would be useful:
I want to download this playlist https://www.youtube.com/playlist?list=PLE30F9d9cZayucP7UqdO37kjo3gtf989s
composed of 121 vidéos at the moment. So I start downloading it with a filename containing %(playlist_index)s. So this program creates the files 001, 002 ... Then there is an error, or the time is too long so I have to stop the download and restart it later with --playlist-start NUMBER. But if I use --playlist-start 22 or more, then there are less than 99 épisodes to download, so the %(playlist_index)s is written on 2 digits.
The first problem is that there is no coherence between the name of the first episodes and the last ones.
The second problem is that as I stopped the first download, it most probably stopped in the middle of the download of one episode, so when it restarts it doesn't find the .part file and starts the download of the current episode from the beginning.
It might be useful to be able to give the format in the --playlist-start in the following way:
--playlist-start 1 => file 1, 2 ... 10 ... 222 ... 99999
--playlist-start 01 => file 01, 02 ... 10 ... 222 ... 99999
--playlist-start 001 => file 001, 002 ... 010 ... 222 ... 99999