DVBLink-TVMosaic Live TV Plugin

[pünktchen 1251]

@emveepee maybe you could code a Kodi pvr addon for Emby? Of course not for free. The Emby team is also paying other devs for their work. @Luke

[emveepee 112]

We discussed it three years ago, and it isn't rocket science, it just takes a little time.  It was a more interesting project when Emby was considering becoming a real PVR backend rather then a  proxy.  Most people will just use the free backend since they still need to run.

Martin

[pünktchen 1251]

Please think about it again. I would do it myself if it were C# and not that C++ mystery.

Edited May 24, 2022 by pünktchen

[Carlo 4330]

45 minutes ago, pünktchen said:

Please think about it again. I would do it myself if it were C# and not that C++ mystery.

I'd prefer C, then C++ then if I have to C#
C# today is more like using Basic compared to the C Language. Makes for some really sloppy programming.

[Luke 37022]

18 hours ago, Slini said:

@Luke I am also using KODi, if I plan a recording in KODI, it synchronize and shows up in TVMosaic and also if I plan it on TVMosaic it shows up in KODI.

But Emby does not synchronize at all, not with TVMosaic nor with KODI. For me it looks like more that TVMosaic and KODI handles the recording. 

With DVBLink plugin it worked perfectly, that's why I am a bit confused now. Is it planed to make the DVBLink plugin work again. If yes i will just wait until i can install the DVBLink Plugin again and uninstall the TVMosaic then.

Thank you

Yes I certainly can port the DvbLink plugin. I just wanted to see that was actually demand for it first given that the underlying software is defunct.

[emveepee 112]

11 hours ago, Luke said:

Yes I certainly can port the DvbLink plugin. I just wanted to see that was actually demand for it first given that the underlying software is defunct.

To avoid continued confusion are you offering to port the plugin to the new limited API, or are your revisiting the API change to allow PVR changes in Kodi and the backend clients to show up in Emby as the user requested?

[Carlo 4330]

It would need to use the new framework like any other TV plugin for 4.7 onward.  That's what he meant by "port".

[emveepee 112]

I thought (hopefully) he meant port the LiveTVServer class back from 4.6.  So the answer rather than the strong yes is actually no you can't make it work like the user wants with Kodi and TV  Mosaic, but you can make the plugin use the new API to work with Emby.

Martin

Edited May 24, 2022 by emveepee

[t.andre 69]

Good evening,

The idea of having a single backend is good.
But unfortunately, for many people mainly in Europe, we have TV boxes and it can be complicated to manage both systems for recordings.

That's why I'm going to stay on version 4.6.7

Wouldn't it be possible to adapt the plugins so that they can communicate directly with the new backend?
If it's possible I would modify the DVBLink and TVMosaic plugins.

 

[Carlo 4330]

54 minutes ago, t.andre said:

Good evening,

The idea of having a single backend is good.
But unfortunately, for many people mainly in Europe, we have TV boxes and it can be complicated to manage both systems for recordings.

That's why I'm going to stay on version 4.6.7

Wouldn't it be possible to adapt the plugins so that they can communicate directly with the new backend?
If it's possible I would modify the DVBLink and TVMosaic plugins.

 

If you think it's complicated to manage think about what Emby had to do previously.  It had it's own scheduling and recording and so did DVBlink so that's two different ways Emby had to deal with, err make it 3 counting TVMosaic.  Oh wait there's like 6 others.

What you end up with is something that looks like a tree where the trunk is Emby Core, but then there are all these other branches that do things differently. You end up having to be able to manage a dozen different schedules, different ways each records, different disk location to find them, different guides, etc. Any place that files can be stored is a possible complication to Emby permissions.  If you wanted to add Commercial Cutting or Marking to recordings and be able to start processing the files while it's recordings you have quite the project in store for you. Since the other system is doing the recording you may not be able to write anything since it's potentially locked. You may have different containers being used that change how something like comskip works. You may need to save the EDL file with the media for one system but not be able to keep it with the media in another.  That's assuming you can even run comskip against the recording.  Since Emby isn't doing the recording it's not in charge of the format used or what the GOP boundaries looks like or the iframes.  So again you have to adjust code for each system and potentially have 12 different resulting versions of combinations of GOP & frame boundaries.  Some clients may play one version fine while have an issue with another plugin version's recordings.  So now additional changes need to trickle down to the client level OR the system needs to transcode/remux the file for specific clients to get it back to a format the client can use.

