Notice to wiki editors only: Database corruption lead to all accounts being reset. You'll have to re-register. Sorry for the inconvenience. Normal XBMC users can ignore this message.
1 From main page
|Name||Backend OS||Addon OS||Homepage||Addon Maintainers||Addon Support||Backend Installation||Notes|
|HTS Tvheadend||Linux||lonelycoder.com||opdenkamp||XBMC Forum||lonelycoder wiki|
|MythTV||Linux||mythtv.org||fetzerch, janbar, tsp, dteirney||XBMC Forum||mythtv.org||MythTV add-on not yet merged into XBMC PVR Addons Repo, but is available in fetzerch's branch|
|MediaPortal||Windows||Windows, Linux, iOS||team-mediaportal.com||margro||XBMC Forum||mediaportal wiki||Backend XBMC Plugin (Required)|
|For The Record||Windows||Windows,
Linux, OSX, iOS
|4therecord.eu||margro, red-f||ForTheRecord forum||4therecord.eu wiki|
|DVBLink TV Server||Windows||Windows||dvblogic.com||zeroniak||DVBLink forum||dvblogic.com|
|VU+ / Enigma2||Linux (Enigma2)||Windows, Linux, OSX, iOS||jdembski||PVR Support forum|
|NextPVR||Windows||Windows, Linux||sub3||NextPVR XBMC Forum||nextpvr.com|
- PVR history
XBMC has long had support for viewing recordings from backend recording services such as MythTV and TVHeadend through the use of specialized video sources that communicate with the backend software. This did not allow XBMC to be used a true PVR frontend since user still had to view EPG data and schedule recordings via the backend interface. These file sources were also part of the XBMC core codebase, so updates to the backend API often broke the integration until XBMC pushed out an update.
Serious efforts to create a PVR frontend for XBMC started with a project during Google Summer of Code 2008. Project student Alcoheca began the fork of what would eventually become the XBMC PVR branch. As this project became more mature it opened the door for skinners to start taking advantage of skinning interfaces for PVR and add them to various XBMC skins.
With the release of XBMC 10.0 (Dharma) came the addition of the addon framework to XBMC. Although binary addons were not available, the PVR branch of XBMC started to use these as a structure for having various backends plug-in to a common API structure.
During the development cycle for XBMC 12.0 (Frodo) the merge of the PVR and mainline XBMC branches was approved during the XBMC Devcon. This made the PVR API available to all mainstream XBMC users, although the addons are still to be maintained in a separate repository and not distributed with XBMC releases.
2 Add-on namespace?
Shouldn't the individual articles about PVR add-ons be moved into the Add-on namespace? Currently there are a number of pages already in that namespace, e.g. Add-on:ForTheRecord_PVR_client that should either be merged under PVR, or they should be merged to Add-on: There is also already a category: Category:PVR add-ons --Fiveisalive 17:19, 10 October 2012 (EDT)
- Well, the add-on namespace is mainly for individual add-on entries more than it is for add-on related pages, while the sub-pages of the PVR guide are about both the add-ons and the backends. I wasn't sure how much over-lap there would be, so if it makes more sense to just have everything on the PVR add-on page and then link directly to that (and not have a sub page here) then we can certainly do that instead. -- Ned Scott 22:38, 10 October 2012 (EDT)
- OK, well I went systematically through all various Add-on:<client name> and PVR/<client_name> pages and tried to normalize as per the setup for PVR/VDR and Add-on:VDR VNSI Client, i.e. moved all the Settings info to the Add-on page and transincluded it in the corresponding PVR/<client name> page. This seems OK since we don't duplicate wikitext that will get out of date. The only thing that I don't quite like about this setup is that there's no obvious way for the user (as opposed to a wiki editor) to get to the corresponding Add-on page. My understanding that a good bulk of each Add-on: page will be autogenerated from repo information, but that the settings part would be manually updated? --Fiveisalive 14:52, 17 October 2012 (EDT)
- Settings will always have to be manually updated, unless we can figure out some way for add-on authors to include it in the (often unused) readme.txt file in the add-on, and automate that with a script.
- I'm also not wild about having two pages for the backend add-ons. It might be best to just move the settings to the PVR subpages, or just redirect one page to the other, but for the time being I wouldn't worry too much about that. We'll likely change/tweak the over-all structure as we get a better feel for what information we have, and what information is still needed. Right now the big thing is just getting that raw content, then we can move things around and such. Of course, any ideas on what our final structure should be are most welcome.
- Awesome work, by the way! -- Ned Scott 21:02, 20 October 2012 (EDT)