Plugin: Emby Interface

[quote=“rigpapa”][quote=“Sammy2, post:22, topic:200354”]I’m sorry to confuse but I’m wondering how to set it up so that when a device is activated I get a notice or how to have it pause if another device changes state… or even change input. Say a camera senses motion Emby switches to display that camera through the Emby Surveillance Plugin.

@chef what do you think?

Sent from my SM-G960U1 using Tapatalk[/quote]

OK. I’ll let @Chef, @PrincessCleavage and others respond on this, because they have relevant experience coordinating events like this with cameras, I recall. But to guide you generally and maybe give you a head start until they chime in, the README file on Github has information about the actions the Emby plugin supports (specifically the Emby Session Actions section).[/quote]Reading it and I also think I need to get a handle on Reactor too…

I haven’t spent much time on my Vera lately as it is doing what I want it to do but I do want it to do more…

Sent from my SM-G960U1 using Tapatalk

[quote=“Sammy2”][quote=“rigpapa”][quote=“Sammy2, post:22, topic:200354”]I’m sorry to confuse but I’m wondering how to set it up so that when a device is activated I get a notice or how to have it pause if another device changes state… or even change input. Say a camera senses motion Emby switches to display that camera through the Emby Surveillance Plugin.

@chef what do you think?

Sent from my SM-G960U1 using Tapatalk[/quote]

OK. I’ll let @Chef, @PrincessCleavage and others respond on this, because they have relevant experience coordinating events like this with cameras, I recall. But to guide you generally and maybe give you a head start until they chime in, the README file on Github has information about the actions the Emby plugin supports (specifically the Emby Session Actions section).[/quote]Reading it and I also think I need to get a handle on Reactor too…

I haven’t spent much time on my Vera lately as it is doing what I want it to do but I do want it to do more…

Sent from my SM-G960U1 using Tapatalk[/quote]
Hi Sammy,
1st. When you have many clients detected It can be easy to miss the master device (emby server name) mixed in with all the others and once I think I set it to hide or not show, and this mater device contains the controls your looking for to show or hide the child nodes.
As for camera feeds I thought it might be best to encourage you to get your hands dirty with reactor and provide some screenshots of my conditions and activities
1st is condition to trigger sending tripped camera feed to an active client while armed (night mode for me)


Action or activities if one of the groups of conditions above are true

A seperate reactor to control monitoring of if the garage camera feed is playing on either of my two main clients and the resume previously playing movie or media

And actions if the above conditions become true then untripped I.e camera feed stops playing
the resume part is the only part I am having difficulty with resuming previously playing media on specific client but I notice that the plugin may of had a update and resume is now and option (I will need to test again). I also have the emby api thread open with a request if luke can possibly add resume previously playing media to the emby server api (to assist with resume of playlists and in general resumption of previously playing media). As for media title you can find this by simply using the search feature in Emby for e.g my garage camera in Chef Surveillance plugin for emby is named simply garage. I hope this is enough to enticement to get you started with reactor app.

1 Like

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 4.1.1.0 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

:slight_smile:

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.