[vdr] Theses Client/Server VDR

[fnu]

Hi there,

following the discussion regarding Client/Server the last couple of day, I'm
honestly horrified.

What I did realize where super complex ideas, hacks, bottomline a solution
from developers for developers. I got the imagination some want to keep out
normal users, inventing VDR to death, because only a few users are able to
handle it.

Since Apple pretty much come with a TV solution this year, expectations of
users will change in terms of GUI & usability. And not only Apple, even
Ubuntu does invent in the same direction on their UbuntuTV.

There's no need to copy these solutions, but the need to be prepared to
these fast changing expectations. To think about the details of VDR, a good
and stable solution, which I love to use since over 10 years now.

I don't have any issues to run a complete VDR on Client and Server, the
binary is small, so what.

My dream of a Client/Server VDR solution is:

- 1+n VDRs do find themselfs seemless w/o user interaction within a network
- 1+n VDRs do elect/define a principle, which become the leader of the pack,
preferably that one with (the most) DVB devices
- The principle becomes the central point of VDR operation
- Timers set on whether Client/Server VDR, is handled by the principle
centrally
- Recordings are also handled centrally on the principle, the clients do
have seemless access to it
- It doesn't matter if the clients do have their own disks
- But if needed principle can use this addional disk space on clients and
each client does also have seemless access
- DVB devices can be added and removed dynamically to each of the VDRs, but
principle stay responsible for all DVB devices within network
- Plugins can be added/removed dynamically via OSD or a Web-Interface
- The VDR pack or rather the principle can be controlled/programmed by a
cloud service from all over the world.
- Setting up one of these VDRs may only be possible for experienced user,
but es soon as they're up and running, you're little children could hanle
them.

Just my vision for a smart client/server VDR solution.

Cheers
fnu

[Lars Hanisch]

Hi,

Post by fnu
Hi there,
following the discussion regarding Client/Server the last couple of day, I'm
honestly horrified.
What I did realize where super complex ideas, hacks, bottomline a solution
from developers for developers. I got the imagination some want to keep out
normal users, inventing VDR to death, because only a few users are able to
handle it.
Since Apple pretty much come with a TV solution this year, expectations of
users will change in terms of GUI& usability. And not only Apple, even
Ubuntu does invent in the same direction on their UbuntuTV.
There's no need to copy these solutions, but the need to be prepared to
these fast changing expectations. To think about the details of VDR, a good
and stable solution, which I love to use since over 10 years now.
I don't have any issues to run a complete VDR on Client and Server, the
binary is small, so what.
- 1+n VDRs do find themselfs seemless w/o user interaction within a network
- 1+n VDRs do elect/define a principle, which become the leader of the pack,
preferably that one with (the most) DVB devices

Since automatism may be wrong (same number of devices in each vdr or whatever), a simple priority numbering scheme of
the vdrs should be possible. Something like: "This is my main vdr (priority 100), this vdr has priority 50 etc."
I think this could be handled by every user and it can be easily configured via OSD. :)

Lars.

Post by fnu
- The principle becomes the central point of VDR operation
- Timers set on whether Client/Server VDR, is handled by the principle
centrally
- Recordings are also handled centrally on the principle, the clients do
have seemless access to it
- It doesn't matter if the clients do have their own disks
- But if needed principle can use this addional disk space on clients and
each client does also have seemless access
- DVB devices can be added and removed dynamically to each of the VDRs, but
principle stay responsible for all DVB devices within network
- Plugins can be added/removed dynamically via OSD or a Web-Interface
- The VDR pack or rather the principle can be controlled/programmed by a
cloud service from all over the world.
- Setting up one of these VDRs may only be possible for experienced user,
but es soon as they're up and running, you're little children could hanle
them.
Just my vision for a smart client/server VDR solution.
Cheers
fnu
_______________________________________________
vdr mailing list
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

[fnu]

Post by Lars Hanisch
Since automatism may be wrong

No, absolutely not, just to keep it super simple for the user.

But yes, I did imply to give interessted users the possibilty to do an
override, which VDR is princible in users personal VDR cloud or the other
settings. Somewhere deep in the OSD ...

Regards
fnu

-----Ursprüngliche Nachricht-----
Von: vdr-***@linuxtv.org [mailto:vdr-***@linuxtv.org] Im Auftrag von
Lars Hanisch
Gesendet: Samstag, 3. März 2012 18:51
An: ***@linuxtv.org
Betreff: Re: [vdr] Theses Client/Server VDR

Hi,

Post by Lars Hanisch
Hi there,
following the discussion regarding Client/Server the last couple of
day, I'm honestly horrified.
What I did realize where super complex ideas, hacks, bottomline a
solution from developers for developers. I got the imagination some
want to keep out normal users, inventing VDR to death, because only a
few users are able to handle it.
Since Apple pretty much come with a TV solution this year,
expectations of users will change in terms of GUI& usability. And not
only Apple, even Ubuntu does invent in the same direction on their

UbuntuTV.

Post by Lars Hanisch
There's no need to copy these solutions, but the need to be prepared
to these fast changing expectations. To think about the details of
VDR, a good and stable solution, which I love to use since over 10 years

now.

Post by Lars Hanisch
I don't have any issues to run a complete VDR on Client and Server,
the binary is small, so what.
- 1+n VDRs do find themselfs seemless w/o user interaction within a network
- 1+n VDRs do elect/define a principle, which become the leader of the
pack, preferably that one with (the most) DVB devices

Since automatism may be wrong (same number of devices in each vdr or
whatever), a simple priority numbering scheme of the vdrs should be
possible. Something like: "This is my main vdr (priority 100), this vdr has
priority 50 etc."
I think this could be handled by every user and it can be easily
configured via OSD. :)

