Great to hear that XBMC (now Kodi) have finally been ported to Vu+ (and PrismCube), however I'm sad to hear it is not using XBMC's internal PVR frontend GUI for LiveTV, EPG, and DVR.
I have the huge problem with this as it is then utilizing the full potential of XBMC by not actually using XBMC's internal PVR frontend GUI unified interface.
That is, XBMC on on Vu+ (nor PrismCube or XBMC) seem to use the integrated PVR or Live TV interface inside XBMC at all, and instead just like on PrismCube it launches a separate closed source application (MaruApp on PrismCube) for the PVR and Live-TV parts, and my guess it is probably even the same separate application software launched being developed by the same developers at Marusus for both Vu+ and PrismCube.
I would very much like to see both Vu+ and PrismCube to instead use XBMC's own native PVR frontend GUI for PVR/DVR/EPG/Live-TV as the only interface on these boxes, and for that have a (headless) PVR-backend/server software which only works as a TV-tuner and recording server running as a background daemon service without a GUI.
I think that Vu+/PrismCube today is kind of ruining the XBMC experience by breaking the immersion of running the single application that is XBMC media center GUI, as it is right now Vu+/PrismCube is instead launching its own separate application for all PVR functions, and that separate application has its own GUI that only tries to emulate the look and feel of XBMC, but needs its own skin.
So it should instead in the future Vu+/PrismCube should port its own PVR backend TV server into a headless background running daemon service that work similar to like how Tvheadend PVR backend with XBMC works on a computer today, (and same if you use MediaPortal Server, VDR, or MythTV backend/server, etc. with XBMC). Which then all share the same XBMC's own native PVR frontend GUI for a common unified interface for everything, and the end-user should not even really need to know what PVR backend server that is running underneath it all.
Note again that I am not saying that Vu+/PrismCube should simply use Tvheadend or VDR. No I am instead saying that Vu+/PrismCube should convert the code for their existing TV tuning application into a PVR backend TV server that works similar to Tvheadend or VDR, without its own GUI. And to begin to instead fully utilize XBMC's native PVR frontend GUI, and soley use that GUI as the only end-user interface for Vu+/PrismCube that the users see on their TV display screen, following the XBMC' concept of how PVR should all the way completely, which happen to be standard client (frontend) to server (backend) model based
By switching to using XBMC's own native PVR frontend GUI and the PVR backend concept you will again all the benefits on a common development community that all work towards the same goal to improve XBMC's own native PVR frontend GUI and API interlace, no matter what PVR backend is used.
See example how Tvheadend integrates into XBMC/Kodi in OpenELEC (Linux distrubution dedicated for XBMC/Kodi):
If MaruApp was at least open source then that would sure be a little better, but if MaruApp TV server was instead only acting as a real PVR backend for XBMC then it would not matter as much if it was closed source, as then much could still be done in XBMC's open source code to improve the actual user experience.
The best scenario to get as many community developers involved as would of course be an open source MaruApp TV server, and open source Vu+/PrismCube PVR backend client for XBMC (that uses XBMC's PVR API), as then third-party community developers can assist in the whole chain, both working on bugs and developing new features or functions. This is the scenario that PVR backend client for XBMC is for Tvheadend, VDR, MediaPortal, and MythTV today and those all work great with very active community developers.
Second best would be closed source MaruApp TV server, and open source Vu+/PrismCube PVR backend client for XBMC (that uses XBMC's PVR API), as then third-party community developers could at least assist in developing both the Vu+/PrismCube PVR backend client for XBMC as well as XBMC. That is the scenario that ServerWMC is in today, which is a third-party open source WMC PVR backend client for XBMC that can still fully control closed source Microsoft Windows Media Center.
Third best would be closed source MaruApp TV server, and closed source Vu+/PrismCube PVR backend client for XBMC (that uses XBMC's PVR API), which would mean that Marusus would have to develop all the backend features themselves without assistance from the community, but at least the community could develop XBMC's PVR GUI, PVR API, and skins, which would improve the end-user experience to give used a completely unified interface and the ability to switch skin in XBMC (without having to skin MaruApp separately).
However today we are almost looking at at almost the worse possible XBMC experience possible on Vu+/PrismCube, with the separate MaruApp having it's own GUI. The only worse XBMC experience I can think of is if the MaruApp did not have the same look and feel as XBMC, but I think it is still bad enough as it is today.
I have the huge problem with this as it is then utilizing the full potential of XBMC by not actually using XBMC's internal PVR frontend GUI unified interface.
That is, XBMC on on Vu+ (nor PrismCube or XBMC) seem to use the integrated PVR or Live TV interface inside XBMC at all, and instead just like on PrismCube it launches a separate closed source application (MaruApp on PrismCube) for the PVR and Live-TV parts, and my guess it is probably even the same separate application software launched being developed by the same developers at Marusus for both Vu+ and PrismCube.
I would very much like to see both Vu+ and PrismCube to instead use XBMC's own native PVR frontend GUI for PVR/DVR/EPG/Live-TV as the only interface on these boxes, and for that have a (headless) PVR-backend/server software which only works as a TV-tuner and recording server running as a background daemon service without a GUI.
Code:
http://kodi.wiki/index.php?title=PVRI think that Vu+/PrismCube today is kind of ruining the XBMC experience by breaking the immersion of running the single application that is XBMC media center GUI, as it is right now Vu+/PrismCube is instead launching its own separate application for all PVR functions, and that separate application has its own GUI that only tries to emulate the look and feel of XBMC, but needs its own skin.
So it should instead in the future Vu+/PrismCube should port its own PVR backend TV server into a headless background running daemon service that work similar to like how Tvheadend PVR backend with XBMC works on a computer today, (and same if you use MediaPortal Server, VDR, or MythTV backend/server, etc. with XBMC). Which then all share the same XBMC's own native PVR frontend GUI for a common unified interface for everything, and the end-user should not even really need to know what PVR backend server that is running underneath it all.
Note again that I am not saying that Vu+/PrismCube should simply use Tvheadend or VDR. No I am instead saying that Vu+/PrismCube should convert the code for their existing TV tuning application into a PVR backend TV server that works similar to Tvheadend or VDR, without its own GUI. And to begin to instead fully utilize XBMC's native PVR frontend GUI, and soley use that GUI as the only end-user interface for Vu+/PrismCube that the users see on their TV display screen, following the XBMC' concept of how PVR should all the way completely, which happen to be standard client (frontend) to server (backend) model based
Code:
http://en.wikipedia.org/wiki/Client–server_modelBy switching to using XBMC's own native PVR frontend GUI and the PVR backend concept you will again all the benefits on a common development community that all work towards the same goal to improve XBMC's own native PVR frontend GUI and API interlace, no matter what PVR backend is used.
See example how Tvheadend integrates into XBMC/Kodi in OpenELEC (Linux distrubution dedicated for XBMC/Kodi):
Code:
http://wiki.openelec.tv/index.php/Configuring_TvheadendIf MaruApp was at least open source then that would sure be a little better, but if MaruApp TV server was instead only acting as a real PVR backend for XBMC then it would not matter as much if it was closed source, as then much could still be done in XBMC's open source code to improve the actual user experience.
The best scenario to get as many community developers involved as would of course be an open source MaruApp TV server, and open source Vu+/PrismCube PVR backend client for XBMC (that uses XBMC's PVR API), as then third-party community developers can assist in the whole chain, both working on bugs and developing new features or functions. This is the scenario that PVR backend client for XBMC is for Tvheadend, VDR, MediaPortal, and MythTV today and those all work great with very active community developers.
Second best would be closed source MaruApp TV server, and open source Vu+/PrismCube PVR backend client for XBMC (that uses XBMC's PVR API), as then third-party community developers could at least assist in developing both the Vu+/PrismCube PVR backend client for XBMC as well as XBMC. That is the scenario that ServerWMC is in today, which is a third-party open source WMC PVR backend client for XBMC that can still fully control closed source Microsoft Windows Media Center.
Third best would be closed source MaruApp TV server, and closed source Vu+/PrismCube PVR backend client for XBMC (that uses XBMC's PVR API), which would mean that Marusus would have to develop all the backend features themselves without assistance from the community, but at least the community could develop XBMC's PVR GUI, PVR API, and skins, which would improve the end-user experience to give used a completely unified interface and the ability to switch skin in XBMC (without having to skin MaruApp separately).
However today we are almost looking at at almost the worse possible XBMC experience possible on Vu+/PrismCube, with the separate MaruApp having it's own GUI. The only worse XBMC experience I can think of is if the MaruApp did not have the same look and feel as XBMC, but I think it is still bad enough as it is today.
Last edited by a moderator: