PVR add-ons

I'd like to ask all PVR add-on authors to provide a pull request for https://github.com/opdenkamp/xbmc-pvr-addons with the latest stable version of their add-on, if it compiles and works on all platforms we support (windows, bsd, osx/ios/atv, linux)

This way, new users will have 1 central source to find the latest stable PVR add-ons, and this will be used as source for a binary add-on repos later on.

Add-ons that are not in this repos will not be supported and might stop working when the api is changed later.

Add-ons that are now included:

• pvr.demo: Demo add-on to demonstrate PVR functionality
• pvr.fortherecord.argus: add-on for the Fortherecord server
• pvr.hts: add-on for the HTS Tvheadend server
• pvr.mediaportal.tvserver: add-on for the Mediaportal tvserver
• pvr.nextpvr: add-on for the Nextpvr server
• pvr.njoy: basic add-on for the Njoy N7 device
• pvr.vdr.vnsi: add-on for the VDR VNSI server
  

Working on that right now for all additional addons that were in my XBMC pvr tree...

Adding the addons alone is not enough. I'm also working on porting some pieces of the Windows BuildDependencies stuff in order to get the required lib curl support for the NJoy and ForTheRecord pvr addons.

My development branch already contains the ForTheRecord pvr addon, a Windows compatible version of the NJoy addon and a compiling VuPlus addon.
XVDR is still a bit of work at the Windows side but this should be also not too difficult to add.

great, thanks!

@margro

It would be great, if you could include the XVDR addon into xbmc-pvr-addon since pipelka does not seem to be interested to do it. I wrote him to do that, but i get no answer. I know many users of this addon, so this would be cool.

ok, in that case: i'm not interested either.
and having two add-ons for the same server only works confusing. xvdr (which is just a fork of our vnsi add-on that pipelka renamed cause he disagreed with us/me) can be merged back into vnsi if you like to see support for it in our add-on repos.

Who is confused with two addons? Most of the VDR users use the XVDR addon. So in my opinion VNSI also could be removed. Or is there still development? For me XVDR is more recent, faster and more stable at the moment.

And why don't let the user choose the best addon for himself?!

The user can, as always, do what he wants. He just shouldn't expect official support for every fork on the planet. That's why we are looking for cooperation of authors here.

While knowing this (first) post/rant is/will get offtopic, my EUR 0,02 anyway:

Regarding VDR I'd rather ditch VNSI as this feels (and probably is) unmaintained feature and bugfix-wise. XVDR has fixed several problems (e.g. with VNSI, after not very long playback duration it starts to drop/malform packets, the result is picture distortion and audio dropouts; also happens when streaming via loopback. The "fix" is to switch channels forth and back...) while VNSI just seems to be pushed from here to there for quite some time now. So if for whatever reason it isn't possible to get XVDR into -pvr-addons, I'd really welcome margro's move to get it in shape and - in consequence - included (and if two clients are not feasible/wanted, as a replacement for VNSI).

why not simply merge the XVDR changes back to the VNSI addon?

The xvdr vs vnsi saga is really annoying from an end-user perspective, this is just silly.
It's a real shame because vdr is way better than any other backend I've tried, fast, reliable and light and no sql bs needed (the only drawback is the kernel headers dependency).

(2012-09-13 21:41)da-anda Wrote:  why not simply merge the XVDR changes back to the VNSI addon?

I don't believe that open source means you can start copy paste code from one project to the other, this is not a proper solution.
xvdr has a developer maintaining the project so it should be his responsibility to make the changes to comply with xbmc code changes and guidelines, another developer can pr these changes to xvdr main git tree but the maintaining developer has to accept these changes.

This is the proper way to go, unless you've got a developer willing to fork xvdr and ready (and able) to maintain this fork and I don't see this happening soon.

p.s. As a non developer I had my share of compiling xvdr and making code adjustments to compile on windows and was able to have xvdr on windows, no good came from that because I now needed to follow any code change from xbmc's pvr api and xvdr, just a huge pita.