Lars.

Post by Lars Hanisch
- The principle becomes the central point of VDR operation
- Timers set on whether Client/Server VDR, is handled by the principle
centrally
- Recordings are also handled centrally on the principle, the clients
do have seemless access to it
- It doesn't matter if the clients do have their own disks
- But if needed principle can use this addional disk space on clients
and each client does also have seemless access
- DVB devices can be added and removed dynamically to each of the
VDRs, but principle stay responsible for all DVB devices within
network
- Plugins can be added/removed dynamically via OSD or a Web-Interface
- The VDR pack or rather the principle can be controlled/programmed by
a cloud service from all over the world.
- Setting up one of these VDRs may only be possible for experienced
user, but es soon as they're up and running, you're little children
could hanle them.
Just my vision for a smart client/server VDR solution.
Cheers
fnu

[VDR User]

Just a few quick thoughts...

Clients have their own independent osd.
Clients have their own display and audio settings.
Clients detect disconnect-from-server and attempt reconnect.
Client labels (living room, office, kids, man cave, etc) for easy
maintenance & identification.

Servers able to (dis)allow timer privileges (create, modify, delete)
for each client.
Servers able to (dis)allow recording privileges (edit, delete) for each client.
Servers able to handle multiple clients that may be trying to
modify/edit things such as timers & recordings.
Servers should have smart device selection. For example if dvb-s is
requested, use an available dvb-s device before dvb-s2. If a non-turbo
fec device is requested, use an available non-turbo fec device before
one that supports turbo fec. Or some method by which users can create
their own device priority list.

[fnu]

Nothing to complain, these thoughts do particularize my sketched vision ...
;-)

-----Ursprüngliche Nachricht-----
Von: vdr-***@linuxtv.org [mailto:vdr-***@linuxtv.org] Im Auftrag von
VDR User
Gesendet: Samstag, 3. März 2012 22:24
An: VDR Mailing List
Betreff: Re: [vdr] Theses Client/Server VDR

Just a few quick thoughts...

Clients have their own independent osd.
Clients have their own display and audio settings.
Clients detect disconnect-from-server and attempt reconnect.
Client labels (living room, office, kids, man cave, etc) for easy
maintenance & identification.

Servers able to (dis)allow timer privileges (create, modify, delete) for
each client.
Servers able to (dis)allow recording privileges (edit, delete) for each
client.
Servers able to handle multiple clients that may be trying to modify/edit
things such as timers & recordings.
Servers should have smart device selection. For example if dvb-s is
requested, use an available dvb-s device before dvb-s2. If a non-turbo fec
device is requested, use an available non-turbo fec device before one that
supports turbo fec. Or some method by which users can create their own
device priority list.

[Tony Houghton]

On Sat, 3 Mar 2012 13:24:11 -0800

Post by VDR User
Servers able to (dis)allow timer privileges (create, modify, delete)
for each client.
Servers able to (dis)allow recording privileges (edit, delete) for each client.

A reasonable idea, but IMO it would need to be easily configurable on
the fly, eg in vdradmin, not buried in a config file that requires VDR
to be restarted after editing.

[VDR User]

Post by Tony Houghton

Post by VDR User
Servers able to (dis)allow timer privileges (create, modify, delete)
for each client.
Servers able to (dis)allow recording privileges (edit, delete) for each client.

A reasonable idea, but IMO it would need to be easily configurable on
the fly, eg in vdradmin, not buried in a config file that requires VDR
to be restarted after editing.

I think restarts should be avoided as much as possible. There's
nothing more annoying than restart/reboot, especially when it's not
necessary!

[Tobias Hachmer]

Hello list,

this topic seems very interesting. I think it's overdue in times a lot
of software is client/server oriented to conform the vdr.
Are there any plans how to start with this project? Will the maintainer
of vdr support this or will there be a fork?

Tobias Hachmer

[Klaus Schmidinger]

Post by Tobias Hachmer
Hello list,
this topic seems very interesting. I think it's overdue in times a lot of software is client/server oriented to conform the vdr.
Are there any plans how to start with this project? Will the maintainer of vdr support this or will there be a fork?

I'll get to this after version 2.0.

Klaus

[fnu]

Dear Tobias,

this was just my vision of a Client/Server capable VDR concept. I felt urged to sketch this user friendly concept, after a similar (horrible) discussion here on mailing list, where developer did discuss complex solutions just for developers.

I don't have the ability to provide a fork and honestly don't want to have one. It would rather be cool if some of the ideas become part within the one and only VDR.

But I don't know if Klaus does have a sneek view into this vision at all, it's up to him. This wasn't a claim, just a sketched design study how an upcoming Client/Server capable VDR could look like on the surface. The details under the hood are far away from being specified. So, don't wait for it, even if it comes (partly) it will be a version 2.2 or further, please let Klaus finish 2.0 with all the good new features and HD capability, finally.

Thanks to all, it seems the ideas did found some fellower.

Cheers
Frank

-----Original Message-----
From: vdr-***@linuxtv.org [mailto:vdr-***@linuxtv.org] On Behalf Of Tobias Hachmer
Sent: Monday, March 12, 2012 9:34 AM
To: ***@linuxtv.org
Subject: Re: [vdr] Theses Client/Server VDR

Hello list,

this topic seems very interesting. I think it's overdue in times a lot of software is client/server oriented to conform the vdr.
Are there any plans how to start with this project? Will the maintainer of vdr support this or will there be a fork?

Tobias Hachmer