Unified PVR frontend (DVR/HTPC client GUI with EPG) and Addons API for PVR backends?

alcoheca Wrote:Because of the way many people use televisions a more immediate link to the TV guide and live TV might appease many non-geeks like ourselves. The option to flick at will and pull up the EPG easily would suit many people (excepting myself).

Adding support to the keymap for this woud also be apprieciated. For those with MCE remote and I for one always used "Recorded TV" to bring me directly there with a flick of a button, same with EPG and LiveTV. But that is the least of the work ahead

Topfs2 Wrote:Adding support to the keymap for this woud also be apprieciated. For those with MCE remote and I for one always used "Recorded TV" to bring me directly there with a flick of a button, same with EPG and LiveTV. But that is the least of the work ahead

I'm sure that this will be incorporated into the list of outcomes for the feature suggestion.

(while on the subject I shall write one up, thanks to Gamester17)

I've added some ideas to the wiki

Should the epg not come from the pvr backend? It seems like it would be for more efficient as my pvr grabs live epg data straight from the dish network satellites.

nate12o6 Wrote:Should the epg not come from the pvr backend? It seems like it would be for more efficient as my pvr grabs live epg data straight from the dish network satellites.

The EPG is the TV-Guide GUI so that should be in XBMC as part of the frontend, so no, but what could come from the backend TV-server is the XMLTV listings.xml (which the GUI will parse and display on the screen as programs and times).

But XMLTV listings.xml could also be downloaded from the internet. So best is just to aim for a EPG which can parse the XMLTV format and display it as a TV-Guide, then the matter of getting the listings.xml files is really separate project as it could be done in several ways (for now we should probably just use python, then later it might be good idea to evaluate a new method like for example extending XBMC's scraper engine, but that is a different discussion that should be discussed in a separate thread).
http://xmltv.org/wiki/

nate12o6 Wrote:Should the epg not come from the pvr backend? It seems like it would be for more efficient as my pvr grabs live epg data straight from the dish network satellites.

Yes freeview in the UK uses EIT aswell which means no XMLTV which i loathe anyway... only a 7 day EPG but i dont care whats on next century

well xmltv as a base is still fine. if we use EIT it's still up to the backend to grab the data as we can't lie and watch mpeg stream all the time. so it must store it in some other format.

i have no problem in adding xmltv output support to our cmyth based filesystem (ie open a special url and you get a xmltv file), even if mythtv stores recordings differently in a db.

C-Quel Wrote:Yes freeview in the UK uses EIT aswell which means no XMLTV which i loathe anyway... only a 7 day EPG but i dont care whats on next century

I'm not sure how it is these days, but the UK EIT EPG used to be pretty poor, with no genre information, detailed description etc. And I'm not sure 7 days ahead is such a great service.

I always found the RadioTimes data to be much more suitable, but isn't this all irrelevant anyway, as each individual module could deal with EPG in a different way? EIT is favourable because then we can get updates to program start times etc. This would have to be be dealt with by the PVR app, updating our EPG minute by minute.

By the time the data gets to the GUI, which we're talking about here, it will probably already be in binary format, objects based on a class that we create. (Passed internally from module to frontend.)

Although eit over the air is not as extensive as with Schedules Direct, it is free.

And yes overtheair in UK now has almost everything you need info wise... its very populated. As i said the 7 day EPG is the weakest point.

elupus Wrote:i have no problem in adding xmltv output support to our cmyth based filesystem (ie open a special url and you get a xmltv file), even if mythtv stores recordings differently in a db.

Sounds like a good idea to get a unified solution, then any other clients can do the same. So even if each each individual client module deals with the EPG data differently internally they will in the end always present a XMLTV listings.xml files to XBMC frontend which it in turn can use in its TV-Guide GUI.