Plugin: Emby Interface

At the request of @PrincessCleavage, I’ve added a mechanism by which you can bookmark and resume media. The version of the Emby plugin in the Github repository stable branch contains the following changes:

  • The new BookmarkMedia action (in service urn:toggledbits-com:serviceId:EmbySession1) will bookmark the currently playing media item and its current position for a session. The single parameter Bookmark must provide the bookmark name (case-sensitive).
  • The ResumeMedia action now accepts an optional Bookmark parameter, which, when given, causes the bookmarked media item to begin playing from the saved position.

Bookmarks are stored on the server object, so it is possible to bookmark media on one session and resume it on another (e.g. bookmark on your phone and finish playing on your TV), as long as the two sessions belong to the same server.

Thanks RIgpapa, I have downloaded the update files and uploaded them to develop apps\Luup files, i then manually set a bookmark named resume1 while playing a video file. When i test this bookmark by manually executing resume media resume1 it always restart the video from the beginning, perhaps i am missing something?

Updating the current media position isn’t continuous. Make sure the session is showing a moving time in it’s current position and the right media name. First guess is that you didn’t wait long enough. Nothing is real time here, remember.

After a bricked Vera edge and re-loading updated apps (is it possible to commit the git hub with bookmarks to standard Vera app release? Or perhaps a reason not too?) to verplus and working with Chef to get his Surveillance plugin for emby working again I can finally say that I have this operational and each part responds reasonably quickly (to my delight). Logic is:
Motion detection in the garage while sensors is in armed state (house in night mode) and if either of two main emby clients are active the reactor will trigger and action a bookmark current play state of both clients then wait 5sec then play garage camera feed to the which ever client is active then wait 5secs and disarm garage sensor (testing so far shows that this disarm of the sensor does not reset the reactor for some reason, see below screenshot of reactor in triggered state when garage sensor is not armed). A second reactor is set to monitor the two main emby clients for playingtitle with the name of “garage” and when triggered resumes media on each of the main emby clients, of course this resume does not actually occur immediately on the emby client as the garage camera feed is still playing but the second reactor is in a tripped state still waiting to resume
Media and once stop of the garage camera feed has occurred then with in a couple of seconds the previously playing media resumes then the second reactor wait for 5mins (4mins for sensors cool off time I think) and then arms the garage sensor again ready to trigger the whole process again. Pretty cool and really wanted to thank Rigpapa and Chef for their wonderful work and great plugins to each ecosystem!

1 Like

Version 1.2 is now released for all platforms/stores. This version adds the ability to bookmark media at the current playback position with a named marker, and later resume playback by specifying only the bookmark. This has been in the stable release for some time, so this general release just formalizes that.

Are you seeing any issue where client information is not show (just showing offline) but has been online for over 1hr?

No, it jumps in pretty quick. I’m running server and all clients are up to date.

Hi Rigpapa,
It seems my emby app keeps finding my android tv and adding it multiple times (think I have 8 now). Might it be possible that to have a discovery switch to turn on/off adding new devices or perhaps this is already possible via advanced settings?

I can add a switch to prevent the automatic creation of new sessions, but if the plugin is doing as you describe, it means that the Emby server keeps issuing a new session ID for the same session, and it probably shouldn’t be doing that.

If you would, please run the “Plugin Status” link from the main Emby plugin device and send that to me via PM here. I’d like to take a look at the extra devices to make sure I haven’t missed a trick before I send you off to report a server problem in the Emby forums.

I bet this happens because the ID for your android TV rotates.

This has been a funny issue when requesting device information from the emby API.

In Emby under the Devices tab I can have upwards of fifty Chrome devices listed. This is because while developing the UI for Plugins, I’ve got to clear cached data in chrome to load the new javascript properly. This causes Chrome to generate a new device ID in emby. I’ll clear the cache about twenty times an hour while writting UI code.

this was also an issue with XBOX One restarting on the Network. Xbox One would generate a new UUID, and fill the device list in emby with quadruplicates on the device (if it restarted, not from sleep).

