cli: support -t formatting vars in -o, -r and -R#3954
Conversation
c501fac to
52aae4c
Compare
52aae4c to
e0bb98c
Compare
|
I'm not sure if I've put the Formatter class file in the right place. Would it be better in |
|
I will take a look at this tomorrow as it's a bit late here. I can already tell you though that this belongs into streamlink_cli, if it makes sense having another formatter class, which I don't know yet. |
|
Cool, I'll move it if the rest of it looks OK to you when you can properly look at it. I think it's worthwhile having the extra formatter class to do both title and filename formatting in a lazy/caching manner. If it wasn't for the use of LazyFormatter in |
|
|
||
| def __missing__(self, k): | ||
| if k == "title": | ||
| v = self.plugin.get_title() or DEFAULT_STREAM_METADATA["title"] |
There was a problem hiding this comment.
all DEFAULT_STREAM_METADATA are pretty stupid, when it get used for a filename
for a player title it is like whatever, but when used for a file it will try to create files with the same name.
streamlink/src/streamlink_cli/constants.py
Lines 11 to 16 in 6cdc3eb
There was a problem hiding this comment.
I don't really see how it's that much of a problem using these default strings in filenames when title/author/category/game cannot be retrieved via the plugin. They seem as good as any to me.
Potentially, yes, if a plugin does not implement any of the metadata methods then it's going to fall back to a filename that will possibly be a duplicate if Streamlink has been called before with a plugin where this has also happened, but the file will not be overwritten unless --force has been specified. I don't think this code should have to do anything to avoid that situation. Why should it need to do so?
| self.cache = self.Cache(self.plugin) | ||
|
|
||
| def __missing__(self, k): | ||
| if k in ("title", "author", "category", "game", "url"): |
There was a problem hiding this comment.
seems hard coded, Formatter is not really reusable for other stuff
There was a problem hiding this comment.
That is true, but it was never intended to be a general reusable formatter. Its purpose is only to supply formatted title and filesystem-safe filename strings in a lazy manner and without multiple calls to the plugin.get_*() metadata methods. Perhaps I should rename it to better reflect that.
|
Here's a cleaned up version:
Changes from this PR:
Tests are obviously still missing. I'm not sure if I want to open a PR for this myself, because I don't want to shut down your efforts of implementing this feature, @mkbloke. What do you suggest should we do? |
|
@bastimeyer, it's fine if you want to open the PR yourself with what you have done. It's substantially different from what I implemented, so I think it makes sense for you to do so. Cheers. |
Sorry for opening yet another PR, it wasn't my original intention.
Tests to come if this code looks reasonable...
closes #3898