Closed GlassedSilver closed 4 years ago
I see what you're saying, I wonder where and how these rules can be set. One edge case is, what if a video or subscription fits into multiple rules? Maybe the rules should be ranked in a priority list so the highest priority rule gets applied and the other ones get ignored.
Another roadblock is the fact that video titles/channel names are not always known before the download is complete, so it might require manually moving the files into the appropriate folders after the download is complete.
category path modifiers are probably best used as either variable token and/or the first level after the root path for downloads.
I think the latter is the simplest approach, as it requires the fewest amount of changes.
I like the idea, but it'll need the subscriptions rework to avoid excluding subscriptions from the categorization system. I'll add it to the 4.2 project so it'll be down the pipeline.
I love you
Haha love you too!
I see what you're saying, I wonder where and how these rules can be set. One edge case is, what if a video or subscription fits into multiple rules? Maybe the rules should be ranked in a priority list so the highest priority rule gets applied and the other ones get ignored.
Okay, so I thought up a little concept. I'll visualize it later on if you want some inspiration how to solve this GUI-wise, bit in a hurry atm, but happy to deliver later today! :)
Either way, I'm thinking of categories in happy harmony with sub-categories.
Tech Videos --PC Tech --Gaming --/--Consoles --/--/--Nintendo Music --Music Videos --/--AMVs --/--MMVs --Nightcore --Mainstream --/--Pop
etc... Explanation: (-- second level, --/-- third level, etc...)
Just an example of how my structure could look like in parts.
Now every level can get its own folder assigned, maybe with reconstruction from an existing hierarchy (in such a case I would suggest any folder name with square brackets is ignored, inform the user about this, as the square brackets are commonly used for IDs for downloads and channel folders. So irrelevant for a reconstruction of the category hierarchy system.
Maybe then we could also have tags, these wouldn't REPLACE or compete with categories, because tags can be very specific, plentiful, etc... I guess you know what I mean. Tags are super helpful for searching, categories are usually very helpful for browsing and discovering.
Tags could warrant its own issue ticket I guess, because it's quite separate both technically as well as UX-wise. If I forget to do that, I'll just mention that copying tags from the source could also be a nice thing. Hmmm... I'll try to remember to create a separate issue for this and flesh out my ideas a bit more, also helps keep the flow of ideas in these more complicated tickets a bit more together and tidy. :)
Another roadblock is the fact that video titles/channel names are not always known before the download is complete, so it might require manually moving the files into the appropriate folders after the download is complete.
Maybe this could be solved by simulating (and hence parsing) the command first? I don't just mean the simulated output that the UI is presenting already, but actually sending the simulation arg to youtube-dl. (--simulate
)
That way we might also catch some errors before the download is started instead of mid-way. (less time spent looking after youtuble-dl properly working. At least you cut down the time on finding errors in many cases I assume?
category path modifiers are probably best used as either variable token and/or the first level after the root path for downloads.
I think the latter is the simplest approach, as it requires the fewest amount of changes.
I like the idea, but it'll need the subscriptions rework to avoid excluding subscriptions from the categorization system. I'll add it to the 4.2 project so it'll be down the pipeline.
Well see above I guess after giving it a bit more thought. :D
Either way, excited to see you assigning this to 4.2. :)
I'd appreciate a UI visualization, I think the more I code the worse I get at UI design :P
Sub-categories is a good extension of this, but I think we still have the underlying problem of conflicting categories. Let's say a video fits into both PC Tech and Gaming, where should it go?
Maybe then we could also have tags, these wouldn't REPLACE or compete with categories, because tags can be very specific, plentiful, etc... I guess you know what I mean. Tags are super helpful for searching, categories are usually very helpful for browsing and discovering.
Hm. We can use the same rule structure for setting categories and tags, so having tags seems like an easy extension of categories. Also, you're right in that we can pre-populate a video's tags with the source video's tags (we have this info, we just don't use it).
Maybe this could be solved by simulating (and hence parsing) the command first? I don't just mean the simulated output that the UI is presenting already, but actually sending the simulation arg to youtube-dl. (--simulate)
That way we might also catch some errors before the download is started instead of mid-way. (less time spent looking after youtuble-dl properly working. At least you cut down the time on finding errors in many cases I assume?
The reason why I have avoided doing this is to reduce download time. It takes around 5-10 seconds for me to get the video info, and this is sometimes longer than the download itself (for short, small videos).
But running the simulation before does have the advantage you listed: we'll know if the download will fail before we run it. I think the benefits of simulating outweigh the harms, so you have a good point here.
I'd appreciate a UI visualization, I think the more I code the worse I get at UI design :P
My next response will have that, I'll do the visualization on my Surface with the pen. :D
Sub-categories is a good extension of this, but I think we still have the underlying problem of conflicting categories. Let's say a video fits into both PC Tech and Gaming, where should it go?
If a video covers more than one main topic then it can be tagged with all appropriate tags, but the user still needs to find a main [sub]-topic.
So manual moving to a different category has to be possible. Personally I'd always put a video into the category that the channel is mainly known for. Any other category that could apply I will apply as tag. Tags and categories are however not mutually exclusive, nor are they replacements for each other. e.g. a video stored in the tech category usually will also get the tech tag, if the user wishes to have tech as a tag as well, but tagging is separate.
Tags are more danbooru-like I think. Categories are more to find a folder to store a video in, especially for things like media-kinds. (think of the differentiation between an AMV and a regular music video or news shows etc... Categories are very much the concept of finding a good storage location based on some user approachable differentiation.
Maybe then we could also have tags, these wouldn't REPLACE or compete with categories, because tags can be very specific, plentiful, etc... I guess you know what I mean. Tags are super helpful for searching, categories are usually very helpful for browsing and discovering.
Hm. We can use the same rule structure for setting categories and tags, so having tags seems like an easy extension of categories. Also, you're right in that we can pre-populate a video's tags with the source video's tags (we have this info, we just don't use it).
That's true. Having triggers activate the setting of a category can set a tag as well. Note however that categories are limited to ONE per video. Tags are not mutually exclusives. Think of categories as folders. A sub-category is a sub-folder as well.
Maybe this could be solved by simulating (and hence parsing) the command first? I don't just mean the simulated output that the UI is presenting already, but actually sending the simulation arg to youtube-dl. (--simulate)
That way we might also catch some errors before the download is started instead of mid-way. (less time spent looking after youtuble-dl properly working. At least you cut down the time on finding errors in many cases I assume?
The reason why I have avoided doing this is to reduce download time. It takes around 5-10 seconds for me to get the video info, and this is sometimes longer than the download itself (for short, small videos).
But running the simulation before does have the advantage you listed: we'll know if the download will fail before we run it. I think the benefits of simulating outweigh the harms, so you have a good point here.
I think so as well. It would greatly benefit the UX, the downside would be more relevant in a less automated and more manual (and hence also more user-monitored) scenario. :)
Good progress has been made on categories! Here's a quick summary of what is done:
Right now, categories don't do anything. It only adds a category
field to the file in the DB. So there's only one thing left to do: the path modification part. This shouldn't be too complicated and much of the functionality is already there. I just need to allow users to input a custom output in the editing dialog.
Here are the screenshots, I'm looking for advice on the UI design so I'd very much appreciate that!
Categories in settings:
Editing a category & its rules:
Implemented! See #236 for details
FYI, in v4.2, playlists will be auto generated for each category :)
I'm thinking of categories you can set per video and per channel as either global rules (channels, keywords in video titles) and per download or per subscription.
The reason this could be very useful is to facilitate browsing both within youtubematerial-dl or other GUIs/servers like a Plex parsing the downloads, latter based on the folder structure.
category path modifiers are probably best used as either variable token and/or the first level after the root path for downloads.