Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 2012-03-02 00:18, schrieb Tony Houghton: Going off on a tangent, there's been some discussion about "Pause and rewind live TV". That could be implemented fairly easily in clients with a big RAM buffer, without adding any complexity to the server. Big RAM buffer means long breaks between channel changes. Gerald ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Thu, 01 Mar 2012 22:12:19 +0100 Manuel Reimer wrote: > Tony Houghton wrote: > > I don't think a plugin is enough. For better client-server VDR > > needs to support multiple clients watching different channels with > > different OSDs simultaneously. > > It just has to deliver the data. The OSD itself is created by the client. That's how most other TV software works, but if you count VDR itself as "server" and vdr-sxfe as "client" then my understanding is that the server generates the OSD and the client just renders the pixmap it gets from the server. That wouldn't necessarily have to change if and when VDR goes fully client-server, but if I was implementing something from scratch I'd prefer to do the rendering on the client. It would reduce server load and network traffic, and be more logical to my mind. And free up more of Klaus' time to concentrate on core functionality while other people can add bling :-). Going off on a tangent, there's been some discussion about "Pause and rewind live TV". That could be implemented fairly easily in clients with a big RAM buffer, without adding any complexity to the server. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 01.03.2012 22:25, schrieb Klaus Schmidinger: > Guys, *please*! I stated earlier that I am currently concentrating > on making a stable version 2.0, and that I will see to make client/server > a priority *after* that. Agreed, lets focus on 2.0 for now. We just got carried away dreaming of VDR 3.0 already. ;) Its never too early to dream tho'... Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Make.config.template broken in 1.7.24
Hello, if I have a look at the changes in 1.7.24, then for me it looks like the file "Make.config.template" is broken there. As Variables are set using "?=", the values in "Make.config.template" not longer override the defaults of "Makefile". I'd vote for reverting this change. Any objections? Yours Manuel ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On 01.03.2012 22:17, VDR User wrote: On Thu, Mar 1, 2012 at 12:12 PM, Udo Richter wrote: Am 01.03.2012 07:03, schrieb VDR User: one option to spread the workload could be Klaus assigning different portions to different contributors that would like to work on it. 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.. The number of Klaus per VDR has always been quite limited. A developer team would surely speed things up, but I also understand that Klaus prefers to keep all development in his own hands instead of delegating and supervising. Letting 'his baby' off the hook isn't easy, and I would understand if he prefers to keep it under control. I'm not talking about him releasing control of anything. I'm talking about people wanting& willing to help develope, being assigned a code task and parameters. When the work is complete, Klaus reviews and either accepts/merges, or instructs the coder what needs to be changed. There's no reason for Klaus to release control of anything in this model. As long as there's a clear instruction of what he wants, and good communication along the way, I can't think of any good reason against it. In a sense this already happens, just on a smaller scale. VDR already contains non-Klaus code. Surely there's a middle ground where development can be assisted because in reality this doesn't need to take forever. Nobody expects it to be finished in a week, but it doesn't need to take forever either. Guys, *please*! I stated earlier that I am currently concentrating on making a stable version 2.0, and that I will see to make client/server a priority *after* that. This discussion at the moment is rather distracting for me, because I do read each posting but don't want to add to this topic right now. I was hoping that, by saying I'll deal with client/server after version 2.0, this topic could be put to rest for the moment. Unfortunately the exact opposite has happened. Another lession learned... ;-) Klaus ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Tony Houghton wrote: I don't think a plugin is enough. For better client-server VDR needs to support multiple clients watching different channels with different OSDs simultaneously. It just has to deliver the data. The OSD itself is created by the client. Yours Manuel ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Thu, Mar 1, 2012 at 12:12 PM, Udo Richter wrote: > Am 01.03.2012 07:03, schrieb VDR User: >> one option to spread >> the workload could be Klaus assigning different portions to different >> contributors that would like to work on it. 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.. > > The number of Klaus per VDR has always been quite limited. A developer > team would surely speed things up, but I also understand that Klaus > prefers to keep all development in his own hands instead of delegating > and supervising. Letting 'his baby' off the hook isn't easy, and I would > understand if he prefers to keep it under control. I'm not talking about him releasing control of anything. I'm talking about people wanting & willing to help develope, being assigned a code task and parameters. When the work is complete, Klaus reviews and either accepts/merges, or instructs the coder what needs to be changed. There's no reason for Klaus to release control of anything in this model. As long as there's a clear instruction of what he wants, and good communication along the way, I can't think of any good reason against it. In a sense this already happens, just on a smaller scale. VDR already contains non-Klaus code. Surely there's a middle ground where development can be assisted because in reality this doesn't need to take forever. Nobody expects it to be finished in a week, but it doesn't need to take forever either. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 01.03.2012 07:03, schrieb VDR User: > one option to spread > the workload could be Klaus assigning different portions to different > contributors that would like to work on it. 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.. The number of Klaus per VDR has always been quite limited. A developer team would surely speed things up, but I also understand that Klaus prefers to keep all development in his own hands instead of delegating and supervising. Letting 'his baby' off the hook isn't easy, and I would understand if he prefers to keep it under control. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
Am 01.03.2012 06:37, schrieb Gero: >> A timer menu that belongs to a recording backend, a recording menu that >> displays content of storage modules, several frontends that can connect >> to one recording backend or several storage modules, ... > > I think, here is already the first shortcoming in design. May be cause you're > thinking with today plugins in mind? You got me wrong on that. My vision would be that timer UI and recording backend are two modules, and in a more complex environment there may be several UI frontends connected to one (or more?) recording backends. Any client should be able to edit timers on the server independently, the backend shouldn't even have any UI. In fact, any UI should be located in the frontend. For all sxfe fans: A frontend implementation itself could split into two parts, one server-side frontend, and one lightweight stream&OSD display. Or keep latency low and put a more complex frontend on the client, that acts independently of the server backend. A high-level frontend could connect to one or more receiver backends to get channels on demand, would be able to schedule timers on recording backend(s), and would be able to play back from storage sources. Why not allow a storage plugin to act as a media player instead of just VDR recording server? Or on-the-fly transcoding on recording? > Additionally it should be possible to configure the preferred input device > used > by this client for life-view. Other devices may be configured as fallback, in > case the preferred device is not available. Thought of that. Generally, the default link between video frontend and receiver backend should be handled like transfer mode, to make things more unique. For the case of FF cards, there could be an additional prefer-this-backend-for-this-frontend rule, and a shortcut in transfer control that routes the video stream within the card instead of user space. > As I already wrote, from my point of view, plugins may continue do > networking, > but the connection between backend- and frontend-part of vdr should not be > public nor affected by any plugin. Well, I have a different vision: More like recording server and streaming client, where all the UI logic resides in the client, and the server doesn't need to know about UI at all. One advantage: Allow a frontend to connect to more than one backend. For example, have two 'full' VDR systems with receivers, recording capabilities and storage, and some streaming clients. And then let each of them use any receiver, any recording capability, and any recording storage that is available. As said, the server itself could spawn several clients, so sxfe-like lightweight viewers can connect to it. There could also be shortcuts if backends are on the same machine or in the same executable, so not everything must go over network. However, thats all pretty much vision and far from being reality. Cheers, Udo ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Client/server implementation after VDR 2.0: Do not reinvent the whole wheel
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Client/server implementation after VDR 2.0: Do not reinvent the whole wheel
Paul Menzel 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 ? -- ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Client/server implementation after VDR 2.0: Do not reinvent the whole wheel
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 signature.asc Description: This is a digitally signed message part ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Client/server implementation after VDR 2.0: Do [not] reinvent the wheel
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Client/server implementation after VDR 2.0: Do [not] reinvent the wheel
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Client/server implementation after VDR 2.0: Do [not] reinvent the wheel
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Client/server implementation after VDR 2.0: Do [not] reinvent the wheel
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] Client/server implementation after VDR 2.0: Do [not] reinvent the wheel
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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
[vdr] Client/server implementation after VDR 2.0: Do not reinvent the wheel
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/ signature.asc Description: This is a digitally signed message part ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24
On Wed, 29 Feb 2012 21:33:31 +0100, Udo Richter wrote > Am 29.02.2012 16:17, schrieb Klaus Schmidinger: > > + The function cDevice::Receiving() now returns true if there is any > > receiver > > attached to the device. Its boolean parameter has no meaning any more. > > Please remember to drop the following line from PLUGINS.html, as it > is now finally completely void: > > > (any negative value will allow a cReceiver to be detached from its cDevice at any time.) > > This was handled via Receiving(true). > > This still leaves the live related receivers unhandled, and since > there's no way to port the 'volatile' patch without reverting your > changes, we still have the old osdteletext-channel-blocking bug. Wouldn't it help to run those live related receivers with priority IDLEPRIORITY and having cDevice::Receiving() ignore receivers with priority IDLEPRIORITY? The default priority of cReceiver should become IDLEPRIORITY instead of MINPRIORITY then. Regards, Frank ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
