New Plugin - Custom Scripting | Emby ScripterX

[Carlo 4330]

2 hours ago, Spaceboy said:

not what was asked for though, is it? we just want a simple way of calling a local program on the start of a recording. no faffing about with the user writing an additional script or executable. the comskipper plugin needs this support especially as scripterx has been broken

Got ya.  I was thinking in context of this thread. Had it been in Live TV I'd have seconded it.
Definitely all for a simple method to use for recordings that anyone could use to kick off a little script!

[ChrisHammond56 4]

I agree with @maegibbons in that we don't want to complicate things. I have already provided what I thought was a solution with the pre-Record and Pre-TV illustrations. However, I am willing to work with what @Lukecan provide. Having said that, I can program in numerous different languages so its not too much an issue. I wonder if the WebHooks path for this is the correct solution though. Don't forget that WebHooks sends mult-part payload, and as such, most handlers will not work, and therefore the user would have to use a proxy, or code up a handler to pass the pure JSON. Jet another part that is needed....

So, I am evaluating the WebHooks path at the moment. I have an Emby WebHooks handler that parses the payload to my end point (also via WebHooks). However, I am seeing some intermittent behaviour. Emby is sending the WebHook at the correct times, but the end point is not always seeing a valid POST payload (WebHook is internal, so Internet is not the issue here). I am using the .32 Beta as a baseline. Once I have some concrete data, I will provide feedback.

In the meantime, can @Luke consider the pre-processing suggestion I made. For single/inexperienced users, that would be the preferred route.

[Carlo 4330]

There are two different conversations going on at present in the thread.

One is general functionality of webhook for complete system use.
One is strictly Live TV related for a recording getting started.

For the starting of recording that has been asked for a lot and should be added to the Live TV section just like the "post" processing hook is. That way you can fire off any type of script you want at the start of a recording.  I think everyone can see the value in this and it would be complimentary to the post processing. That will give you START and END hooks for recordings that's super easy to use. Luke already said on the last page he could add this directly to the Live TV section. We just need to make sure he understands we want the exact same things a post processing but ALSO done at the start of the recording as @Spaceboy & @maegibbons have pointed out.

Then there is everything else webhook or plugin script related. This plug gave everyone a look at what's possible via some kind of notification mechanism and it was good.  Now, many of us want more and it should be more efficient being built into Emby vs a 3rd party module. 

So let's let Luke get the first thing done and added to Live TV so we have the ability to easily run scripts at the start or end of recording.  He can think of how to factor in webhooks into the framework so they can self populate and be created automatically more or less for our use.

[maegibbons 1267]

20 minutes ago, cayars said:

There are two different conversations going on at present in the thread.

One is general functionality of webhook for complete system use.
One is strictly Live TV related for a recording getting started.

For the starting of recording that has been asked for a lot and should be added to the Live TV section just like the "post" processing hook is. That way you can fire off any type of script you want at the start of a recording.  I think everyone can see the value in this and it would be complimentary to the post processing. That will give you START and END hooks for recordings that's super easy to use. Luke already said on the last page he could add this directly to the Live TV section. We just need to make sure he understands we want the exact same things a post processing but ALSO done at the start of the recording as @Spaceboy & @maegibbons have pointed out.

Then there is everything else webhook or plugin script related. This plug gave everyone a look at what's possible via some kind of notification mechanism and it was good.  Now, many of us want more and it should be more efficient being built into Emby vs a 3rd party module. 

So let's let Luke get the first thing done and added to Live TV so we have the ability to easily run scripts at the start or end of recording.  He can think of how to factor in webhooks into the framework so they can self populate and be created automatically more or less for our use.

Agreed

[ChrisHammond56 4]

On 02/04/2022 at 22:23, ChrisHammond56 said:

I agree with @maegibbons in that we don't want to complicate things. I have already provided what I thought was a solution with the pre-Record and Pre-TV illustrations. However, I am willing to work with what @Lukecan provide. Having said that, I can program in numerous different languages so its not too much an issue. I wonder if the WebHooks path for this is the correct solution though. Don't forget that WebHooks sends mult-part payload, and as such, most handlers will not work, and therefore the user would have to use a proxy, or code up a handler to pass the pure JSON. Jet another part that is needed....

