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

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Development (https://forum.kodi.tv/forumdisplay.php?fid=32)
+--- Forum: Add-ons (https://forum.kodi.tv/forumdisplay.php?fid=26)
+---- Forum: PVR (https://forum.kodi.tv/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

Is Alcoheca still working on GSoC PVR Integration ? - Swifty - 2008-11-27

Hi All,

I have been keeping an eye on the thread related to the GSoC project to integrate PVR's into XBMC but all has gone quiet for a couple of months now.
I was just wondering if the project was still alive and being worked on ?

Please don't take it as pestering, I am not expecting it to be released tomorrow or anything.. I'm just curious if it has died or is still underway, since there hasn't been any news.

Thanks!

- Jeroen - 2008-11-27

Seeing as alcoheca commited stuff to his branch 5 hours ago I would say yes.

http://trac.xbmc.org/browser/branches/unified-pvr/XBMC

- Swifty - 2008-11-27

Hehe, ok thanks Jeroen Nod

I didn't realise that you could see the activity like that.
Good to know its still progressing Smile

Thanks!

- barney_1 - 2008-12-04

I'm not involved in the development but I'll give you an update. On November 20th alcoheca formed a new branch in the source code called "unified-pvr" with the log message of "new branch to test PVR code against linuxbranch".

Here's the link to browse the code in the svn:
http://xbmc.svn.sourceforge.net/viewvc/xbmc/branches/unified-pvr/

I have downloaded and compiled this branch for linux. It runs but I haven't been able to test much of the new functionality (I just can't quite figure out how this is implemented).

@alcoheca (or anyone else who knows)

I found the TV listing under video settings. I enter in my information (including port 6543 which should be the mythtv default right?). From there I don't see how to access the "TV service". Do I need to add a new source in the video dialog?

I'd like to look under the hood of your new code but I've got to see if the car runs first.

update - alcoheca - 2008-12-04

hi barney,

Glad you got it to compile ok, you can thank davilla for that Big Grin

yes the mythtv defaults are:
user: mythtv
pass: mythtv
port: 6543

For now nothing more than info on the next recording is working, while I hook up the tv guide to the backend. You will only see this in Project Mayhem 3 skin and in PAL 4x3 resolution for now.

Check your logs and make sure myth connects. grep 'PVR:'

Sign up to notifications of commits to that branch, as there should be some movement in the next few weeks. (I'm about to finish university for the year, and at least 3 other people have shown an interest in developing this feature, so I'm really hoping to make progress).

For now though as this is EXTREMELY BUGGY and TOTALLY USELESS I suggest the only people who bother compiling are those interested enough to read the code. Nearly all of it is in files with PVR, EPG or TV in the filename.

- barney_1 - 2008-12-04

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

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

[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

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

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

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

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

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

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. Huh

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

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.