Live TV is plenty hard enough just have the different formats to deal with that each region uses:

and dealing with differences such as Subtitle use vs Closed Captioning. Of course they have different frame rates and resolutions as well.  So normal Live TV is hard enough without complicating this with 12 potentially different ways of doing each of these things.

Now switch the model so the plugin/backend system isn't responsible for doing any recording or choosing formats to use.  In general you only need the plugin to give you a list of channels and then be able to feed you a stream when you ask it to without helping you and doing it's own transcoding or anything else.  That's essentially what the new framework does.  It removes all the different ways the media gets handled/changed out by it's simplicity. As long as the plugin can give Emby the channel list info and can stream the channel to Emby when asked for it untouched that's all it needs to do now. It can optionally give Emby guide info but not a requirement.  Emby now has one set of code to handle recordings all using the same format across the board.  It knows where this information is stored.  It's know it's not locked and clients can access the file while being recorded, etc

It's now going to be much simpler adding new features like commercial marking because the files are all using a form you created for it and have control over.  Writing the code is easier, testing it is easier. The whole process is easier.  It's also far easier to add new types of tuners because your not worried about creating yet more potentially different versions/formats but instead just filter the streams right into the current pipeline.

There will be some "growing pains" from the change that are going to be very difficult to address like what's mentioned trying to use two different systems to set recordings and scheduling in.  Frankly Emby needs to get away from that and not worry about it because it's not an Emby problem.  That's harsh sounding I know but Emby needs to think about the plugin being "just another dumb tuner" and not worry about sending information to it for it's use.  The job of the tuner is to supply information to Emby, not the other way around.

So essentially you have one system being used as a tuner for potentially 2 different independent systems. That's really the scope of the change. What you schedule in Emby is done in Emby.  What you schedule in NextPVR, TVMosaic or any other PVR stays with that PVR.  Think of them as being 2 different systems and you wouldn't expect them to share information or be aware of each other.  Honestly this is going to be a problem for a very minor amount of people.  Most people I work with that have a PVR setup besides Emby is using it as a tuner for Emby and doesn't directly use the other system.  I did say most not all because I do know some use both systems but it's the minority.  Some of them use Kodi where they can't possibly enter recording schedules with that client.  One person told me not a big deal, they'll just use Emby to setup their show recordings for the year but may still use Kodi to record movies or a single sports event. They won't see the schedule but will get the recording showing up in Emby.

Hopefully as Emby keeps getting better and better you won't want to use a different system.    Some of the plugins/PVR system may not be needed in the future. A great many people use another system because their tuner isn't directly support by Emby.  That's part of the change to make it easier for us to add new tuner types. Hauppauge and/or BDA based tuner drastically reduces the need for outside tuner support.

The lack of actual Emby TV support in Kodi is a real issue that if reconciled would be welcome I'm sure for those who use Kodi.

So we know there will be some small growing pains do to the change and we've tried to keep these to a minimum. We're not saying "tough" that's the way it's going to be.  Just saying it's part of the growing pain of a change like this.  We can and will try to minimize issue like this when we can or try and help in ways we can but we need to keep pushing Emby in the direction that makes sense for Emby architecture so that more features can be added as well as make changes to improve things here and there much easier!

[t.andre 69]

It was not a reproach or a criticism that I made; it was a proposal.
It is not viable but at least it was made.
Speaking of my case but certainly others who have paid for a license are in the same situation.

Have a Hauppauge card that I had to remove from my computer because Hauppauge hardly ever updates its drivers anymore and this causes a problem with new operating systems like Windows 11.
Had to replace it by a Vu+ which is a box that contains its own operating system and storage but not enough performance or incompatibility with Emby.

Not everyone is going to spend extra money on storage for TV recordings, and only be able to use half of it for example, because the box's storage will remain unused if you use the Emby recording system.

But as I explained, this is only my point of view.

