Jump to content

Recommended Posts

pünktchen
Posted

@quickmic 
Does your addon support simple plugin paths for playback like EmbyCon does?

plugin://plugin.video.embycon/?item_id={ItemId}&mode=PLAY

I know i can use the addon webserver like this:

http://127.0.0.1:57578/embyvideodynamic-{ServerId}-{ItemId}-{ItemType}-{Name}.{Extension}

But that requires to know to many parameters beforehand, when i only have the itemId.

quickmic
Posted (edited)
On 8/26/2021 at 1:52 AM, pünktchen said:

@quickmic 
Does your addon support simple plugin paths for playback like EmbyCon does?







plugin://plugin.video.embycon/?item_id={ItemId}&mode=PLAY

I know i can use the addon webserver like this:







http://127.0.0.1:57578/embyvideodynamic-{ServerId}-{ItemId}-{ItemType}-{Name}.{Extension}

But that requires to know to many parameters beforehand, when i only have the itemId.

Well, you need the ServerID. It's mandatory due to multi-Emby-server-support.

The ServerID is NOT made up by next-gen plugin, it the real Emby-Server ID like: "2a38697ffc1b428b943aa1b6014e2263"

Also there are two options for remote content. One is the embyvideodynamic as you mentioned, the other one is embylivetv.

http://127.0.0.1:57578/embylivetv-{ServerID}-{ItemID}-stream.ts

For embyvideodynamic:

{ItemType} = "MusicVideo", "Movie", "Episode", "Video" etc

{Name} = Filename

{Extension} = mkv, mp4 etc.

{Filename} are not really critical. It's just used for connivance, you can also make that up like "blabla" as filename. (no special characters allowed, including spaces!)

