Added new MetadataViewer PlugIn

[softworkz]

It's beta, it's hacky, but it works fine with the current dev versions at least.

[LukePulverenti]

This will be best left as a private plugin in the community. Not all environments will have write access to the install folder to modify source files, therefore I'd rather not have it in the catalog. I don't think it's the right approach anyway.

[softworkz]

I don't think that's a good approach either - it's just a hack to get it working at all for now.

You should not decide private/official by judging the current implementation. You should rather decide about the functionality it provides.

IMO the presented information is extremely useful and will be even more useful once we get some feature to override providers for certain items (especially series).

Looking at this from the opposite perspective: If we add another (4th) episode provider (tvmaze), the benefit would be quite limited with the current logic. To allow efficient use of such a multitude of providers, the user needs to be able to:

• View and compare the data provided by the individual providers
• Override provider priorities in certain cases (e.g. because he found in the previous step that another provider has better data)

Without such means for transparency and manipulation, I wouldn't see much value in creating additional providers.

[softworkz]

PS: I didn't actually expect you to merge this in its current state. I created the PR to let you see what changes would be required in Emby to support a PlugIn like this...

[LukePulverenti]

Ok, sounds good. Thanks.

[softworkz]

I just re-read your comment:

Not all environments will have write access to the install folder to modify source files, therefore...

Probably you didn't see that I don't modify the original source files. I modify the "metadataeditor.js" and save it to a sub-folder of the Plugins folder. Then I make ServiceStack serve it from there instead of the original file (only works as long as the plugin is loaded). Isn't it allowed to create a subfolder in the plugins folder? (because the CoverArt plugin does the same)

I don't think it's the right approach anyway

I totally agree and I'm waiting for your input on how to solve that. Here are my personal ideas... Eventually it boils down to these two issues:

Serve Static Files

How can I serve custom static files (html/js/css) via http without copying them to the dashboard-ui subfolders? The least invasive (and only working) mehod to do that from a plugin appeared to be adding a handler to the RawHttpHandlers collection of ServiceStack's IAppHost. I tried other ways from the list of "HTTP Custom hooks" described here: https://github.com/ServiceStack/ServiceStack/wiki/Order-of-Operations but others didn't seem to work for static files. Alternatives could be using ServiceStackHost.VirtualPathProvider or some manual implementation in HttpListenerHost.RequestHandler, but this must be implemented in the core server and expose a method for plugins to register certain files or folders to be served.

Add custom library commands

Currently I am modifying "metadataeditor.js" to add an addional menu command which is an ugly hack of course. For a clean solution there should be a method to register custom commands. In the client code, something like: Dashboard.RegisterLibraryCommand(caption, icon, visibleDelegate, enabledDelegate) Or deliver custom commands through the server. Either way the server must be able to inject plugin script files into the client.

Just my thoughts - maybe you come up with something better ;-)

[softworkz]

I was able to eliminate any local file manipulations in the latest version. All new or modified files are directly served from memory now!

[softworkz]

Added some minor improvements:

• Removed additional irrelevant properties
• Display Provider IDs as hyperlinks if it's supported
• Display the returned ProviderIds for each provider