So, I am evaluating the WebHooks path at the moment. I have an Emby WebHooks handler that parses the payload to my end point (also via WebHooks). However, I am seeing some intermittent behaviour. Emby is sending the WebHook at the correct times, but the end point is not always seeing a valid POST payload (WebHook is internal, so Internet is not the issue here). I am using the .32 Beta as a baseline. Once I have some concrete data, I will provide feedback.

In the meantime, can @Luke consider the pre-processing suggestion I made. For single/inexperienced users, that would be the preferred route.

 

[ChrisHammond56 4]

Just now, ChrisHammond56 said:

 

I have been investigating the intermittent WebHooks issue, and it would seem that the problem lies with episodes that have a single apostrophe in them. Emby is substituting the ' in the string with the escape character \'. However, my WebHook parser is seeing this as an end of string.

For example, "Episode":"My Mother's Day" is literally translated to "Episode":"My Mothers' - Breakage!

I scotched the idea and decided to use a docker WebHook proxy (thecatlady/webhook). This seemed the best/quickest approach. However, after spending almost 2 days messing and thinking that the docker image had issues, it turns out that it's an issue with the format of the form-data missing the 'name' entity.  I validated the docker with Plex (sorry Emby Devs). All was working and I could see the form-data (name="payload").

This issue was reported in Jan 2020.

Content-Type:     multipart/form-data   <-- boundary missing!

Has anything been done to address this. The WebHooks seemed like a good path, but with every approach I try with Emby, there always seems to at least one 'component' missing that stops me from have a complete solution.

[Luke 37178]

On 4/2/2022 at 2:19 PM, Spaceboy said:

not what was asked for though, is it? we just want a simple way of calling a local program on the start of a recording. no faffing about with the user writing an additional script or executable. the comskipper plugin needs this support especially as scripterx has been broken

At the start or before? 

[Spaceboy 2500]

14 minutes ago, Luke said:

At the start or before? 

at the start. currently running the below command and arguments at recording start using scripterx

that is sufficient to run comskip on live tv recordings and detect commercials so they can be skipped when in progress recordings are played

[DarKni8 37]

I am glad emby is graced with developers who can create such plugins

[maegibbons 1267]

49 minutes ago, DarKni8 said:

I am glad emby is graced with developers who can create such plugins

The issue comes when the developer does not want to maintain it anymore and has not made the source available for anybody else to fix.

That is the situation in which we find ourself.

 

Krs

Mark

[DarKni8 37]

2 hours ago, maegibbons said:

The issue comes when the developer does not want to maintain it anymore and has not made the source available for anybody else to fix.

That is the situation in which we find ourself.

 

Krs

Mark

I think it's the most common problem with closed source softwares. Those which are not enterprise, you can't leave legacy behind. Unless and until it's either open source or you become INC like plex ehre you keep people on payroll and get it done. Kind of love emby but hate how its stuck in middle of plex and Jellyfin. Few example recently is jellyseerr , how quickly they were able to hard fork it and make it run for jellyfin(It works for emby also if anyone wants to try), came across python script for auto skip intro for jellyfin.

[ChrisHammond56 4]

Good evening. I have just (with baited breath) installed the .34 beta and haven't noticed any changes with respect to LiveTV. I may have jumped the gun here, but if not in this release, when are the suggested improvements coming?

From my selfish perspective, I was expecting any of the following:

1. Tuner details to be provided in the WebHooks payload. Having multiple tuners is unusable with Emby as the WebHook needs to pass which tuner was required for the playback/scheduled recording.

2. Pre-Processing for LiveTV. To clarify, a method to run a script either immediately before or as soon as a LiveTV stream is required

3. Same as (2) for a Recorded Schedule.

Did I miss any of the changes?

One thing I do note is that my scheduled recording tab has increased to include recordings that will not be recorded! Is that expected behaviour?

[Carlo 4330]

19 hours ago, ChrisHammond56 said:

Good evening. I have just (with baited breath) installed the .34 beta and haven't noticed any changes with respect to LiveTV. I may have jumped the gun here, but if not in this release, when are the suggested improvements coming?