Thanks for the information provided.

[pünktchen 1251]

@cayars I have not the time currently to write a long and detailed answer, but most of the things you've written here and also in the NextPVR thread about how complicated it was for Emby to handle the different tv plugins is just totally nonsense! Especially something like this "You end up having to be able to manage a dozen different schedules, different ways each records, different disk location to find them, different guides, etc.", because Emby never had to care about this, it were the plugins that had to adapt to Emby.

[emveepee 112]

@pünktchenthat post made no sense to me either.  Kodi doesn't have any backends yet it is able to handle 20 different backends with one API, after all that's why API's exist.  The issue is probably Luke has to manage all these plugins now, but I guess it was that or complete NextGen TV real.  I was quite  happy keeping NextPVR running and supporting it before it got gutted. 

As for comskip that example seems like a snow job.   It is not "new" I purchased my copy in 2012 but was using it with NextPVR before that and Kodi added EDL API support seven years ago so many clients already support it.  Passing a raw EDL file or filling a new Emby class would probably take about as much time as writing that "explanation"  Emby didn't even have to add EDL support for addons.

 

[Carlo 4330]

Sorry guys but I disagree with you. I know from doing support how different the plugins work causing all kinds of little issues. One plugin on a guide refresh doesn't clear out channels that have been removed while the other does.  User never thought to look and verify the guide is empty, makes a channel lineup change then adds this tuner back. Looks at the guide and there is bad info.  Refreshing data doesn't get rid of it.

Remove both, refresh guide, wait until all records are removed. Functionality in plugins different.  There was a couple things like that. Differences in streams, difference in where and how recordings were saved.  These topics come up enough they should sound familiar. These kinds of differences shouldn't happen with the new framework because the plugin does do these thing any more. Besides supplying a channel list and optional guide take when asked the plugin has but one other job. Supply a channel stream when asked for it. Everything else is handled by Emby and will work the same removing these kinds of issues.

emveepee, the age of comskip has nothing to do with it.  I too have used it for a long time back to Myth/BeyondTV/SageTV days. My point is that when plugins are in control the server often had many different things to do.  If a recording is done with 3 different backends do you think all 3 wrote it the same? Three different places where the recording took place. Multiple possible outcomes if you try to use a file that open belonging to another program. Of course any difference in format is always going to have more potential client issue.  That of course makes trying to implement comskip harder.  2 or 3 tests with the new framework and you know if it's working or not.  With the old plugin the recording could be indifferent locations, have different permissions. Could be on another computer where the PVR runs. Doing 2 or 3 test even if working correct doesn't give you an indication it's going to work.  You don't know until you've tested each combination. That's the "hard" I'm referring to. Part of the "hard" is taking longer to test as well as have more things to test.

[emveepee 112]

I totally agree the LiveTV API in Emby was far from perfect and the code was stale, but I blame Emby side not the plugin.   The old API if Jellyfin is even worse.  Kodi doesn't have any issues with the integration and can cache EPG so only deltas are saved.    I think Emby is lucky that pirate IPTV became the focus for so many users that the warts have been masked.  The mediaitems table is also a bit of a  mess but there should always have been a way to clean PVR.

Given that Emby still can't automatically map the 4.7 database to Emby data and leaves tuners hanging I feel the new Emby solution remains far from perfect.

For EDL support I was certainly not suggesting the addon should be in control, just pass the EDL information to Emby as the addons do to Kodi and simply let the Emby player manage the seek logic.

Martin

 

 

 

Edited May 25, 2022 by emveepee

[pünktchen 1251]

26 minutes ago, cayars said:

I know from doing support how different the plugins work causing all kinds of little issues. One plugin on a guide refresh doesn't clear out channels that have been removed while the other does.  User never thought to look and verify the guide is empty, makes a channel lineup change then adds this tuner back. Looks at the guide and there is bad info.  Refreshing data doesn't get rid of it.

And i'm a developer of three live tv plugins and can tell you that this is nonsense. The live tv api didn't even had a method to remove channels. That was and is still Emby's job at the time of the guide refresh.

27 minutes ago, cayars said:

Differences in streams

