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

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

+- XBMC Community Forum (http://forum.xbmc.org)
+-- Forum: Development (/forumdisplay.php?fid=32)
+--- Forum: PVR Development (/forumdisplay.php?fid=136)
+--- Thread: Unified PVR frontend (DVR/HTPC client GUI with EPG) and Addons API for PVR backends? (/showthread.php?tid=28918)

Pages: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28

- barney_1 - 2008-12-04 04:01

That did the trick, thanks!

I figured the early merge with the linux branch would have very little functionality. I am however one of those people interested enough to read the code.

It is connecting with my mythtv backend.... it's not showing the "correct" next program to record, but the one it shows is set to record tomorrow so I think that's a success.

Thanks for your work, I look forward to following the development! I'd be happy to help with testing so keep us posted if you need help.

- alcoheca - 2008-12-04 04:13

barney_1 Wrote:It is connecting with my mythtv backend.... it's not showing the "correct" next program to record, but the one it shows is set to record tomorrow so I think that's a success.

It does that for me too, but with a recording that finished last night. It's showing me the next scheduled broadcast and saying it's set to record. Must be something stinky in the implementation...

- alwinus - 2008-12-21 17:40

[EDIT]: Please ignore this, I have send submit a patch on trac and will e-mail Alcoheca directly instead.

VDR client plugin patch for XBMC SVN revision 16630:
http://trac.xbmc.org/ticket/5595

Patch for Alcoheca's unified PVR frontend and a plugin for VDR backend (including modified streamdev-plugin for VDR)

Best regards / Alwin Esch

- dubstar_04 - 2009-01-04 12:10

I just had a look at the branch to get a status update and it seems work has slowed recently.

Does anyone know whats happening with it ? has it been merged?

- Gamester17 - 2009-01-05 11:11

alwinus Wrote:Patch to xbmc-svn16630:
http://rapidshare.de/files/41182644/xbmc-pvr-svn16630.patch.gz.html

VDR with modified streamdev:
http://rapidshare.de/files/41182638/vdr-1.7.1-xbmc-streamdev.tar.bz2.html

Best regards,

Alwin Esch

Please always submit all an any patches to trac (our tracking-system):
http://trac.xbmc.org
http://wiki.xbmc.org/?title=HOW-TO_submit_a_patch
http://wiki.xbmc.org/?title=Appendix_D:_Development_Notes

Like so => http://trac.xbmc.org/ticket/5595 Nod

Thanks in advance!

- Redth - 2009-01-06 17:45

I've also been anxiously awaiting the unified pvr.. as soon as it's done I hope to start working on getting it working with mediaportal....

My Concept - SSchocke - 2009-01-17 11:05

First off, let me say I am by no means an expert in any of this, I just have a few ideas and a concept that I had in mind to develop myself before I found this work.

I had much the same vision as alcoheca did. A unified GUI in XBMC, allowing me to connect to any PVR server that we could interface with. Coming from Media Portal, my experience has been with TVServer. My first instinct was to say, we need a TVManager(PVRManager) that would present a unified interface for the GUI to use. You can query the TVManager for any info you wanted to display in the client. TVManager.GetChannelList() would return a list of channels, independent of which or how many TV Servers were in your setup. Each channel would have a ID.

On the other side, we would have the client implementation. Unlike alcoheca's idea, I did not want to do a plug in architecture. My feeling with XBMC is to minimize DLL's. If only your application will ever use the functionality provided, DLL's are just more hassle than anything else. So my idea was, provide a standard interface for the clients, similar to the TVManager. A TVServer or MythTV or whatever implementation has to implement the interface. So, for instance the TVServer implementation also has a GetChannelList() that returns a list of channels. How it gets this list is irrelevant.

So, when the GUI calls GetChannelList() on the TVManager, it calls GetChannelList() for all configured backends, consolidates the list, and presents it to the GUI. EPG data can be handled in the same way. Config can be handled via XML file like RSS Feeds.

Further functionality like scheduling recording, program info, watching a channel, etc, all use the Unique ID of the channel returned by the GetChannelList() call to TVManager. The TVManager then looks up what backend that channel is tied to, and sends the command along to that backend. Once again, how the backend actually does it is irrelevant.

I am sure it is actually a lot more complex than this once one starts coding it... Also, I am not looking to try and compete with the work already done my alcoheca, but rather to contribute and help. Judging from what I have read on the forums, the GUI part seems to be fairly done and working... Just the integration which seems to be a pain.

- alcoheca - 2009-01-17 18:39

SSchocke Wrote:First off, let me say I am by no means an expert in any of this, I just have a few ideas and a concept that I had in mind to develop myself before I found this work.

I had much the same vision as alcoheca did. A unified GUI in XBMC, allowing me to connect to any PVR server that we could interface with. Coming from Media Portal, my experience has been with TVServer. My first instinct was to say, we need a TVManager(PVRManager) that would present a unified interface for the GUI to use. You can query the TVManager for any info you wanted to display in the client. TVManager.GetChannelList() would return a list of channels, independent of which or how many TV Servers were in your setup. Each channel would have a ID.

So as it stands that's the current plan.

SSchocke Wrote:On the other side, we would have the client implementation. Unlike alcoheca's idea, I did not want to do a plug in architecture. My feeling with XBMC is to minimize DLL's. If only your application will ever use the functionality provided, DLL's are just more hassle than anything else. So my idea was, provide a standard interface for the clients, similar to the TVManager. A TVServer or MythTV or whatever implementation has to implement the interface. So, for instance the TVServer implementation also has a GetChannelList() that returns a list of channels. How it gets this list is irrelevant.

I don't see the difference in what you're suggesting to how it is currently implemented. The API is the standard interface you talk about.

SSchocke Wrote:So, when the GUI calls GetChannelList() on the TVManager, it calls GetChannelList() for all configured backends, consolidates the list, and presents it to the GUI. EPG data can be handled in the same way. Config can be handled via XML file like RSS Feeds.

This is how it works right now. GUI calls PVRManager::GetChannels(); PVRManager calls each Client::GetChannels() in turn. PVRManager aggregates this data into one list.

SSchocke Wrote:Further functionality like scheduling recording, program info, watching a channel, etc, all use the Unique ID of the channel returned by the GetChannelList() call to TVManager. The TVManager then looks up what backend that channel is tied to, and sends the command along to that backend. Once again, how the backend actually does it is irrelevant.

Yep that's how it's currently planned. My thoughts are that in XBMC Settings there will be a channel editor which will differentiate the multiple sources(backends), highlight new channels, set access restrictions to different profiles, etc etc. In here you will be able to set the channel numbering you like, grab channel logos etc; wholly separate from the backend implementation.

- SSchocke - 2009-01-18 09:50

alcoheca Wrote:I don't see the difference in what you're suggesting to how it is currently implemented. The API is the standard interface you talk about.

Right

. I was under the impression that the Client API would allow someone to code a SageTV plugin wholly separate from the XBMC source code, only using the ClientAPI, compile it as a DLL, and just copy it into a Plugins folder(not necessarily the XBMC Plugins folder) where the PVRManager would find it and load it.

My idea was just to code the SageTV "plugin" as part of the XBMC code. It simplifies things in terms of the interface, and since there is really no reason for anyone to want to use our plugins outside of XBMC, I don't see why we should go through the hassle. Confused

alcoheca Wrote:This is how it works right now. GUI calls PVRManager::GetChannels(); PVRManager calls each Client::GetChannels() in turn. PVRManager aggregates this data into one list.

Glad to hear it Big Grin

. I have not checked out a copy of your PVR branch yet. Here in South Africa, we have a draconian ISP that limits our bandwidth to about 1Gig a month Sad

, and I am running dangerously near to that limit for January. I am looking forward to playing with the code. Just wanted to throw around some ideas in the mean time.

- alcoheca - 2009-01-18 21:19

SSchocke Wrote:Right . I was under the impression that the Client API would allow someone to code a SageTV plugin wholly separate from the XBMC source code, only using the ClientAPI, compile it as a DLL, and just copy it into a Plugins folder(not necessarily the XBMC Plugins folder) where the PVRManager would find it and load it.

sounds great.

SSchocke Wrote:My idea was just to code the SageTV "plugin" as part of the XBMC code. It simplifies things in terms of the interface, and since there is really no reason for anyone to want to use our plugins outside of XBMC, I don't see why we should go through the hassle.

Maintaining multiple clients inside XBMC source tree is sub-optimal and would only end up with stale code and unwanted support requests when plugin developers stop maintaining them. It's not that much hassle to switch to packaging the clients once the API is finalized so I don't see the issue.