Downloading youtube videos named by playlist position

[Outer-Guy]

Is your question related to a problem? Please describe. When trying to download videos from a playlist. I want to place them in a folder with the name of the playlist and put the playlist index in front of the name, but putting _%(playlist)s/%(playlist_index)s-%(title)s.%(ext)s_ returns a - the name of the video and the extension. It doesnt create a folder nor does it number the videos

Describe the question you have. For what i understand, this is possible when not using the gui, but i would really prefer to use it. ¿Is there a way to do this and im stupid? or ¿Is there a workaround?

Additional context By looking at the link of the video on the list that the application creates, i think it could have to do with the app separating the playlist in independent videos, and separating them from the playlist. This is the link i put this is an example of the link that the app gives on information, it doesn´t have the playlist.

Update After trying copying a single video from a playlist with the playlist link and index of the video, it still didn´t download with a correct folder and name, although the link from the app was correct

[StefanLobbenmeier]

Just to clarify, you are looking for a way to use the -o option documented here in the gui? https://github.com/yt-dlp/yt-dlp#output-template

If yes, can you just confirm that the template works with the youtube-dlp cli?

[StefanLobbenmeier]

Should work in principle: https://github.com/StefanLobbenmeier/youtube-dl-gui/blob/ad64f9f3e0f2b2f8eabbc6bd9715c2e845fb604a/modules/download/DownloadQuery.js#L97

[StefanLobbenmeier]

Ok I think I understood, the issue is that the playlist metadata is not replaced in the -o option

Probably this is caused because the open video downloader does not actually tell yt-dlp to download the whole playlist, but first makes it fetch the playlist and then downloads the individual videos. So that information is lost on the way. I am not sure if we can manually replace the metadata, this would require some research.

This also causes the folder not to be created - the empty foldername is ignored. It your case I would expect a folder to be created though since you put an underscore in front.

In my case that also worked with your -o option:

[download] Destination: C:\Users\Stefan\Downloads_-Blinding Heartbeat - Uzaki-chan vs. The Weeknd.mp4_.f137.mp4

[Outer-Guy]

Thanks for your fast response! Yes, that´s exactly the problem and what i would like it to do

Probably this is caused because the open video downloader does not actually tell yt-dlp to download the whole playlist, but first makes it fetch the playlist and then downloads the individual videos. So that information is lost on the way. I am not sure if we can manually replace the metadata, this would require some research.

This also causes the folder not to be created - the empty foldername is ignored. It your case I would expect a folder to be created though since you put an underscore in front.

I think i put the underscore by mistake, but yes, it fetches the playlist and sends the individual videos so it loses the playlist information. I don´t know how hard it could be to implement, but i think it would be a nice feature to have.

[StefanLobbenmeier]

Sorry Took me some time to realise, but there might be a setting for it: https://github.com/StefanLobbenmeier/youtube-dl-gui/wiki/Settings#split-playlists-into-separate-videos

if we don’t split the playlist (select „never“) and let yt-dlp handle the playlist, then those playlist metadata should be available. Could you give it a try?

[Outer-Guy]

I think that only changes how the video is displayed on the GUI because when downloading the videos it doesn´t put the playlist name on the downloaded file This is the file format : %(playlist_title)s/%(playlist_index)s.%(title).200s.%(ext)s the file format omits the playlist information the wiki information says that the option to not separate playlists is for performance's sake.

[StefanLobbenmeier]

Hmm Strange, I’ll take another look at the implementation, but this should be where we fix it the easiest way.