Tzahi12345 / YoutubeDL-Material

Self-hosted YouTube downloader built on Material Design
MIT License
2.66k stars 276 forks source link

Feature Req: Create Playlist from local directories (i.e. already downloaded) #97

Open projx opened 4 years ago

projx commented 4 years ago

Hi

I appreciate this may be out of scope, as strictly speaking its not downloading, and I'm not sure it is possible. But the interface and player in pretty slick, so this would be a nice feature to make it a comprehensive ripped video player.

Requirement: At present users will have a host of files, probably downloaded with youtube-dl directly, another video-ripper. Having all these videos spread out across different directories, then having to use a mix of a File Manager, NAS Browser, and YoutubeDL-Material to watch them.

Proposed Feature: Add a feature, that allows a user to create multiple local playlists, each playlist would have a defined root-directory, YoutubeDL-Material would scan this (including sub-directories), indexing the videos files. In the UI, clicking a local-playlist would should the list of videos (as currently done in Playlist/Subscription), clicking the video will play the video.

Justification: YoutubeDL-Material provides a superb Video downloader and viewer, adding this feature would allow it to become a centralised-media viewer, or a one-stop-shop for ripped videos, removing the need to revert to different solutions depending upon the video location or how it was downloaded.

Thanks for reading :)

Tzahi12345 commented 4 years ago

Not a bad idea! I'd like to allow users to be able to import video files, optionally creating playlists if the videos are in the same subfolder. There's one big caveat with this though:

The .info.json file must be present with the file, otherwise YoutubeDL-Material has no way of producing the necessary metadata to store and run the file. This is why every download has --write-info-json, it simply needs that information for the file to get registered into the DB.

We already have 90% of the functionality there for file imports, but those files need to have their .info.json present or it will be skipped. Not sure if there's an easy way around this (maybe just use N/A values for most of the metadata, and let users manually input all that info?). Another limitation is file extension, as the imported files would need to the mp3 or mp4.

Long story short, I think this is viable, just comes with a couple kinks. Thanks for the suggestion!

suckerfish commented 4 years ago

Going to second this. I have a lot of 'random' videos lying around that I'd love to centralize in some way. A feature like this would be great.

GlassedSilver commented 4 years ago

Not a bad idea! I'd like to allow users to be able to import video files, optionally creating playlists if the videos are in the same subfolder. There's one big caveat with this though:

The .info.json file must be present with the file, otherwise YoutubeDL-Material has no way of producing the necessary metadata to store and run the file. This is why every download has --write-info-json, it simply needs that information for the file to get registered into the DB.

We already have 90% of the functionality there for file imports, but those files need to have their .info.json present or it will be skipped. Not sure if there's an easy way around this (maybe just use N/A values for most of the metadata, and let users manually input all that info?). Another limitation is file extension, as the imported files would need to the mp3 or mp4.

Long story short, I think this is viable, just comes with a couple kinks. Thanks for the suggestion!

For videos that don't have info.jsons we could have a staging process. An "inbox" where videos are listed that have been found, but aren't supplied with valid info files.

You could then manually edit the meta data. Similar to how iTunes really wants you to have an artist, album, track title, etc for an mp3, but if that isn't present it will show with its filename and you're free to manually edit all those fields yourself.

However I'd really suggest that for "imprope" files found we have that staging process, so we can separately deal with files that aren't conforming to the standard. And make that a special inbox really please. Anything that has info.jsons can go straight to the db and main view. :)