Skip to content
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

Pad %(playlist_index)s with zeroes 2 #5185

Closed
Romain-Revel opened this issue Mar 12, 2015 · 5 comments
Closed

Pad %(playlist_index)s with zeroes 2 #5185

Romain-Revel opened this issue Mar 12, 2015 · 5 comments

Comments

@Romain-Revel
Copy link

@Romain-Revel Romain-Revel commented Mar 12, 2015

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

@yan12125
Copy link
Collaborator

@yan12125 yan12125 commented Mar 12, 2015

FYI, not related to this issue: 2015.03.09 is out

@Romain-Revel
Copy link
Author

@Romain-Revel Romain-Revel commented Mar 12, 2015

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):
youtube-dl --get-filename --playlist-start 22 -o "%(playlist)s - %(playlist_index)s - %(title)s.%(ext)s" https://www.youtube.com/playlist?list=PLE30F9d9cZayucP7UqdO37kjo3gtf989s
youtube-dl --get-filename --playlist-start 23 -o "%(playlist)s - %(playlist_index)s - %(title)s.%(ext)s" https://www.youtube.com/playlist?list=PLE30F9d9cZayucP7UqdO37kjo3gtf989s

@jaimeMF
Copy link
Collaborator

@jaimeMF jaimeMF commented Mar 12, 2015

Instead of deciding automatically how many zeros to use, we could just allow in the output template %(playlist_index)04d, which would produce 000x.

@dorry2015
Copy link

@dorry2015 dorry2015 commented Dec 4, 2015

download the source and open file "youtube_dl\YoutubeDL.py"
find function def prepare_filename(self, info_dict)
find line template_dict['playlist_index'] = '%0*d' % (len(str(template_dict['n_entries'])), template_dict['playlist_index'])

add code template_dict['playlist_index'] = template_dict['playlist_index'].zfill(2) after the line
and the result filename will be 01xxx,02xxx,03xxx,you can change the zfill parameter what you want

@Moredread
Copy link

@Moredread Moredread commented Jun 27, 2016

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 %0*s syntax of python2. I guess we still have to do some manual parsing to find out if we should autopad when %(playlist_index)s is used.

@dstftw dstftw closed this Feb 23, 2017
@ytdl-org ytdl-org deleted a comment from jxu Feb 25, 2020
@ytdl-org ytdl-org locked and limited conversation to collaborators Feb 25, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
6 participants
You can’t perform that action at this time.