And you think that has changed now? With old api and the new api nothing has changed here. The streams from the plugins are still the same. Only the method that is requesting the stream has changed, not the routing of the stream in Emby. The handling of the stream data is still the same. It was and is in Emby's responsibility.

37 minutes ago, cayars said:

difference in where and how recordings were saved

All plugins did only provide a stream link to the recording. Where they were saved in the backend did not matter.

[Carlo 4330]

7 hours ago, pünktchen said:

And i'm a developer of three live tv plugins and can tell you that this is nonsense. The live tv api didn't even had a method to remove channels. That was and is still Emby's job at the time of the guide refresh.

And you think that has changed now? With old api and the new api nothing has changed here. The streams from the plugins are still the same. Only the method that is requesting the stream has changed, not the routing of the stream in Emby. The handling of the stream data is still the same. It was and is in Emby's responsibility.

All plugins did only provide a stream link to the recording. Where they were saved in the backend did not matter.

Install your 3 plugins. Add different m3us and load everything up in Emby.
Remove some channels from each m3u and refresh the guide.
Remove the 3 m3u files and refresh the guide.
Tell me if you get the same results.

Add the same channel to all three plugins but make a change so they all load.
Record the same 30 minute show on all three at the same time.
Look at the format of each when complete and tell me they are the same.

No your wrong on the guide update and I think you may see this.  I think one of them will not allow the guide to be cleared unless you completely remove the plugin.

There's lots of goofy difference like that all over that the new format gets rid of.
Please don't think I'm saying the plugins are crap or anything like that.  I'm simply saying they work differently. Luke has had to make change to accommodate one plugin that's caused issues with another.  You can read many time the guide not clearing if the plugin isn't removed.  Again I'm not pointing blame at anyone.  That could be bug in something done by Luke for a tuner.  My point is that one plugin being present won't allow the guide to clear, while another plugin can still be installed.  They work differently in little ways and that's what I was referring to about it being "hard". You have no idea if every is going to work correctly after making a change and can't test 4 that work great and assume the other 8 will.  Old style you don't know it works until you test it.  With different code surely you get and understand that.  I know you understand the difference something as simple as 3 different PVRs all doing recording their way vs one PVR doing recording the same way.

[emveepee 112]

Everything I read there points to the Emby backend.  Many times during development I had to delete  library.db or mediaitems to get things to match what the API was loading.  That is as good a reason as any for getting rid of the old style plugins.

I disagree however that you can assume that recording will work better with the new approach.  Schedules recordings now won't fail or generate conflicts until recording time because Emby assumes unlimited tuners.   As released Emby is not always releasing tuners from NextPVR either so more recordings and live TV will fail.  This is not a new problem for Emby PVR users, but it is for NextPVR users.

 

[toon 3]

How about working with the system TVMosaic. I need this to set up channels and decrypt these from digital devices tuners. So I don’t see a way of working without TVMosaic. 

If I look at this API it is possible to get a M3U list from TVMosaic. http://www.dvblogic.com/download/tvmosaic/tvmosaic_remote_api.pdf

Also the guide EPG data can be extracted from TVMosaic API as a XMLTV file. 

It seems to me a possible solution for the TVMosaic users is the possibility to enter the TVMosaic API data. Emby can use their standard M3U /XMLTV set up and act as DVR only using the streams from TVMosaic. TVMosaic will only serve as tuner for the streams Emby uses to record or show as live tv. 

[Carlo 4330]

16 hours ago, emveepee said:

Everything I read there points to the Emby backend.  Many times during development I had to delete  library.db or mediaitems to get things to match what the API was loading.  That is as good a reason as any for getting rid of the old style plugins.

I disagree however that you can assume that recording will work better with the new approach.  Schedules recordings now won't fail or generate conflicts until recording time because Emby assumes unlimited tuners.   As released Emby is not always releasing tuners from NextPVR either so more recordings and live TV will fail.  This is not a new problem for Emby PVR users, but it is for NextPVR users.

 

