[FEATURE] Customize folders higher up

[snab43]

Is your feature request related to a problem? Please describe. No

Describe the solution you'd like Currently when you subscribe to a channel it's hardcoded to store videos within a folder with the channel name. Some Plex agents require the uploader ID to be in the folder name as well. If I were to use the file output of %(uploader)s [%(uploader_id)s]/%(title)s [%(id)s] what I would get is channel/channel [id]/video title [id].mp4. I'd rather it not be one more level deep.

Additional context If I use the file output ../%(uploader)s [%(uploader_id)s]/%(title)s [%(id)s] it does achieve what I want, but I now just have double folders for each subscription.

I'm hoping to do the same for playlist subscriptions as well. In general the ability to customize the folder structure one level higher would be useful.

I also would find defaults per-type useful. So a default subscription format, default playlist format, and default one-off video format.

[GlassedSilver]

I agree with everything that you said.

[GlassedSilver]

Something to consider is: if the channel name changes at the source, I think we should store both names as "akas" and rely on the channel ID if available to map them together.

STORING the videos on-disk should always use the channel name at the point of subscribing or when you first downloaded a one-off video.

That way videos are stored alongside another that belong to the same channel even if it changes name at the source at any point in time.

[mstrhakr]

Honestly if %(uploader)s [%(uploader_id)s] was the default name generated for subscriptions it would solve this problem for me, I was about to raise an issue for this exact reason, mostly to track my attempts at solving this. Another fix I've thought about is an option to merge all downloads to this type of folder structure, I'd call it Plex mode. lol. If you have a suggestion on which direction to take this let me know, or I guess if you already plan to look into this.

[GlassedSilver]

Honestly if %(uploader)s [%(uploader_id)s] was the default name generated for subscriptions it would solve this problem for me, I was about to raise an issue for this exact reason, mostly to track my attempts at solving this. Another fix I've thought about is an option to merge all downloads to this type of folder structure, I'd call it Plex mode. lol. If you have a suggestion on which direction to take this let me know, or I guess if you already plan to look into this.

That's basically what I'm thinking about myself.

If we change the default however, it shouldn't apply retroactively without the user agreeing to switching to the new structure, since they may use YTDL-M as frontend for ytdl automation and use the files elsewhere or at least in YTDL-M AND externally. Adding the ability to retroactively sort the on-disk structure is something I am definitely a fan of, because it means you can correct naming mistakes and as long as we have the info.jsons we literally have the same flexibility to path things as we had at the time of downloading. So, in theory, you could download everything into one big mean folder and later on say, enough is enough, thousands of videos and their sidecars in one folder is not okay and just commit to a new structure retroactively.

This approach would entail that we...

• [ ] Index all sidecar files to a download, as in: comments, info-json files, thumbnails, live-chat files, and anything else, usually likely with the same pattern of filename as the video or audio file has, but a different extension. We would need to make sure we become aware of all the different kinds of sidecar files that may come up first, then commit to building a scanner for these files. Scanning yt-dlp's (or any other fork's) stdout for file generation may be one possible way to catch such files getting created going forward. We need to do this, because these files HAVE to stay together, and we DO want them indexed in our database, so we can reference them when needed. (like comments, live chat display, reading metadata from them, displaying thumbnails, etc...)
• [ ] Provide the ability to define your own structure that is used for subscription downloads going forward as described here. This should be possible on a per subscription level as OVERRIDE and the subscriptions in general should be customizable to have this flexibility globally as well.
• [ ] Then we would implement a system where we can move files retroactively, both manually (most suitable for one-off downloads I guess) and systematically by electing to "apply current structure logic to old content of subscription" or a similarly named function. This would also lay the base for: #158

[GlassedSilver]

blocked by #570

blocks #571

[jvgoch]

To add to this, I would like playlists to go straight into the subscription folder and not in the subfolder playlists. Could this be realized with this feature as well?

[pixelapex]

Sounds like this issue should cover the functionality I'm looking for. I mapped both "video" and "subscriptions" to the same "video" folder. I use the following -o path to download videos and playlists: "%(uploader)s/%(playlist)s/%(playlist_index)s - %(title)s" Works perfectly by downloading files in Uploader/Playlist/File structure. I want to download subscription into the same folders organized by Uploader. If I use the same -o string, Subscription always adds channel/playlist folder, then Playlist name, then creates the structure as in -o string, but with playlist being "NA".