If there was one piece of information I'd want to know before developing an Emby Plugin ...

[Anthony Musgrove 195]

Hi all,

 

After working with the Emby SDK for almost 2 months now, I'm finally getting really tight grasp on its framework, troubleshooting and usability.

 

This thread is for those who are just starting out developing an Emby Plugin, to browse through and get closer to understanding the quirks and tips & tricks of the Emby plugin development trade.

 

I'm going to start by saying;

 

 

Some of the various quirks that I wish I knew before I started ... 

 

• Plugin configuration html pages should ALWAYS be scoped to the page and NOT the entire document, by passing the page instance around to functions to setup your interface, you'll be guaranteed to always have them in the right scope.   Why?  Because the configuration pages (upon reopening the configuration pages), load up to three times in the one browser session.  If you scope to the entire document, your code will end up selecting an instance of the configuration page loaded in browser memory that isn't currently being shown -- so you'll be pulling your hair out (trust me, you will end up bald), trying to figure out why you can't see your javascript making changes to your configuration interface.
   
• DONT use label for="" if you want to link some javascript to the element described in 'for'.  This is the most recent thing that I've figured out after spending hours trying to figure out why my File Picker would only update the label the first time I opened the configuration page (when selecting a file).  It was updating the 'for' element on ONE of the THREE loaded interface pages that wasn't on screen (after reloading the configuration page).  This makes sense - because label for='' is stating that this particular label is for 'an element called this', where 'an element called this' can exist up to three times in your browser memory and may not be on-screen.   Even if its on a separate 'page' instance, the browser just sees the first element with that Id and that label belongs to that first element - which may or may not be on your screen.
   
• DONT try to reference to a list of elements in another object in your plugin configuration - for example, I have a 'ScripterX Package Manager' that contains a List<Package> (list of packages) that are currently installed - I tried to refer to this in the plugin configuration to simply load the elements from configuration directly into my package manager, and likewise save them back to the configuration file from this list.   The main problem here is that my package manager loads way further down the track than the XML is deserialized, so because there was no package manager, I ended up with a bunch of orphan packages, then saving back actually erased everything out of the configuration file.
   
• DONT try to use RequestStream in the API with other elements - if you require the RequestStream you need not have any other elements in the request data.
   
• DONT stress if your plugin needs some external dll files (libraries).  You can embed them into your plugin's dll file and use Reflection to load them as per needed - it is actually REALLY simple and REALLY effective.
   
• Make sure all your configuration files, javascript files, etc are set to 'Embedded resource' under Advanced -> Build Action for that file.  It's very easy to forget this simple step and can leave you stuck for a significant amount of time, trying to figure out why your configuration files don't exist on your server.
   
• Need an external javascript library?  No problems.  Don't try injecting it yourself.  Use the proper framework and use the 'Require' command, for example;  require([Dashboard.getConfigurationResourceUrl('SortableJS')], function (Sortable) { }  gave me a nice little package for sorting elements on my configuration page(s) and it scoped it perfectly.
   
• Setup your IDE properly - it takes time copying your freshly compiled plugin to your plugins directory for testing on your local installation of Emby Server.   Setup your post-build script to do all the work for you.  Install curl on your computer and you'll also be able to use Visual Studio to restart Emby Server after your fresh build is automatically copied to your plugins directory.  My post-build script on my laptop is:

copy $(TargetPath) M:\programdata\plugins\
call c:\curl\bin\curl.exe -X POST "http://192.168.1.50:8096/emby/System/Restart?api_key=<yourapikeyhere>" -H "accept: */*" -d ""

This tells visual studio, after my build is successful, copy the .dll file to my plugins directory, then restart my emby server.

 

 

There's so much more I've learnt, but this is a start.  If you have anything to add, please feel free to add it here.  I am excited to read some of the nuances you've come across while making your awesome plugins shine.