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
Hi,
Am 02.03.2012 11:12, schrieb fnu:
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.
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-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] Im Auftrag von Lars Hanisch Gesendet: Samstag, 3. März 2012 18:51 An: vdr@linuxtv.org Betreff: Re: [vdr] Theses Client/Server VDR
Hi,
Am 02.03.2012 11:12, schrieb fnu:
UbuntuTV.
now.
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.
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.
Nothing to complain, these thoughts do particularize my sketched vision ... ;-)
-----Ursprüngliche Nachricht----- Von: vdr-bounces@linuxtv.org [mailto:vdr-bounces@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.
_______________________________________________ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
On Sat, 3 Mar 2012 13:24:11 -0800 VDR User user.vdr@gmail.com wrote:
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.
On Sun, Mar 4, 2012 at 5:39 AM, Tony Houghton h@realh.co.uk wrote:
I think restarts should be avoided as much as possible. There's nothing more annoying than restart/reboot, especially when it's not necessary!
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
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-bounces@linuxtv.org [mailto:vdr-bounces@linuxtv.org] On Behalf Of Tobias Hachmer Sent: Monday, March 12, 2012 9:34 AM To: vdr@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
-
fnu -
Klaus Schmidinger -
Lars Hanisch -
Tobias Hachmer -
Tony Houghton -
VDR User