The Emby Vera plugin (The one in the emby catalog) will return devices based on Client.AppName/Name and Device.Name. Limiting its return from a custom API Endpoint, to only show Distinct items.

This is a limitation if two Emby Devices on the network have the same name. The plugin will trigger vera scene requests for both devices. This issue hasn’t come up, and would be rare, but it does exist.

So, a short story long, I bet that is what is happening with the Android TV.

I started using a Fire Stick and realized that because it doesn’t sleep, it startups, it too generates a new device.Id each time it loads. It runs Android TV


Note: SO much fun coding emby and vera together! Not sure what will happen if it where to become cloud based?

Not sure what you mean here. The Emby plugin will filter out devices via isControllableSession(), but the matching of Emby session to existing plugin child device is done strictly by session ID. Two Emby devices can have the same name and the plugin doesn’t care. The name isn’t used as a unique identifier for a session, the UUID is. In fact, the DeviceName and Name fields are pretty much only used for display.

Right sorry, not the Vera Emby Plugin (you wrote) , but the Emby Vera Plugin (I wrote) LOL!
man that could get complicated… :slight_smile:

The emby API allows you to create custom endpoints in their API.

What I did in my plugin was create a custom endpoint which sorts Emby devices so only one version of every device returns. Instead of the entire list of devices, which could have many version of the same device because of the ID changing.

Sorry if that didn’t make any sense at first.

I should explain why an ID might create a new session.

I suspect that the emby server looks at the device ID when creating a session, and if that changes, then a new session would be logged, and the old session with the old device id would be terminated, and a new device would also be added to Emby devices.

And at the same time, I might not be helping at all. :thinking:

Yeah, we’re going to have some fun with that… :slight_smile:

So, this is a pickle, then. Is there any way to uniquely identify a device behind a session (as opposed to a session) on Emby? With new UUIDs being issued for what a user perceives as the same device, it’s automatically broken on Vera because any scripts written to query or take action on the session will be addressing an old, presumably dead session.

Yes, you are correct. Saving device data based on sessions, and counting on Device.Id (UUID) could break easily.

I suppose just comparing device.Name and Client.AppName/Name.

I use to hold session data to gather device information. A user would login on a device, and that would trigger my plugin to show that device in a list to choose from. However, it got complicated because of the changing device.Ids. When devices where compared to “saved device data”, using Device.Ids, it wouldn’t work because the device had changed it’s UUID/Id.

What I have done since, is requested All Device Items ("/Devices") from emby API, then sort the list so no duplicate existed, then show the user the condensed list of devices to choose from.

Then I save data based on Device.Name and Client.Name/AppName, and only ever compare those two variables to act upon.

In most cases people will only ever have one “AndroidTV - Family Room Firestick TV”, or “XBOXONE - Emby Theater” so it is safe. But, if two people are login into a Web client in Chrome, on two different computers, and start video playback, there is no way to know which chrome to choose from so it would, in theory, act upon both of them.

It is not perfect, by any means.

I personally don’t know which chrome account to choose sometimes I don’t have only one

ShowBox Tutuapp Mobdro

OK. As a workaround, the current stable release, which I plan to put in general release tomorrow, contains two new state variables: FilterClients and FilterDeviceNames. These variables may contain patterns that, when matched, prevent a session from becoming a Vera device. The defaults are “emby mobile” and blank, respectively, which should filter out all browser-based sessions (as long as that client string stays consistent on the Emby server/client side).

So if I have a emby device that keeps being added (TV) I can can simply add this to the FilterDeviceNames and it will not be added again?

That’s my story and I’m sticking to it.

Hi Rigpapa,
I have added “TV” into filterdevicenames but I am still getting multiple tv child devices created e.g TV2 TV3 TV4 TV5 etc
Should I be using a wildcard in filterdevicenames like TV* perhaps?

Try using tv lower case.

© 2019 Vera Control Ltd., All Rights Reserved. Terms of Use | Privacy Policy