From my selfish perspective, I was expecting any of the following:

1. Tuner details to be provided in the WebHooks payload. Having multiple tuners is unusable with Emby as the WebHook needs to pass which tuner was required for the playback/scheduled recording.

2. Pre-Processing for LiveTV. To clarify, a method to run a script either immediately before or as soon as a LiveTV stream is required

3. Same as (2) for a Recorded Schedule.

Did I miss any of the changes?

One thing I do note is that my scheduled recording tab has increased to include recordings that will not be recorded! Is that expected behaviour?

Hi,

I've got more than 10 tuners plus some m3u tuners as well.  I'm not sure why you think it's unusable?

What difference does it make what tuner did the recording?  That's not something you need to pre-process with.

Emby doesn't give you the tuner it's going to use when scheduling a recording because it has no idea what tuner will be used until the recording starts. How would it possibly know how many other uses would be using tuners when it goes to record?  It could be the first tuner or 6th tuners if 5 are tied up already. With some boxes you don't even need to request a tuner, just a channel.  If you had 3 HDHomeRun Quatros that's 12 tuners in all but one interface to make the request from.  It will then select the first available tuner for you.

What you really need and not present that I've asked for is the actual file name including path of the recording just started.  You can then use that for comskip or what-ever preprocessing you plan to do.

Does that make sense?

 

[ChrisHammond56 4]

@cayars I don't think you understand my use-case. I am using multiple receiver boxes and HDMI encoders, so only one stream is available per source compared to other M3U playlists that provide 10s or 100s of streams. To facilitate my setup in Emby, I have M3U playlists that map to each encoder, and has every channel in that playlist mapped to the URL of the encoder. However, the channel name/number is used to change to the appropriate channel on the box (via a script). That is why I need the pre-recording and pre-livetv hooks so that the channel change script can be achieved.

Now to your question about the tuner. I have multiple M3U playlists (one for each tuner). Each playlist points to a feed from a different HDMI encoder. When I click for example a channel in Emby for LiveTV, then Emby fires an event to say 'play channel BBC1', BUT it doesn't provide which M3U playlist (tuner source) the play event was fired from. So, how would the channel change be directed to the appropriate box to change the channel.  Same for recordings, when the recording starts, then Emby should be tracking which tuner source requested the recording.

Remember Emby cannot combine M3U tuner sources (unlike HDHR where the processing is done in the device itself), and Emby displays multiple's of the same channels in the GUI. So if I set a recording on the first instance of BBC1 @ 7pm, then the recording will start using the correct tuner source, but NOT provide the tuner source in the WebHook, and the channel change will not happen.

This opens up the wider issue of multiple M3U tuner sources and no Emby management of these sources that has been around for years.

[Carlo 4330]

Yes, that is a different setup then what most people would have.  I'm still not clear on why you need hooks for scheduled recordings or how a hook that you receive after a new recording has started will help you with tuning.  Unless I'm missing something all you need to do is make sure your setup works tuning channels based on the URL you have in the M3U file.

Are you encoding from a cable or satellite box? If satellite you can get digital sat tuners that capture and rebroadcast over IP. You can get them new in 4, 8, 12 or 24 channels per box for under a grand 24 channel and half that price used. You can also find these devices used with bigger security camera setups.

Something like this.

Or single unit PVRs like those from Hauppauge.  These smaller personal PVR encoders are used a lot.  With these an IR blaster is usually used to change the channel and the capture is fed to the host computer via USB3 (or internal PCI Card).  You can typically get the consumer capture device/cards from 1 to 4 captures per device.

Depending on the setup you can sometimes use HDMI passthrough and change channels via CEC making even easier. Most people will set these up in TVHeadEnd which is used to orchestrate the IR Blaster/CEC channel changes as well as receive the feed via USB3 and broadcast it out as some type of stream.

Besides USB or internal PCI capture boards there are also HDMI to IP capture devices that are half way between the first two in functionality. Typically these are single capture devices so one device per streaming channel is needed. These are usually the way to go as they make the best use of resources.  The box handles the capture, encoding and streaming to Emby Server so all TVHeadEnd needs to do is orchestrate the multicast it's broadcast to and change the channel on the box you receive the signal from via CEC or IR Blaster. Since TVHeadEnd doesn't need to stream the video or even tough it but simply orchestrate the recording it can be ran on the same NAS/PC as Emby or from a Raspberry Pi. One Pi could handle dozens of streams easily.

