EPG (TV-Guide) data-store code development discussion for the unified PVR front-end
#31
Quit piling on the pressure!

Wink
Reply
#32
Looks really nice. alcoheca do you have already an idea on how the plugin interface will look like (or will you offer a vdr plugin? Laugh )
Always read the XBMC online-manual, FAQ and search the forum before posting.
Do not e-mail XBMC-Team members directly asking for support. Read/follow the forum rules.
For troubleshooting and bug reporting please make sure you read this first.
Reply
#33
quick update..

@WiSo the beginnings of the interface is now available in my branch - IPVRClient.h. Once I have it working reasonably well (ie by the 18th) I'll strip out any of the xbmc classes and just use structs & standard data types. Then we can look at the methods for packaging/linking the 'plugins'.
Reply
#34
I was just wondering if you have made any more reportable progress?

I am really excited to see what you come up with for this.

Could you post anymore screenshots?

regards,

Dubstar_04
Reply
#35
If you're really, really excited try reading the svn log, or compiling my branch - It's sure to calm you down. Smile

No screenshots but in terms of changes to the gui, there's some info on the home page similar to the weather button, there's a new window which pops up from the tv guide, where you can find other broadcasts (repeats), and schedule a recording.

Non-gui - It was a lot of work to get the PVRManger class & the client side behaving. I need to cope with multiple requests to the pvrmanager taking place at the same time and this was tricky to learn how to do it; it's certainly not bug free yet either.

I'll take some screenshots once there's something more exciting to look at.
Reply
#36
alcoheca: How functional is the current SVN? I am considering compiling your branch and I am trying to decided if it is worth it yet. Could you possibly list the features that are currently working or not working? (If you have the time) I am dieing to see commercial skip in there.

Thanks for all your hard work!

-Hotstyle
Reply
#37
alcoheca: I had a TVServer patch for XBMC, which did work a little, but I have been waiting for your branch. Is it at a state at the moment where it would be relatively easy for me to add my TVServer code to your branch easily? I would love to play around with it, but don't want to port it all over if it is still changing a lot.
Reply
#38
EvilDude Wrote:alcoheca: I had a TVServer patch for XBMC, which did work a little, but I have been waiting for your branch. Is it at a state at the moment where it would be relatively easy for me to add my TVServer code to your branch easily? I would love to play around with it, but don't want to port it all over if it is still changing a lot.

sorry for the off topic but I'm really glad to here your still working on this as really don't want to have to run a liunx server for tvLaugh
Reply
#39
hotstyle765 Wrote:alcoheca: How functional is the current SVN? I am considering compiling your branch and I am trying to decided if it is worth it yet. Could you possibly list the features that are currently working or not working? (If you have the time) I am dieing to see commercial skip in there.
Just so you know, commercial skip wasn't in the GSoC project specification and therefore is fairly low priority for me right now, I really need to make more progress in the EPG related functions first. It *IS* something which I will implement, and will be fairly straightforward to do once time is made available for it.

Thing is, commercial skip, pausing live tv, PIP etc are file system related and outside the scope of the GSoC project. You may have noticed I've pledged to continue working on this post-GSoC and that will probably end up being the next step - creating a pvr:// protocol type for the virtual file system so that we can then get nice things happening with live tv, have recordings available from the Video Library and get commercial skip, and other file related things working to a degree.

Before all that though, the primary function - scheduling recordings - must be working 100% and so I'll be working on that solely for now. (I'm also attempting to have a life at the moment. which is why I ignored the notification email when it first arrived)
Reply
#40
EvilDude Wrote:alcoheca: I had a TVServer patch for XBMC, which did work a little, but I have been waiting for your branch. Is it at a state at the moment where it would be relatively easy for me to add my TVServer code to your branch easily? I would love to play around with it, but don't want to port it all over if it is still changing a lot.

It's still changing so I would recommend holding off for now. The interface currently uses xbmc's internal datatypes, so it will need to be changed to use only use standard C types and structs.

Saying that this is in the area of the frontend that I have the least understanding of - how to compile clients, and dynamically link them with XBMC at runtime. I would welcome the more knowledgeable people here to lead the discussion here..:p
Reply
#41
Gamester17 Wrote:XMLTV formated listings.xml for input from the client and a own epg.db SQL database for the storage does sounds logical.
However I do not think it should be the clients job to populate the SQL database directly, instead the clients job should be to provide the XMLTV formated listings.xml file to the XBMC EPG API, then it will the the job of XBMC EPG API to parse that file and populate the SQL database (which in turn the EPG GUI part will use).

Had a discussion with alcoheca about handling the epg data on the xbmc side.

As how it is intended to be right now I see a problem on how to synchronize the epg from the client and the pvr.
I see 3 options:
1. The server knows which data has been inserted or been replaced in the latest update and offers the delta.
2. The client only updates everything that has been inserted after the last day it knows. Thinking about changes in the epg data this is a bad option.
3. The client doesn't permanently stores all epg data and just receives them on demand from the server. Thinking of filtering and searching the libcmyth isn't really capable of doing this. So there have to be changes made to the lib, which can't be to bad, since it just queries the mythtv mysql db.

If we store all epg data and don't want option 2, because changes in the epg wouldn't be recognized and the server doesn't offers option 1... we have to receive a full epg update, which can be timecritical in my opinion.

Feel free to discuss the problem Big Grin
Reply
#42
Why not talk to some of the dreambox developers (pli). They are dealing with the same issues. I really like the way they handle epg data and the way they show the zaplist.
Image
I know that pli also works with a sqlite database for the epg data.
Reply
#43
mgbouma Wrote:I really like the way they handle epg data and the way they show the zaplist.
hi mgbouma,
What is it that you like in the way they handle EPG data? From the PLi wiki I've read they chose SQLite as a means to store more than 2 days of data with the limited resources (RAM) of the dreamboxen. (Not exactly the same issues the_alien is raising).
Reply
#44
MythTV updates it's own TV schedule each time the XMLTV feed is given to it.

For my system I have a cron job that obtains the latest XMLTV file containing 7-8 days worth of data from the internet. This job then uses the native mythfilldatabase command line tool, which does the magic to make sure the TV schedule is up-to-date in the database.

Would seem silly to have XBMC try and do the same sort of thing. As long as the EPG in XBMC matches what I'd see in Myth TV in terms of the schedule I'd call the solution a success.

Is there anyway to have XBMC simply copy the entire content of the Myth TV schedule every now and then (perhaps once a day at a given time to coincide with what most people are likely doing for the backend)?

EIT data feeds for the programs are more timely and can change the timings more frequently but I don't have much experience with this.
Reply
#45
dteirney Wrote:MythTV updates it's own TV schedule each time the XMLTV feed is given to it.

For my system I have a cron job that obtains the latest XMLTV file containing 7-8 days worth of data from the internet. This job then uses the native mythfilldatabase command line tool, which does the magic to make sure the TV schedule is up-to-date in the database.

Would seem silly to have XBMC try and do the same sort of thing. As long as the EPG in XBMC matches what I'd see in Myth TV in terms of the schedule I'd call the solution a success.

Is there anyway to have XBMC simply copy the entire content of the Myth TV schedule every now and then (perhaps once a day at a given time to coincide with what most people are likely doing for the backend)?
You mean like it's doing at the moment? I'm not sure you've understood what's being suggested. Smile

dteirney Wrote:EIT data feeds for the programs are more timely and can change the timings more frequently but I don't have much experience with this.
We're talking about much more frequent updates: e.g. in the case where the PVR backend is following changes to the EPG via the Running Status Table (taken from the EIT) and is updating start/end times of programs that are due to start very soon. Few PVR backends support this, and even fewer broadcasters actually send useful data in the RST currently but there's good sense in supporting this from the outset.
Reply

Logout Mark Read Team Forum Stats Members Help
EPG (TV-Guide) data-store code development discussion for the unified PVR front-end1