Jump to content

How to build the EMBY EPG using JS


VicMoore

Recommended Posts

pünktchen

Seems Id and Type is the same and also the same that will then be listed in the selection dropdown of the guide data source setup screen. The question is if the dropdown will only list "known" types or also custom ones?

Link to comment
Share on other sites

BillOatman
7 hours ago, softworkz said:

It's not about anxiety - it's just not an acceptable way of interaction. 

Anxious -  "moved by a strong and urgent desire or interest,"  Not anxiety :)

Link to comment
Share on other sites

Just now, BillOatman said:

Anxious -  "moved by a strong and urgent desire or interest,"  Not anxiety

As non-native speaker, I might not be aware of all cases of usage - although Google Translate tells exactly the same as what I thought these two words would mean, including the fact that it's the same word in two forms, once as noun and once as adjective. So I'm confused...

image.png.91c3b0270a6869705e92c015c33ab8b9.png

 

image.png.135438a9ce4a0b1081eac6c090f6414f.png

 

Link to comment
Share on other sites

11 minutes ago, BillOatman said:

Anxious -  "moved by a strong and urgent desire or interest,"  Not anxiety :)

Ah - you meant anxious in the sense of positive excitement, right?

Link to comment
Share on other sites

VicMoore

@BillOatmanproposed earlier a possible easy solution that works for everyone. 

1) under LiveTV, add M3U as a tuner source (done only once)

2) provision the added M3U tuner with a local file path (done only once)

3) Create a m3u file with the desired EPG data and write that data to the local file (done each time you want to change the EPG)

4) Through the ApiClient force the M3U tuner to load and process the local file (done each time you want to change the EPG)

5) The Emby EPG is now modified to agree with the m3u file

@softworkzwhat do you think?

Vic

Link to comment
Share on other sites

pünktchen

All wrong, because you don't want a tuner source but guide data! So not a m3u playlist but a xmltv file. But the xmltv file (plugin) doesn't know about the properties that VirtualTV needs to be able to play the Emby library items.

Link to comment
Share on other sites

VicMoore

@pünktchenI think you are enjoying this. You owe me nothing. You are within your rights to withhold information about writing content to the EPG.  You win !!!!   I want ask you anymore questions.   I enjoy programming and have the time and resources to contribute to the Emby community.  That's all I was trying to do.  I know you are a good person.  I extend my hand of friendship and will move on.  I have many things I can do in my life other than Emby.

Your friend, Vic

Link to comment
Share on other sites

pünktchen
1 hour ago, VicMoore said:

I think you are enjoying this.

No, not at all. I just want to save you from investing time in things that will not help you. Probably we are different in this regard, but i don't have fun in learning if the outcome doesn't give me any success. And tuners will not give you success. You want guide data, not channels.

 

1 hour ago, VicMoore said:

You are within your rights to withhold information about writing content to the EPG.

I can't hold back what I don't know about, and apparently neither can softworkz. See me assumption about the api endpoint livetv/program. That was wrong obviously, because i didn't know it. Or my idea about the C# interface IListingsProvider. I don't know if it will work, because i've never used that and there's no public available source code that can be used as a sample. I only know that everthing with a tuner source is the wrong approach. Emby even doesn't allow you to map the integrated guide data from one tuner source to an other tuner source! And i already mentioned the problem with xmltv files.

So you can't blame me for not trying to help. At maximum you can only criticize about my short answers. That's because i'm just to lazy to write lengthy explanations if it doesn't change the result.

Link to comment
Share on other sites

BillOatman
15 hours ago, softworkz said:

Ah - you meant anxious in the sense of positive excitement, right?

Yeah basically that team emby would probably not think it was a good idea to publish the schema so that people can change the data (and maybe mess it up and blame emby).

I am a software developer and we had a customer once start asking questions about our products schema ... next release the majority of the database was encrypted :)

Edited by BillOatman
Link to comment
Share on other sites

2 hours ago, BillOatman said:

Yeah basically that team emby would probably not think it was a good idea to publish the schema so that people can change the data (and maybe mess it up and blame emby).

I am a software developer and we had a customer once start asking questions about our products schema ... next release the majority of the database was encrypted :)

I think we have no intentions to go that far. We also don't want or need to hide the data. Users who want to read the data for further processing elsewhere are welcome to do so, and the schema can be understood with some effort, even though it's not really an Entity Data Model "by-the-books" (probably for historical reasons).

Emby Server is using exclusive locks on the DB files, so you cannot access them anyway while Emby Server is running. Making modifications while Emby Server is stopped is unsupported. That means, in case we notice that this has happened, users can expect no help from us and the recommendation will be to re-setup Emby Server from scratch.

From the perspective of an application developer this means that if you would offer any extension, companion or plugin solution which makes changes to the database directly, you would be responsible for screwing users servers, so I hope this makes it clear enough that it is not something to even think about.

Edited by softworkz
Link to comment
Share on other sites

8 hours ago, VicMoore said:

@softworkzwhat do you think?

I appreciate your effort to and enthusiasm to provide added value to Emby users and I always welcome new ideas and development of new Emby Server plugins, that's why we spent effort and time into building and publishing the new Emby SDK and the Emby Dev Website, even in two flavors (stable and Beta).

