Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Buldarged]

After reading the All the little technical things thread which is somehow completely right and wrong at the same time I decided to make this thread to state my opinion, with the hope to get some answers and insights from JRiver and other users.

MC has become very large and the user base is quite heterogeneous. Therefore, most additions will only cater to a small part of the total user base. There was an official thread about this a year or two ago. There were some recent additions I think are important(e.g. black bar detection), but overall I think MC moved quite slowly in the last 10 years. Mostly due to updates being fixes, changes or small additions. And some bigger additions don't change that much (e.g. JRVR).

JRiver decision to give users more possibilities to customize MC is absolutely the right one. However, I think that happens far too slowly and without a greater goal in mind. MCs expression language is not a good tool to work with. No local variables, no loops, no functions, no network requests, no GUI, etc. It's not even ideal for a simple task like thumbnail text as shown in my progress bar example.
This does not mean JRiver should invent a new programming language. But, it should provide a sandboxed scripting language environment(ideally Python) and the necessary API for interacting with the database and the GUI to allow users to write their own plugins. Those plugins could be additional metadata sources(TVDB, AniDB, ...), content providers(Netflix, Disney Plus, ...) and custom views. Of course an easy way for users to share and install plugins is also necessary.

Competing software like Plex & Emby have plugins and they are really thriving and it makes me quite envious. It allows an army of users to quickly add desired functionality, which can than later be standardized by the companies behind. In that sense, plugin download counts are also a great marketing research tool. It shows what users want and what the software does not provide. From a business perspective, plugins are also quite beneficial. They are usually developed for the latest version only, therefore encouraging users to upgrade their software, if the want to update their plugins.

I think the missing plugin functionality is the largest drawback of MC and providing it, could fix so many issues it currently has. However, many users, include me, have brought this request up multiple times without success. Now the question is why? Is it an issue of complexity, fragmentation, control, etc? Isn't the time ripe?

[JimH]

Are you aware of the current API's?

https://wiki.jriver.com/index.php/DevZone

MCWS is the most modern.

[Buldarged]

The current API's don't really allow for the things I'm talking about. They are suited for external tools that interact with MC or complement. When I say "plugin", I talk about changing and adding functionality from inside MC not from an external tool.

E.g. lets assume I would like to add Amazon as a book metadata source into MC since there is no book metadata source yet. What would I need for that?
Right click on a file that has the media sub type set to book should have an additional "Get Book Info from Amazon" entry --> Ability to add right click context handlers
MC should display a window similar to the "Get Movie & TV Info" dialog --> Ability to show a window and adding basic widgets with minimal layout control
Such plugins would also probably need some kind of permission management, which in this case would be: "Reading and writing library tags"  + "Network Access"

And sharing such plugins is an important aspect too. Ideally, there would a plugin category inside the settings menu, where users can search, install and update plugins from within MC.

[EnglishTiger]

E.g. lets assume I would like to add Amazon as a book metadata source into MC since there is no book metadata source yet. What would I need for that?

A Miracle because Amazon prevented metadata extraction by anything other than a human being using cut and paste years ago.

Oh and some of those existing plugins do create, read and write library fields/tags

[Buldarged]

A Miracle because Amazon prevented metadata extraction by anything other than a human being using cut and paste years ago.

I just recently wrote a curl oneliner to get the cover art of books from Amazon using the ASIN. More complex tasks should work quite well using scrapy and some waiting time in batch queries. Calibre uses Amazon to this date. A proper API is nice for robustness, but in no means necessary. Anti-DDos measures like Cloudflare & co are only a problem, if you send too many requests in too short time.

Oh and some of those existing plugins do create, read and write library fields/tags

Yeah, those methods seem fine to me in the sense that they can do what they should do. But, if you want to do more, e.g. add a new streaming provider, then the right tools aren't really there. You could add "dummy entries", but what are the consequences? Those entries might be cleaned up when exiting MC or might show a missing file indicator.



I don't think JRiver should start with a plugin framework that can do all these things, but rather seeing these usecases as a goal. Each new version of MC can then bring the new functionality for a new type of plugin.
E.g.
MC32 --> Support for an imperative scripting language with loops, functions, classes, etc
MC33 --> Ability to create and manipulate windows and widgets in this scripting language
MC34 --> Plugin Manager for easy plugin installation + permission management
MC35 --> Ability to create new custom views