For this setup you would create your own m3u file with each channel having a unique multicast URL.  This allows Emby to request a URL/channel from TVHeadEnd that you setup. Emby Knows where to listen and TVHeadEnd know where to multicast/broadcast and of course know what channel to tune to via IR Blaster or CEC. TVHeadEnd also takes care of tracking each capture device you have setup to know which is busy and which is free.  

With any of these setups Emby gets an m3u file that has all the unique channels.  Each channel is listed only once.  You setup a guide for it in Emby per usual and Emby Server is happy as it works just like other tuners.  Emby just requests the channels like any other IPTV service.  You just happen to also be running the service via help from TVHeadEnd.

It might sound complicated but it's actually a rather simple process to setup and get working once you have your first capture board setup and working including IR Blaster.

Sorry for the long winded answer but that's how you would normally setup a system using capture cards instead of normal tuners or traditional m3u files.  You're also the provider of said service so that needs setting up properly to emulate a traditional IPTV service with unique streams per channel. Once the first device is setup in TVHeadEnd you can copy the profile to use for any other capture boards. 

With TVHeadEnd used this way you could easily mix in traditional IPTV as well as cable or OTA channels as well for an assortment of channels.

[DarKni8 37]

I dont understand , is this plugin not functional anymore , because if not why its present in official catalogue?

[ChrisHammond56 4]

@cayars Thanks for the very detailed information. I am at a half-way house in respect to the setup you describe. This is my setup.

                                    SkyQ Box -> DHMI Encoder (HTTP/RTSP etc) -> Provides stream as http://<ip>/0.ts

I am currently using these devices: https://www.amazon.co.uk/gp/product/B07CBMZ24P/ref=ppx_yo_dt_b_asin_title_o00_s00?ie=UTF8&psc=1

 

This, as you say, is the best setup, but does only provide one streaming source. I then have an M3U playlist including each channel that the SkyQ box can provide, but pointing to the same stream source. This is an excerpt:

#EXTM3U
#EXTINF:0 channelID="101" tvg-chno="101" tvg-name="BBC One West Midlands" tvg-id="101" tvg-logo="" group-title=""
http://<ip>/0.ts
#EXTINF:0 channelID="102" tvg-chno="102" tvg-name="BBC Two HD" tvg-id="102" tvg-logo="" group-title=""
http://<ip>/0.ts
#EXTINF:0 channelID="103" tvg-chno="103" tvg-name="ITV HD" tvg-id="103" tvg-logo="" group-title=""
http://<ip>/0.ts
#EXTINF:0 channelID="104" tvg-chno="104" tvg-name="Channel 4" tvg-id="104" tvg-logo="" group-title=""
http://<ip>/0.ts
#EXTINF:0 channelID="105" tvg-chno="105" tvg-name="Channel 5 HD" tvg-id="105" tvg-logo="" group-title=""
http://<ip>/0.ts

For each SkyQ/HDMI Encoder the <ip> is changed to match. These M3U files are added to Emby as an M3U tuner, and the channels can be displayed. At the moment I am using 2x sources (not scaled up yet!). Using 2x M3U tuners, Emby displays the channels in the GUI, but has two entries for each channel.

