[vdr] Client/server implementation after VDR 2.0: Do not reinvent the wheel

[Paul Menzel]

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/

[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 :)

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

[Eric Valette]

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

[Gero]

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

[Eric Valette]

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

[Magnus Hörlin]

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

[Paul Menzel]

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

[s***@no-log.org]

Paul Menzel <***@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 ?

--

[Gero]

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