Dear VDR folks,
as you might have noticed in the thread of the announcement for version 1.7.25 there is some ongoing discussion about a client/server implementation for VDR which Klaus said to look at after the VDR 2.0 release.
I just want to throw in, that there are several programs already using a client/server approach (MythTV [1], Tvheadend [2], …) and we should not reinvent the wheel when designing the new implementation. That means maybe folks having already used some of the other programs could write down the pros and the cons of their implementation. Maybe even the developers of these programs could be asked to comment on that and to give hints.
Just a thought.
Thanks,
Paul
[1] http://www.mythtv.org [2] https://www.lonelycoder.com/tvheadend/
On Thursday 01 March 2012 - 10:31:37, Paul Menzel wrote:
On Thursday 01 March 2012 - 07:03:03, VDR User wrote:
I just want to throw in, that there are several programs already using a client/server approach (MythTV [1], Tvheadend [2], …) and we should not reinvent the wheel when designing the new implementation.
I'd like to oppose headline and last statement.
"We" can do better, so let's go ahead :)
I don't know MythTV, but I tried tvheadend. It has a really attractive backend, but no (working) frontend. Starting vlc from browser crashes the browser and the frontend does not connect to backend at all.
With available docs from programs website there's no way to get a working C/S solution (refering to debian stable).
So from a users point of view, I prefer a working solution with "suboptimal" design over an attractive design, that does not work.
If Klaus is clear about what he wants and is in good communication with other coders, perhaps it could become more of a team effort with Klaus as team captain..
+1
Keep in mind, people have been wishing for VDR to go this route for quite a while so even if it means extra work fixing plugins, I think you'll find more people welcoming this change than not.
+1
maybe it would be a wise idea to start a dedicated thread to it for collecting information on identifying the needs/wants, and ways they can be met. This is a great opportunity to thoroughly think things through so the actual server/client design & integration addresses all the necessary considerations.
+1
kind regards
Gero
On 03/01/2012 03:31 PM, Gero wrote:
I don't know MythTV, but I tried tvheadend. It has a really attractive backend, but no (working) frontend. Starting vlc from browser crashes the browser and the frontend does not connect to backend at all.
Say you've been unable to manage to do it ;-)
Im currently steaming forma dual tuner on two xbmc ;-)
--eric
On Thursday 01 March 2012 - 15:59:24, Eric Valette wrote:
On 03/01/2012 03:31 PM, Gero wrote:
I don't know MythTV, but I tried tvheadend. It has a really attractive backend, but no (working) frontend. Starting vlc from browser crashes the browser and the frontend does not connect to backend at all.
Say you've been unable to manage to do it ;-)
Sure!
Im currently steaming forma dual tuner on two xbmc ;-)
xbmc is not part of tvheadend, so it does not count. ... additionally I don't want xbmc. I want a small client like vdr-sxfe that simply works ;)
There are various solutions of C/S with vdr, but all are addons. I don't see any benefit of tvheadend + xbmc against "my" vdr-setup.
kind regards
Gero
On 03/01/2012 05:02 PM, Gero wrote:
Im currently steaming forma dual tuner on two xbmc ;-)
xbmc is not part of tvheadend, so it does not count.
But XBMC incorporates via plugin tvheadend support (as vdr but not via streamdev btw).
There are various solutions of C/S with vdr, but all are addons. I don't see any benefit of tvheadend + xbmc against "my" vdr-setup.
integration of iptv, simplicity, efficiency and the fact that the HTSP protool is built-in.
-- eric
On 03/01/2012 05:02 PM, Gero wrote:
browser and the frontend does not connect to backend at all.
Say you've been unable to manage to do it;-)
Su
I'd say we should let Klaus reinvent the wheel. I'm pretty sure he (using us as testers) can do better than myth/tvheadend. As an electronics design engineer, I myself do a lot better work if I'm allowed to do it the way I want instead of trying to copy someone elses design. /Magnus H
Am Donnerstag, den 01.03.2012, 15:31 +0100 schrieb Gero:
On Thursday 01 March 2012 - 10:31:37, Paul Menzel wrote:
On Thursday 01 March 2012 - 07:03:03, VDR User wrote:
I just want to throw in, that there are several programs already using a client/server approach (MythTV [1], Tvheadend [2], …) and we should not reinvent the wheel when designing the new implementation.
I'd like to oppose headline and last statement.
"We" can do better, so let's go ahead :)
It looks like my message was not clear enough. I meant we should look at what other projects implemented and tried and take the good ideas and use those. So of course the result will probably be better.
But cooperation like on using already existing protocols would be a big advantage, because in this way already existing clients or servers can be used to or tested against.
[…]
Thanks,
Paul
Paul Menzel paulepanter@users.sourceforge.net writes:
Am Donnerstag, den 01.03.2012, 15:31 +0100 schrieb Gero:
On Thursday 01 March 2012 - 10:31:37, Paul Menzel wrote:
On Thursday 01 March 2012 - 07:03:03, VDR User wrote:
I just want to throw in, that there are several programs already using a client/server approach (MythTV [1], Tvheadend [2], …) and we should not reinvent the wheel when designing the new implementation.
I'd like to oppose headline and last statement.
"We" can do better, so let's go ahead :)
It looks like my message was not clear enough. I meant we should look at what other projects implemented and tried and take the good ideas and use those. So of course the result will probably be better.
But cooperation like on using already existing protocols would be a big advantage, because in this way already existing clients or servers can be used to or tested against.
Do you also imply the use of things like git/github ?
On Thursday 01 March 2012 - 17:45:02, Paul Menzel wrote:
Am Donnerstag, den 01.03.2012, 15:31 +0100 schrieb Gero:
On Thursday 01 March 2012 - 10:31:37, Paul Menzel wrote:
On Thursday 01 March 2012 - 07:03:03, VDR User wrote:
I just want to throw in, that there are several programs already using a client/server approach (MythTV [1], Tvheadend [2], …) and we should not reinvent the wheel when designing the new implementation.
I'd like to oppose headline and last statement.
"We" can do better, so let's go ahead :)
It looks like my message was not clear enough. I meant we should look at what other projects implemented and tried and take the good ideas and use those. So of course the result will probably be better.
I believe, the better way would be, collect all requirements and wishes and start from scratch without caring about existing code (no matter wether it is vdr-code or other code). Current vdr already contains most functionality, so code needs "only" to be structured in a different way.
Most lowlevel functionality of vdr is good and I don't see the need to look at other projects.
What needs to be rewritten is the higher level application code and starting from scratch opens the chance to establish a clean design, that is flexible enuf for future requirements. Existing plugins will - of cause - be broken, but starting them from scratch with the new archtecture will be faster than first development.
But cooperation like on using already existing protocols would be a big advantage, because in this way already existing clients or servers can be used to or tested against.
I think, support of existing protocols to connect to other clients or more general other apps can and should stil be delegated to plugins. It should not be the main focus of vdr to wish to connect to other clients.
Even more - I believe, if future design of vdr is good enuf, there's no more need to want any other clients :)
kind regards
Gero
-
Eric Valette -
Gero -
Magnus Hörlin -
Paul Menzel -
syrius.ml＠no-log.org