Plugin paths supported?

[pünktchen 1288]

@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 1486]

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 August 27, 2021 by quickmic

[pünktchen 1288]

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.

[pünktchen 1288]

@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 1486]

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 1288]

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 1486]

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 November 15, 2021 by quickmic

[pünktchen 1288]

Great! Will report back.

[pünktchen 1288]

Working great. Thank you so much!

[pünktchen 1288]

@quickmic is this still supported?

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

 

[quickmic 1486]

6 hours ago, pünktchen said:

@quickmic is this still supported?

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

 

Yes

[pünktchen 1288]

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

[quickmic 1486]

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 1288]

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 1486]

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 January 15, 2023 by quickmic

[pünktchen 1288]

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.

[Luke 38093]

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 1486]

Ok, I'll check that.

Edited January 16, 2023 by quickmic

[quickmic 1486]

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 1288]

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.

[quickmic 1486]

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.

 

[Luke 38093]

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 1486]

@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 January 17, 2023 by quickmic

[pünktchen 1288]

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.

[quickmic 1486]

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.