{Extension} should at least indicate the content (Kodi uses the extensions to detect audio or video content. So it's critical NOT using mp3 if it's a video and vice versa.

It's not really critical to use mkv instead of mp4. Probably the Kodi OSD tags are not correct, but it will work anyway.

{ItemType} is used for identification. Actually dynamic content (this is all content received remotely from emby server via websocket) is checked if it's (already) synced to Kodi's DB.

If yes, next-gen pulls the metadata from Kodi DB (much faster). If it's not synced, next-gen queries Emby-server for metadata. If this info is not correct, worst case would be. next-gen pulls data from Emby server even it's already synced and actually no need for. (Slower). But it should work even it's not correct.

 

btw, what you hav ein mind?

VirtualTV is already supported by the latest experimental version.

Edited by quickmic
pünktchen
Posted

My plugin can also export stream links for playback of past and future programs as archive video (SimplePVR calls it catchup streams) to a channels.m3u. The stream links are urls with a placeholder for the "CatchupId" that is provided as part of the program from a xmltv file. I must admit i didn't try if the CatchupId accepts such a long parameter like the ones that are needed for your addon. I thought i would ask for a simpler method before i start to code.

The reason why i also write EmbyNextGen urls in the export function of my plugin is, with the channels.m3u of your addon users that have a live tv plugin in Emby and the same as a Kodi pvr addon, get duplicated channels.

  • Like 1
  • 2 months later...
pünktchen
Posted

@quickmic with some of your addon updates, the dynamic proxy urls have changed

from:

http://127.0.0.1:57578/embyvideodynamic-{ServerId}-{ItemId}-{ItemType}-{ItemName}.{FileExtension}

to:

http://127.0.0.1:57578/embyvideodynamic-{ServerId}-{ItemId}-{ItemType}-bc5ed8d67ac34d98745631hhb2158d7b12-8000507-h264-{ItemName}.{FileExtension}

What are those additional parameters?
Are really all those parameters needed that your addon works correctly? Right now your addon just throws an exception if only one parameter is missing in the query.
How often do you plan to change those urls? It makes it really hard for me to support your addon if such basic function changes often.

quickmic
Posted
Quote

How often do you plan to change those urls? It makes it really hard for me to support your addon if such basic function changes often.

Actually, yes they can change and have in one of the last betas. Actually it was not the intention as API usage.

I will add an api/url like Embycon. Mandatory data would be {ServerId} and  {ItemId} OR {MediasourceID}.

I cannot skip ServerId due to multi emby server support. The ItemId or MediasourceId is no longer unique in this case

 

At the moment, all parameters are mandatory, but some of the are not critical. You could make an assumption for :

 

e.g.
{ItemType} = movie
{ItemName} = unknown
{FileExtension} = mkv

pünktchen
Posted
1 hour ago, quickmic said:

I will add an api/url like Embycon. Mandatory data would be {ServerId} and  {ItemId} OR {MediasourceID}

That would be fantastic and would solve all problems. Preferable only ServerId and ItemId.

quickmic
Posted (edited)

I added the API support in the last experimental version.

 

If you want you can try or wait till beta is available.

command is:

RunPlugin(plugin://plugin.video.emby-next-gen?mode=play&server=2a38697ffc1b428b943aa1b6014e2263&item=123322)

case sensitive!

 

 

Edited by quickmic
  • Thanks 1
pünktchen
Posted

Great! Will report back.

pünktchen
Posted

Working great. Thank you so much!

  • Like 1
  • 1 year later...
pünktchen
Posted

@quickmic is this still supported?

plugin://plugin.video.emby-next-gen?mode=play&server={ServerId}&item={ItemId}

 

quickmic
Posted
6 hours ago, pünktchen said:

@quickmic is this still supported?

plugin://plugin.video.emby-next-gen?mode=play&server={ServerId}&item={ItemId}

 

Yes

  • Like 1
pünktchen
Posted

Any reason why you don't request "Static=true" for a live tv stream?

quickmic
Posted
6 hours ago, pünktchen said:

Any reason why you don't request "Static=true" for a live tv stream?

"Historical" reasons, but transcoding options will be completly changed in next version. However current "ts" must also work.

pünktchen
Posted
5 hours ago, quickmic said:

However current "ts" must also work.

Only partially, because you don't request a live tv stream like it's supposed to be. Normaly you should make a post request to MediaInfoService with AutoOpenLivestream=True before requesting the actual live tv video stream.

quickmic
Posted (edited)

Well current request is a regular stream in a specific container format (ts).

/emby/videos/{ItemId}/stream.ts?PlaySessionId=XXXX&DeviceId=XXXX

 

I'll check what's the actual request via plugin:// "api"

EDIT:

check, api should use the same stream query type

Edited by quickmic
pünktchen
Posted

I didn't say you request is completely wrong! I only said you are missing the post request to MediaInfoService before. The way you do it, not all live tv plugins will work.

Posted

Full complete support of all features, yes, I would suggest using the /playbackinfo api for video, rather than just constructing a stream url client-side.

quickmic
Posted (edited)

Ok, I'll check that.

Edited by quickmic
quickmic
Posted

Can you elaborate what's the actual reason for the MediaInfoService calls?

The player has all information needed and by transmitting the ItemID it should be clear to Emby server it's a livestream.

 

As mentioned, I'll change the query in next version to just calling:

videos/{QueryData['EmbyID']}/stream?static=true&PlaySessionId=XXX&DeviceId=XXX&api_key=XXX

or transcoding:

videos/{QueryData['EmbyID']}/stream.ts?VideoCodec=XXX&AudioCodec=XXX&PlaySessionId=XXX&DeviceId=XXX&api_key=XXX

Still looking into the post request...

 

pünktchen
Posted

Live tv plugins can define two important properties: RequiresOpening and RequiresClosing. For example if a plugin sets RequiresClosing=True, then when closing a live tv stream in Emby, the Emby server also calls the live tv plugin to close the stream at the backend. This is done with a LiveStreamId not the PlaybackSessionId! You get that LiveStreamId from the post request with AutoOpenLivestream=True. Without that proper Id the live tv plugin backend will never release it's tuner unless it has some kind of timeout.

For RequiresOpening hopefully @Luke will tell us what is happening in the background.

  • Thanks 1
quickmic
Posted
22 minutes ago, pünktchen said:

Live tv plugins can define two important properties: RequiresOpening and RequiresClosing. For example if a plugin sets RequiresClosing=True, then when closing a live tv stream in Emby, the Emby server also calls the live tv plugin to close the stream at the backend. This is done with a LiveStreamId not the PlaybackSessionId! You get that LiveStreamId from the post request with AutoOpenLivestream=True. Without that proper Id the live tv plugin backend will never release it's tuner unless it has some kind of timeout.

For RequiresOpening hopefully @Luke will tell us what is happening in the background.

Ok, understood. Frankly sounds a bit like Emby server is outsourcing what should be handled internally.

 

Posted

There are a number of server settings that affect how things get steamed, disabling, enabling, limiting certain things, etc. This helps make sure those get respected. 

quickmic
Posted (edited)

@pünktchen

I need your support what API calls are required.

I performed several tests with LiveTV/DVR streams via Emby server. I had no issues, static streams are perfect (including audio stream selection, handled by player)

I know Emby deals with Transcoding kind of odd, assuming "historical" reasons.

 

So let's focus first on static streams:

You mentioned I should POST a /LiveStreams/Open

Would this be sufficient for your plugin:

1. /LiveStreams/Open?UserId=XXXX&playsessionid=XXXX&itemid=XXXX&api_key=XXX

2. /videos/{QueryData['EmbyID']}/stream?static=true&PlaySessionId=XXX&DeviceId=XXX&api_key=XXX

3. on stop: with /LiveStreams/Close?livestreamId=XXX&api_key=XXX

 

Where did I get the LivestreamID? I just performed a quick test, seems POST request doesn't return the LivestreamID? Will double check soon.

btw, my opinion is still stands. This something the player should not deal with.

Edited by quickmic
pünktchen
Posted

1. post to Items/{Id}/PlaybackInfo with "AutoOpenLiveStream=true" in the request payload will return a LiveStreamId (also urls for your second request)

3. post to /Sessions/Playing/Stopped with the LiveStreamId

I hope this helps a little bit. I'm only on mobile until the weekend... But you can also use the browser console to see what the web client is doing.

  • Thanks 1
  • 2 weeks later...
quickmic
Posted
On 1/17/2023 at 11:53 PM, pünktchen said:

1. post to Items/{Id}/PlaybackInfo with "AutoOpenLiveStream=true" in the request payload will return a LiveStreamId (also urls for your second request)

3. post to /Sessions/Playing/Stopped with the LiveStreamId

I hope this helps a little bit. I'm only on mobile until the weekend... But you can also use the browser console to see what the web client is doing.

I modified the code following -> PlaybackInfo ->  LiveStreams/Open -> LiveStreams/Close.

Will be available in 8.x, also I have a deeper understanding what Emby server actually does with this information. -> consumer count is now 34

Still I see no need that the player is responsible providing Emby server with this information. consumer count, OpenToken all good functions, but still I think this should be handled internally.

btw. Seems the consumer count cannot be reset (in case application crashes etc.) There should be at least a timeout. Emby server knows when a application is disconnected and should decrease the counter but that's a different topic.

Thanks for pointing me in the right direction.

 

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...