Regarding this particular subject though, I don't think it is worth pursuing right now. With the arrival of TVnext, all these things will be invalidated because TVnext is a full replacement to the live TV part of Emby Server. Even @pünktchen's plugin won't work anymore in its current form. Due the fact that it's a popular plugin used by many, we have committed to assist him in migration and provide a way to achieve similar functionality in the context of TVnext.
The general line though, is to stop having pseudo-channels in the guide which do not reflect linear timed tv programming (for example "vod channnels" - we'll have something much better for them), which allows us in turn to provide much better handling and support for TV channels with features that weren't possible so far.

In the case of EPG data for a digital TV channel there will be 4 stages at which that data can be updated:

  1. Full EPG Data Import (e.g. from Emby EPG Data)
  2. Late Breaking Changes data import (in case of Emby EPG Data) - every 4 or 6h covering only the next 6h
  3. In-Band EPG data (from data included in the TV signal) - merged with data from 1. if available
  4. In-Band Current/Next data (from the TV signal about current and next program) - used if no other data available, otherwise used to adjust start and end times of existing data

Currently, Emby does only #1. TVnext does all 4 (if available). Doing so requires a complex logic where the application (Emby Server) needs to be in full charge of. That's why I said that even TVnext doesn't provide any interface to modify the EPG data.
But what it will officially allow is creating custom EPG providers - and of course tuner providers as well. You'll also be able to create a plugin with a tuner provider AND a related EPG provider where the tuner channels will be automatically matched to the EPG channels from the EPG provider. The requirement for the tuner provider though, is to provide channel data as TV broadcast streams (MPEG2-TS). 

My advice for you at this time would be to wait a bit and re-assess your idea once this is available in beta.

Link to comment
Share on other sites

VicMoore

@softworkzThanks for the advice.  I will wait as you recommend.  You have always been helpful.

Vic

  • Like 1
Link to comment
Share on other sites

arrbee99
1 minute ago, softworkz said:

Just rebased to the latest beta few days ago..

Got lots of space on my 😄 drive...

  • Haha 1
Link to comment
Share on other sites

Spaceboy
5 hours ago, softworkz said:

Just rebased to the latest beta few days ago..

is there genuine hope we may at last see this in 4.9 then?

Link to comment
Share on other sites

7 minutes ago, Spaceboy said:

is there genuine hope we may at last see this in 4.9 then?

I would say no, as for the fundamental nature of changes it should be a 5.0 IMO.
(please note how elegantly I avoided to say anything useful 😉 )

  • Haha 4
Link to comment
Share on other sites

A more serious answer:

  • The primary question is not about when it will get into stable, it's about when it will get into public beta
    • That's the next required step
    • Realistically, a duration of at least 6 months in public beta is required
      (4.8 is pending for 2 years now, even without a major feature change)
       
  • TVnext is switchable via command line switch now
    which means
    • It won't be required to make a hard switch from one beta to the next
    • The experience of beta users won't be disrupted - they can choose a point in time to look into migrating
    • Switchability is not meant to be a mechanism for stable, but it's perfect for the betas.
    • Eventually, this invalidates arguments and concerns around transition, compatibility and possible risks involved
      all transitioning can happen smoothly,
       
  • I hope that we can get into a public TVnext beta after the 4.8 release - it's really time to go forward now
  • Like 4
  • Thanks 1
Link to comment
Share on other sites

Spaceboy
4 hours ago, softworkz said:

A more serious answer:

  • The primary question is not about when it will get into stable, it's about when it will get into public beta
    • That's the next required step
    • Realistically, a duration of at least 6 months in public beta is required
      (4.8 is pending for 2 years now, even without a major feature change)
       
  • TVnext is switchable via command line switch now
    which means
    • It won't be required to make a hard switch from one beta to the next
    • The experience of beta users won't be disrupted - they can choose a point in time to look into migrating
    • Switchability is not meant to be a mechanism for stable, but it's perfect for the betas.
    • Eventually, this invalidates arguments and concerns around transition, compatibility and possible risks involved
      all transitioning can happen smoothly,
       
  • I hope that we can get into a public TVnext beta after the 4.8 release - it's really time to go forward now

sounds great. look forward to engaging with the beta again.

in answer to a question on another thread, i believe tvnext will be emby's usp when implemented

  • Like 1
  • Agree 1
Link to comment
Share on other sites

23 hours ago, Spaceboy said:

sounds great. look forward to engaging with the beta again.

in answer to a question on another thread, i believe tvnext will be emby's usp when implemented

Not everybody believes in that - but I do.
I can't say whether it will have a sensational or just moderate effect, but at minimum it will be solid and noticeable. 

When looking at history it's a kind of weird picture anyway: MB started as a companion to WMC, which was strong in TV but had its shortcomings in management of non-tv media. WMC was architected for local single-user deployment (with a flaky extender concept). MB filled all those gaps but when WMC fell out of the picture, it couldn't provide an adequate replacement for the live TV part (well - it's a complex subject without doubt).
Some say - nobody would be interested in all those TV features as the world has moved on and nobody would want these things anymore, rather looking for "modern apps" which are like "N-flix" and Co. - I'm sure the latter part is generally valid, the world is changing rapidly in many ways. Broadcast TV - somewhat - but not that fast, it's still a strong component in media consumption all over the world and what I doubt strongly is that nobody would be interested anymore in a TV experience like WMC had offered. It's rather that nobody's doing it because there is nothing like it available anymore. Many half-baked solutions exist, some better some worse but nothing getting really close while at the same time covering all the new "more modern" demands.

To me it even appears to be that the market of TV applications is very similar to the pre-WMC situation. Everything a bit more advanced, but there are those single/local TV apps (like DVBViewer etc.) which still do the same like they always did, and then there are some more htpc-style applications but each with their own sets of drawbacks and weaknesses.

Regarding the latter ones - Emby is way better than every single one of them.....if you don't count TV.....

This is what TVnext is intended for making a change to: getting ahead of the competition in the one area which has always been its weakest.

Edited by softworkz
  • Like 1
  • Agree 1
Link to comment
Share on other sites

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