Emby can play/stream and record any of these channels just fine. I can set two recordings at the same time, using one channel from each channel group as it were (so in the above image, using Left BBC1 channel and right BBC2 channel. However, the stream will be just that, there has been no communication to the SkyQ box to change to any particular channel. This is where the WebHooks come in. For any LiveTV or Recording, Emby is sending all the information I require to change the channel except for which M3U tuner source was used for the request. The SkyQ boxes do not have any Remote Eye or IR Blaster facilities any more, so the script changes channel via ethernet APIs, Hence my request for a pre-livetv and pre-recording script facility. Not having those meant I had to go down the WebHooks path.

I will investigate your TvHeadEnd suggestion as that may be a solution, however that app seemed way to complex to setup, and I couldn't see any way to execute a script on tuner selection (unless I missed that?).

I really don't like having multiple 'same' channels in the GUI, and then for recordings, its a nightmare to select which tuner group to use for each recording, so I need a better solution to what I have currently, that is a fact.

FWIW. When I was using only one tuner source, the above setup works flawlessly with Emby (as I have been using it for quite some years).

[Carlo 4330]

Sounds like TVHeadEnd is what you need.  It's not really hard just seems it from the install.

You might want to try a test setup using a docker version which will make getting started a lot easier.

[ChrisHammond56 4]

Just set that up (I planned on using a docker as you also suggested), and I don't see where to execute scripts on a stream request. Does any one following this thread know how to do this quickly before I spend hours asking Google?

The setup is quite complex, but in defence of the tool, it's trying to please everyone, so I can appreciate that. It just seems a travesty that we using a sticking plaster on a bigger issue. Emby already directly supports the playback/recording of M3U playlist entries, but to get something as simple as an execution script (that already exists for post-processing) is really baffling me.

Can we get some feedback from @Luke or the Emby Devs as to why my proposed solution is not workable. I know I am not the only one requesting/wanting the pre-livetv and pre-recording (or to be more accurate 'at-livetv-start' and 'at-recording-start'). Why is there reluctance?

[Anthony Musgrove 201]

Hi guys, I'm in the process of setting up my new dev environment.  Just having an issue with referencing the latest Emby.LiveTV.dll as a project reference (Unsupported) VS2022, so I'm working on it.  I've got Covid at the moment so I am a bit slow with replying.

It's possible that the issues with live TV has something to do with the DLL referencing maybe its unsupported now, I'm working on it.  I need to get more involved in the project again as i've had to take a hiatus.

Comments, feedback, suggestions, I need a list of things that need to be resolved, please add to the github issues list.  Thank you.

[Anthony Musgrove 201]

 

So as you can see here, Emby.LiveTV (the DLL that I reference to to access EmbyTV) isn't accessible at the moment in my new dev environment, possibly either my problem, or the DLL..  so thats the issue I'll need to overcome, then release.. 

[Luke 37178]

2 hours ago, Anthony Musgrove said:

 

So as you can see here, Emby.LiveTV (the DLL that I reference to to access EmbyTV) isn't accessible at the moment in my new dev environment, possibly either my problem, or the DLL..  so thats the issue I'll need to overcome, then release.. 

I would suggest not referencing it at all and just use the nuget packages.

[Anthony Musgrove 201]

18 hours ago, Luke said:

I would suggest not referencing it at all and just use the nuget packages.

 

Alrighty, well I will need some assistance here..

 

The only reason I reference to the Emby.LiveTV dll, is so that I can cast the ILiveTvService as the type EmbyTV, such that it allows me to subscribe to two events that are otherwise unavailable as the initial ILiveTvService type -- RecordingStarted and RecordingEnded. 

this._embyTv = (Emby.LiveTV.EmbyTV)lts;
this._embyTv.RecordingStarted += _embyTv_RecordingStarted;
this._embyTv.RecordingEnded += _embyTv_RecordingEnded;

 

As you can see, if I were to try to subscribe to these two events, they do not exist in the ILiveTvService interface:

 

 

Is there another way I can subscribe to these events? 

 

Thank you.

 

The references to the old LiveTV dll will no longer be required due to Luke's amazing work with providing the appropriate access and functionality into the nuget packages, this access didn't exist at the time of writing the initial LiveTV functionality (back in 2020)

 

Edited April 17, 2022 by Anthony Musgrove

[Anthony Musgrove 201]

I've managed to remove the reference and readd the latest, and its working again

 

The references to the old LiveTV dll will no longer be required due to Luke's amazing work with providing the appropriate access and functionality into the nuget packages, this access didn't exist at the time of writing the initial LiveTV functionality (back in 2020)

Edited April 17, 2022 by Anthony Musgrove

[Anthony Musgrove 201]

** If everyone can please upgrade to v3.0.5.5 on the official catalog, and report EVERY single issue in the Github Issues list and I'll get a team together asap.  Thank you guys