Hi Rion
I really think we’ve been super clear about this already.
There’s been extensive initial discussion here:
We do intend to develop a replacement Linux player - the details of which have already been published on this forum here:
I don’t see us targetting current RPi hardware. It really isn’t a good choice. It’s limited in power and expansion, especially when compared to systems like the Intel Compute Stick, NUC etc. It’s very much geared to things like Kodi where a single video playback is sufficient. Xibo is much much more demanding than that.
The existing Python player is tied to 1.6 series CMS and would take significant work to make it compatible with a 1.7 CMS, and given it’s unreliability and fragile software stack I’m not prepared to do that. It’s Open Source and you are of course free to do with it as you wish within the licence terms, but we really wouldn’t be moving on from it if we felt it was salvageable in its current state.
I really don’t think your comment that Xibo has moved towards close source is in any way fair or true. Spring Signage has released a commercial application to bring Xibo to Android, the funds from that pay for the project to run, and pay the development and support teams, without whom there wouldn’t be the system in its current state. Xibo would likely be yet another abandoned project on Launchpad or Github, or at best running at a much slower pace and with a far less mature product.
The reason there’s a step change between 1.6 and 1.7 in terms of Player compatibility is that around that time, we started doing alot of the pre-rendering on the CMS side - for example to support datasets, improved tickers etc. The now ancient version of Chrome available to us in libavg via Berkelium simply can’t render that content. Berkelium is a dead project (because there’s nothing behind it driving it). A clean break is required to a stack which is supportable going in to the future - which is what we’ve proposed and what we will deliver.