[mgbouma]

@alcoheca

What I ment was that during channel selection from the list you see the epg data for the current show. You also see a bar showing if the show has just started or is nearly finished. If you select a channel you will see the now/next data (short version) if you press the info button you will see all the info available in the now/next data.

The sql database was chosen to be able to simple fill the epg data with 3rd party programs.

I currently use my xbmc to connect to my dreambox. I also have an skystar card in my linux server running mythtv. Would be nice if it it's possible to connect to both frontends. Currently I use tuxbox to connect to my dreambox. It's working but channel selection is a disaster. Therefore looking forward to using the universal tv frontend.

[alcoheca]

@alcoheca

What I ment was that during channel selection from the list you see the epg data for the current show. You also see a bar showing if the show has just started or is nearly finished. If you select a channel you will see the now/next data (short version) if you press the info button you will see all the info available in the now/next data.

Well there's no graphical list of channels currently except in the tv guide window, but I know what you mean and there will something along the lines of this.

I currently use my xbmc to connect to my dreambox. I also have an skystar card in my linux server running mythtv. Would be nice if it it's possible to connect to both frontends. Currently I use tuxbox to connect to my dreambox. It's working but channel selection is a disaster. Therefore looking forward to using the universal tv frontend.

Multiple backends will be supported from the outset, though we still need to decide how to section/display the different sources. Do you have any channels that are available from both sources? In that case we need a setting that chooses which backend has priority when reading schedule data, which isn't a big deal.

[mgbouma]

@alcoheca

Yes, Both the dreambox and the skystar are using the same dishes and thus see the same channels. I'm using the skystar to record tv-shows and use the dreambox to watch tv.
I'm currently using two xbox and one linux xbmc systems. The problem is that the all 3 xbmc are using the same sources. If i'm watching tv via xbmc and my son wants to watch tv via his xbmc he will override my connection. Each xbmc setup can connect to different tv-backends. So should xbmc know that one backend is busy and it should use another one? I think the problem is one can have multiple xbmc setups and also multiple backends. A bit of a challenge here.

[alcoheca]

@alcoheca

Yes, Both the dreambox and the skystar are using the same dishes and thus see the same channels. I'm using the skystar to record tv-shows and use the dreambox to watch tv.
I'm currently using two xbox and one linux xbmc systems. The problem is that the all 3 xbmc are using the same sources. If i'm watching tv via xbmc and my son wants to watch tv via his xbmc he will override my connection. Each xbmc setup can connect to different tv-backends. So should xbmc know that one backend is busy and it should use another one? I think the problem is one can have multiple xbmc setups and also multiple backends. A bit of a challenge here.

This should be continued somewhere else as it's getting off-topic, a new thread could be started to discuss these sort of problems with watching live-tv with multiple sources & multiple clients. As it is I see all of this being handled by the backend (if smart enough) or by the client plugin, and not by XBMC.

I'll be in a similar situation, I have 2 satellite sources & 3 from terrestrial. All are in one pc. The channel lists are different but there are channels available from both sources, so the backend (MythTV, but eventually VDR) will handle the requests and just return true or false to a request to start live-tv.

[alcoheca]

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

So there's not been much discussion on this problem yet, but in the meantime I'm having a go at modifying the CGUIWindowEPG so that it streams EPG data via PVRManager->Client->Backend rather than from PVRManager->local databsae. Will report back with some benchmarks once it's working.

I agree that it's a lot simpler to just demand epg directly from the client as and when we need it, but what should happen with clients who for some reason or another cannot offer timely retrieval of EPG data within a range, and/or for certain channels? In that case it's up the client plugin to handle caching of EPG data locally and in that case it's probably sensible to offer API access to a local db.

I already have storage of client's properties & capabilities working, so we could add another field which dictates whether or not to retrieve data via the db, or via the plugin directly.

what does anyone think?

[the_alien]

So there's not been much discussion on this problem yet, but in the meantime I'm having a go at modifying the CGUIWindowEPG so that it streams EPG data via PVRManager->Client->Backend rather than from PVRManager->local databsae. Will report back with some benchmarks once it's working.

Sounds good. Waiting for your benchmarks

I agree that it's a lot simpler to just demand epg directly from the client as and when we need it, but what should happen with clients who for some reason or another cannot offer timely retrieval of EPG data within a range, and/or for certain channels? In that case it's up the client plugin to handle caching of EPG data locally and in that case it's probably sensible to offer API access to a local db.

I would recommend to make one API for retrieving EPG data from the client. If it is handled via streaming the EPG on the fly from the backend or a local database is up to the client.
Offering API access to the local db would lead others to make there client offering API access to db XYZ... maybe offering an ODBC API would solve this problem. There you have a unified API and the PVRManager (or whatever class should use the API) wouldn't mind which database is running, the local SQLite, MythTVs MySQL, VDRs foo or an Oracle DB

[alcoheca]

Offering API access to the local db would lead others to make there client offering API access to db XYZ... maybe offering an ODBC API would solve this problem.

I don't completely understand what you're talking about here.
I was talking about having the ability for the clients to use the built-in SQLite implementation without loads of code or dependencies being added to the plugin.
(In the case where they grab EPG from XMLTV or somewhere else that doesn't do frequent updates)

[the_alien]

Okay, I missunderstood you, my bad :/

Forget everything I said, it's a good idea

[SebaSOFT]

Any news on this? Is already behind schedule?

[DJBlu]

Have you thought of using EIT? Send it via TS Stream to clients. Store it as you wish.