kodi-pvr / pvr.hdhomerun

Kodi's HDHomeRun client addon
GNU General Public License v2.0
20 stars 24 forks source link

EPG refactor #57

Closed fuzzard closed 7 years ago

fuzzard commented 7 years ago

Hi,

Just opening this Issue to see if you would be interested in a branch ive started. https://github.com/fuzzard/pvr.hdhomerun/tree/xmltv

Currently the SiliconDust EPG Api has a general limit of 4 hours. There are workarounds to extend this to ~12hrs, and obvisouly SD's DVR service provides a longer time window. There are also many providers of EPG data with longer windows of time. I am wanting to factor out the EPG update to allow the implementation of other EPG guide data. Im from australia, so i was looking at freepg.tv for my purposes, but i realise icetv is a much used EPG guide, as well as just importing from a local xmltv formatted file that is provided by the user.

Just looking to see if you think this out of scope for your wishes with the addon? Or if you may be interested in a pull request when i get it further along?

zcsizmadia commented 7 years ago

Sounds interesting and open to it. Of course the devil is always in the detail :) Could you tell me more how you are planning to automate it? E.g. pull the latest data from the EPG web servers, match channel names/ids with the web server channel names/ids, ...

It is possible it is just a very advanced option, where the user has to provide the xmltv file, and the addon just reads it. This is most likely the easiest way, but needs a very advanced user :)

fuzzard commented 7 years ago

The intent initially is to factor out the current epg guide to its own class, and then allow implementation of other epg's using their own class. Have the return value be a json representation of the guide (xml to json provided by the epg class). The reasoning at this stage for that is everything else in the existing code is reliant on a json structured format. The xmltv format will obviously need to be manipulated to match up to the HDHomerun lineup (Channel - Channel, other elements to existing elements), and this will be done by the EPG class before returning the final json representation to be put into the existing lineup/guide codepath.

I intend to implement an EPG_SD class that handles the current EPG format with very little change, as well as an extended format that provides a 24hr guide for each channel. Once this is complete i'll look at doing either a user provided xmltv file that is stored locally (as you say, one of the easier options to implement from the dev side, but more involved for the end user supplying the xmltv file for updates), but also a class to pull from an epg provider ive been looking at using that provides a URL to pull from and then parse.

For the xmltv local file, i would look at providing a setting that allows x hours/days to reparse the file selected in the settings. Leaving it up to the user to provide (Possibly some other webscraper addon or something for automation). XMLTV is a fairly well documented format, so im hoping i can generally match 1+ displayname provided into Guidename field in the existing json implementation. Drop any fields we dont have existing fields for at this stage, and parse the rest into existing elements.

If other users wish to create classes for any other epg's, they can use the existing classes as a template for how to.

Im trying to stage everything so as to not require massive rewrites of the existing code base, but there are some limitations, so maybe down the line can look at changing some existing codepaths, but i see this as a different project for another time.

fuzzard commented 7 years ago

Gday, Ive come a bit further with this, but before i do a pull request, thought id ask to see if i could get any feedback. Looking for any criticisms in the approach ive taken. Still heavily WIP, but if im going too far away from what is acceptable up stream, id like to tackle those concerns sooner rather than later.

The XML EPG guide isnt feature complete as yet (xml < programme > is used for multiple < channel > is not populated for all of the desired channels), but it functions enough for a proof of concept.

The SD guide is just factored out the existing implementation, and the extended guide of this is completed with a caveat regarding epg update times and addon startup times.