One common PVR front-end (client-side GUI) and a unified API for addons that control different PVR back-end TV-servers?
Please do not let the length of this post put you off, as this is really a great idea for truly 'taking XBMC to the next level' for sure!
Note that I have already tried to lobby this internally to Team-XBMC for quite a long time but unfortunately none of the developers on the team currently have both personal interest and time required to programming all this by themselves alone, (mostly due to time restraints), so I am now posting this idea as a public request, hoping that some new C/C++ programmer/developer will like this idea and take the initiative to make it happen (and submitting an initial code patch for it to help get us started).
As you may already know, more and more PVR/DVR devices (and also HTPC software applications) are nowdays redesigning/refactoring their applications to be split into a separate back-end and and a front-end, (meaning a separate server-side back-end which runs as a background service and takes care of the recording, storing, and sharing part, and a separate a client-side front-end that acts as the graphical user-interface and media-player viewer).
The basic concept of this design is that the back-end and the front-end have a two-way communication channel between them for sending commands and streaming video, using either their own protocols, (which though often proprietary usually have an openly documented command API), or they use an open internet standard protocol like UPnP, RTSP/RTP, HTTP, XML and/or SOAP. Also, many PVR/DVR devices and HTPC software that are not front-end/back-end based does still have a built-in web-interface (similar to what XBMC has) that can be used to fully remote-control that device/software, plus they often support streaming video via HTTP and RTSP/RTP or they have the option to share their recorded files via standard SMB over the network.
My idea here for is that XBMC could have a generic GUI front-end section in XBMC (which could maybe have the graphical EPG and scheduling stuff based on the XMLTV-GUI TV-Guide standard format for the EPG back-end?). This GUI front-end section should be designed to to able to command and control all types of PVR/DVR devices (and HTPC software) over a network. This GUI front-end should preferably be linked to a generic PVR framework infrastructure with a mapping/translation-layer that would offer a common uniform 'wrapper' API which developers can write separate plugins (eg. DLL libraries) for in order control specific PVR/DVR devices and HTPC software, (like MythTV, MediaPortal, and Dreambox as examples). Maybe even a few common DLL libraries that could be shared between the different plugins if they utilize similar functions/protocols, like UPnP, which could be customized via XML and RegEx or Python to fit different back-ends. All controlled from the same interface in XBMC, with the user all seeing the same generic GUI front-end no matter which back-end is used.
So which new end-user features would this then enable in XBMC?:
- Watch Live TV
- Channel selection during Live TV over full screen window
- Info screen during Live TV with Program Descriptions)
- Record Live TV (on the server-side back-end running on a PC)
- Basic cut and rework recordings (trim the beginning and end)
- Watch that recorded TV
- Electronic Program Guide (EPG) GUI
- View Program Listings (and Program Descriptions on demand)
- Schedule recordings
- Info about what is currently recording or next scheduled recording
- Pause Live TV (time-shift)
- Listen to AM/FM and Satellite Radio
- Teletext (Text TV)
I guess that the requirements for a such API as this will be that it has to be well specified and documented, (or at the very least use doxygen for semi-automatic code documentation?), so that independent plugin developers can jump right in and get started quickly, ei. writing a 'plugin' for the API should not require any knowledge of XBMC GUI internals or the actual workings inside this 'PVR front-end API', right? Maybe start by looking at the existing XBMC's visualization API as a framework reference? As an option we could maybe also add an alternative method for those back-end devices/software that have a web-interface, for those we could possible let the users write 'simple' XML plugins made with RegExp similar to the scrapers and/or Python to enable scraping and web-interface control, or we could even possibly extend XBMC's existing HTTP API to be more flexible in these areas and be accessible from this API as well(?), noted though that those 'simple' plugins could only work if the back-end is capable of streaming using a standard protocol such as UPnP or RTSP/RTP.
Suggested plugins (if a the framework API described in the concept above will ever become available in XBMC):
- MythTV (HTPC software for Linux and Mac OS X) front-end to control MythTV back-end (maybe via MVPMC's libCMyth, or UPnP?).
* XMLTV's .XML download to XBMC's TV-Guide from MythTV EPG and possible schedule control via the TV-Guide too.
- Linux VDR (Video Disk Recorder) front-end to control LinVDR server (maybe via UPnP or existing VDR plugin like streamdev?).
* XMLTV's .XML download to XBMC's XMLTV TV-Guide from VDR EPG and possible sheduele control via the TV-Guide too.
- HTS TVheadend front-end to control HTS's TVheadend as a back-end] (maybe via TVheadend's existing XBMSP-server and Web UI API?).
* XMLTV's .XML download to XBMC's XMLTV TV-Guide and possible schedule control via that TV-Guide too.
- Dreambox/Dbox2 front-end to fully control Dreambox/Dbox2 boxes (maybe via Tuxbox Client for Enigma?).
* XMLTV's .XML download to XBMC's TV-Guide from Dreambox/Dbox2 EPG and possible schedule control via the TV-Guide too.
- HDHomeRun front-end to fully control HDHomeRun boxes.
* XBMC's XMLTV TV-Guide from HDHomeRun EPG and possible sheduele control via the TV-Guide too.
- MediaPortal front-end to control MediaPortal TVserver back-end (maybe via UPnP?, or RTSP?) now they've newly released TvEngine
* XMLTV's .XML download to XBMC's TV-Guide from MediaPortal EPG and possible schedule control via the TV-Guide too.
- MeediOS front-end to control MeediOS back-end (maybe via UPnP?, or RTSP?) they use a derivative of MediaPortal's TV Engine.
* There is also a project on SourceForge called "VistaMCEClient for TVE3 Server" which does the same for Windows Vista MCE.
* XMLTV .XML download to XBMC's TV-Guide from MeediOS EPG and possible schedule control via the TV-Guide too.
- Windows Media Center Extender front-end to control Microsoft Windows MCE as the back-end (maybe via WebGuide for the control?)
* XMLTV's .XML download to XBMC's TV-Guide from Windows MCE EPG and possible schedule control via the TV-Guide too.
- ProgDVB front-end to control ProgDVB as a back-end] (maybe via UPnP or existing ProgDVB plugins API?).
* XMLTV's .XML download to XBMC's XMLTV TV-Guide and possible schedule control via that TV-Guide too.
- v4l and v4l2 (Video4Linux framework) - v4l comes built-into Linux 2.6.x kernel and later, plus a library for v4l2.
What do you all think? Comments, suggestions, ideas?
Any volunteers for the API and/or any or the plugin ideas?
Note! Please understand that since I'm not a programmer myself I probably didn't get all the technical terms correct in this first concept draft.
Please do not let the length of this post put you off, as this is really a great idea for truly 'taking XBMC to the next level' for sure!
Note that I have already tried to lobby this internally to Team-XBMC for quite a long time but unfortunately none of the developers on the team currently have both personal interest and time required to programming all this by themselves alone, (mostly due to time restraints), so I am now posting this idea as a public request, hoping that some new C/C++ programmer/developer will like this idea and take the initiative to make it happen (and submitting an initial code patch for it to help get us started).
As you may already know, more and more PVR/DVR devices (and also HTPC software applications) are nowdays redesigning/refactoring their applications to be split into a separate back-end and and a front-end, (meaning a separate server-side back-end which runs as a background service and takes care of the recording, storing, and sharing part, and a separate a client-side front-end that acts as the graphical user-interface and media-player viewer).
The basic concept of this design is that the back-end and the front-end have a two-way communication channel between them for sending commands and streaming video, using either their own protocols, (which though often proprietary usually have an openly documented command API), or they use an open internet standard protocol like UPnP, RTSP/RTP, HTTP, XML and/or SOAP. Also, many PVR/DVR devices and HTPC software that are not front-end/back-end based does still have a built-in web-interface (similar to what XBMC has) that can be used to fully remote-control that device/software, plus they often support streaming video via HTTP and RTSP/RTP or they have the option to share their recorded files via standard SMB over the network.
My idea here for is that XBMC could have a generic GUI front-end section in XBMC (which could maybe have the graphical EPG and scheduling stuff based on the XMLTV-GUI TV-Guide standard format for the EPG back-end?). This GUI front-end section should be designed to to able to command and control all types of PVR/DVR devices (and HTPC software) over a network. This GUI front-end should preferably be linked to a generic PVR framework infrastructure with a mapping/translation-layer that would offer a common uniform 'wrapper' API which developers can write separate plugins (eg. DLL libraries) for in order control specific PVR/DVR devices and HTPC software, (like MythTV, MediaPortal, and Dreambox as examples). Maybe even a few common DLL libraries that could be shared between the different plugins if they utilize similar functions/protocols, like UPnP, which could be customized via XML and RegEx or Python to fit different back-ends. All controlled from the same interface in XBMC, with the user all seeing the same generic GUI front-end no matter which back-end is used.
So which new end-user features would this then enable in XBMC?:
- Watch Live TV
- Channel selection during Live TV over full screen window
- Info screen during Live TV with Program Descriptions)
- Record Live TV (on the server-side back-end running on a PC)
- Basic cut and rework recordings (trim the beginning and end)
- Watch that recorded TV
- Electronic Program Guide (EPG) GUI
- View Program Listings (and Program Descriptions on demand)
- Schedule recordings
- Info about what is currently recording or next scheduled recording
- Pause Live TV (time-shift)
- Listen to AM/FM and Satellite Radio
- Teletext (Text TV)
I guess that the requirements for a such API as this will be that it has to be well specified and documented, (or at the very least use doxygen for semi-automatic code documentation?), so that independent plugin developers can jump right in and get started quickly, ei. writing a 'plugin' for the API should not require any knowledge of XBMC GUI internals or the actual workings inside this 'PVR front-end API', right? Maybe start by looking at the existing XBMC's visualization API as a framework reference? As an option we could maybe also add an alternative method for those back-end devices/software that have a web-interface, for those we could possible let the users write 'simple' XML plugins made with RegExp similar to the scrapers and/or Python to enable scraping and web-interface control, or we could even possibly extend XBMC's existing HTTP API to be more flexible in these areas and be accessible from this API as well(?), noted though that those 'simple' plugins could only work if the back-end is capable of streaming using a standard protocol such as UPnP or RTSP/RTP.
Suggested plugins (if a the framework API described in the concept above will ever become available in XBMC):
- MythTV (HTPC software for Linux and Mac OS X) front-end to control MythTV back-end (maybe via MVPMC's libCMyth, or UPnP?).
* XMLTV's .XML download to XBMC's TV-Guide from MythTV EPG and possible schedule control via the TV-Guide too.
- Linux VDR (Video Disk Recorder) front-end to control LinVDR server (maybe via UPnP or existing VDR plugin like streamdev?).
* XMLTV's .XML download to XBMC's XMLTV TV-Guide from VDR EPG and possible sheduele control via the TV-Guide too.
- HTS TVheadend front-end to control HTS's TVheadend as a back-end] (maybe via TVheadend's existing XBMSP-server and Web UI API?).
* XMLTV's .XML download to XBMC's XMLTV TV-Guide and possible schedule control via that TV-Guide too.
- Dreambox/Dbox2 front-end to fully control Dreambox/Dbox2 boxes (maybe via Tuxbox Client for Enigma?).
* XMLTV's .XML download to XBMC's TV-Guide from Dreambox/Dbox2 EPG and possible schedule control via the TV-Guide too.
- HDHomeRun front-end to fully control HDHomeRun boxes.
* XBMC's XMLTV TV-Guide from HDHomeRun EPG and possible sheduele control via the TV-Guide too.
- MediaPortal front-end to control MediaPortal TVserver back-end (maybe via UPnP?, or RTSP?) now they've newly released TvEngine
* XMLTV's .XML download to XBMC's TV-Guide from MediaPortal EPG and possible schedule control via the TV-Guide too.
- MeediOS front-end to control MeediOS back-end (maybe via UPnP?, or RTSP?) they use a derivative of MediaPortal's TV Engine.
* There is also a project on SourceForge called "VistaMCEClient for TVE3 Server" which does the same for Windows Vista MCE.
* XMLTV .XML download to XBMC's TV-Guide from MeediOS EPG and possible schedule control via the TV-Guide too.
- Windows Media Center Extender front-end to control Microsoft Windows MCE as the back-end (maybe via WebGuide for the control?)
* XMLTV's .XML download to XBMC's TV-Guide from Windows MCE EPG and possible schedule control via the TV-Guide too.
- ProgDVB front-end to control ProgDVB as a back-end] (maybe via UPnP or existing ProgDVB plugins API?).
* XMLTV's .XML download to XBMC's XMLTV TV-Guide and possible schedule control via that TV-Guide too.
- v4l and v4l2 (Video4Linux framework) - v4l comes built-into Linux 2.6.x kernel and later, plus a library for v4l2.
What do you all think? Comments, suggestions, ideas?
Any volunteers for the API and/or any or the plugin ideas?
Note! Please understand that since I'm not a programmer myself I probably didn't get all the technical terms correct in this first concept draft.