Development is different than use or testing of course. As a dev you often wack data, change something in code, rebuild data etc.  But once you have the correct data flowing you would of course want to switch back to an untouched database. Switching hats from Dev to QA/Testing wouldn't allow using a modified database but one created only with code used as a normal user.  If you see mismatches in input to output at this stage in  testing you have a bug/issue that needs to be solved vs changing data to match. That could be a plugin or Emby bug. As a developer you know first hand how different you could write EPG handling code in each plugin which Emby would use. You had control over what data is loaded or not. In the new framework you just supply the basic information that best matches the standard XML data format.  Emby then loads it consistently regardless if the data came from a plugin, XML downloaded guide source or from Emby's upstream provider. You no longer have control over the guide data ultimately used because the customer can replace the data your plugin supplies at will. That's one of the key upgrades that comes with the new plugin framework.

You can't assume it will work "better" but can assume it will work "consistently" which is different. Knowing you have consistent results from changes you make allows you to make it "better".  3 different plugins the old way doing a recording might give you three different formats on disk.  3 different plugins giving the stream to Emby who does the recording produces 3 files using the same format. The could have different content (ie 2 audio stream in one file, 1 in another) depending on what data the plugin send, but it's saved using the same format. The more consistent the pipeline is from start to finish the less chance of breakage or strange outcomes.

Scheduling is a whole different topic but I agree with you here. Emby doesn't have a scheduling engine to speak of other than ok we'll "try" to record this using the criteria.

10 hours ago, toon said:

How about working with the system TVMosaic. I need this to set up channels and decrypt these from digital devices tuners. So I don’t see a way of working without TVMosaic. 

If I look at this API it is possible to get a M3U list from TVMosaic. http://www.dvblogic.com/download/tvmosaic/tvmosaic_remote_api.pdf

Also the guide EPG data can be extracted from TVMosaic API as a XMLTV file. 

It seems to me a possible solution for the TVMosaic users is the possibility to enter the TVMosaic API data. Emby can use their standard M3U /XMLTV set up and act as DVR only using the streams from TVMosaic. TVMosaic will only serve as tuner for the streams Emby uses to record or show as live tv. 

That looks like you could set a cron job up to pull both m3u and xml data from TVMosaic adding them as standard m3u/xml sources in Emby.
I would definitely give that a try.  Have to tried it?

[toon 3]

18 hours ago, cayars said:

That looks like you could set a cron job up to pull both m3u and xml data from TVMosaic adding them as standard m3u/xml sources in Emby.
I would definitely give that a try.  Have to tried it?

 

I did this manually now and it works perfect. I have EmbyTV working now as you designed it for us.

So I pulled the M3U list. This is a one time job as long as channels are unchanged of course.

EPG needs to be done a couple of times a day ideally and I do this manually now, not ideal. This needs to be automated as a download and replace task on my server.

 

Would be great if Emby server could do this for us, this would solve most problems for DVBLink/TVMosaic users.

This way Emby TV can be used with a much wider range of TVTuner devices which are already solved by the software of our friends of DVBLink in the past.

[Carlo 4330]

@toon What country do you live in?

The manual process you refer to for EPG, is this something you do for TVMosiac?
Is/can it be done from the command line?

[toon 3]

I’m Dutch,I hope you can understand my English
You can see the procedure in the API manual in my previous manual. The manual action is getting the EPG from Tvmosaic

[leone007 1]

Might be a stupid question.

I am using tvmosaic CE, with custom ffmpeg, full cuda pipeline for decode, deinterlace, scale, hevc encode, now it works great with Kodi, but I'd like to use it "through" emby, so I can watch full framerate content in browser. 

Is there a way (preferably client side like the kodi add-on) to set  tvmosaic server transcoding (on/off), bandwidth and dimensions?

Thanks.

Edited June 7, 2022 by leone007

[Luke 37022]

On 6/7/2022 at 11:43 AM, leone007 said:

Might be a stupid question.

I am using tvmosaic CE, with custom ffmpeg, full cuda pipeline for decode, deinterlace, scale, hevc encode, now it works great with Kodi, but I'd like to use it "through" emby, so I can watch full framerate content in browser. 

Is there a way (preferably client side like the kodi add-on) to set  tvmosaic server transcoding (on/off), bandwidth and dimensions?

Thanks.

Hi, if you import into emby server, transcoding is off and emby will handle it as needed