[ANNOUNCE] VDR developer version 1.7.24

  On 25.02.2012 00:21, Frank Schmirler wrote:
> On Fri, 24 Feb 2012 19:33:06 +0100, Udo Richter wrote
>> Am 24.02.2012 17:23, schrieb Klaus Schmidinger:
>>> IIRC that whole "Primary Limit" thing was introduced because in the
>>> beginning
>>> the full featured DVB cards were unable to record and play at the same
>>> time.
>>> So it could happen that a timer occupied the primary device and left the
>>> user with a black screen. Since the old FF cards have been given the
>>> ability
>>> to do simultaneous recording and replay a long time ago, and the new TT
>>> S2-6400
>>> has been able to do this from the very start, I'd rather prefer to do
>>> away with
>>> the "Primary Limit" altogether - to make things simpler instead of more
>>> complex ;-)
>
> I was not aware of this as I have no FF card. For me, "Primary Limit" always
> was the "Priority of Live TV". Ok, MANUAL talks about being allowed to "use
> the primary DVB interface" and not denial to "affect live TV", but the use
> case "recordings that should take place only when there is nothing else to do,
> but should never keep the user from viewing stuff on the primary interface"
> clearly pointed into that direction.
>
> Always using priority 0 instead of a configurable "Primary Limit" means
> there's no way to get anything with less priority than live TV but without the
> "may always be detached" meaning of negative priorities.
>
> Streamdev is using the "Primary Limit" to control priorities between multiple
> clients and partially also between clients and server. Only "partially" due to
> transfer mode receiver device running with priority -1. Currently a plugin
> can't simply call GetDevice with a non-negative priority without disturbing
> Live TV in transfer mode. Some ugly workarounds were necessary in streamdev to
> handle this.
>
>>> Well, I don't like the idea of introducing yet another parameter
>>> ("volatile") here.
>>> The "priority" should be sufficient to solve this. So if you can suggest
>>> a solution
>>> that works solely with priorities, I might take a look ;-)
>
> Well, the -1 priority on the transfer mode receiver device solves the
> "receivers still attached when switching channels" problem. But it introduces
> an exceptional case which causes problems (osdteletext) or makes apparently
> simple things hard to handle (streamdev GetDevice). Trading this for an
> explicit parameter sounds like a very good deal to me.
>
>> Letting VDR know that a device will probably soon be detached was
>> one of the smarter solutions to this. Another alternative I was
>> thinking of was to let the device know that a receiver is 'live-
>> related', and thus can be canceled for another live view, but the
>> 'volatile' solution was more general.
>>
>> Maybe it would be possible to manually lower the transfer mode receivers
>> to -1 when calling GetDevice with live view, and raise them back to
>> PrimaryLimit (or 0) at the end. Not sure if that's more elegant...
>
> +1 for the "volatile" solution. Streamdev-server has to handle channel
> switches, too. On the server side they are not "live-related", but the problem
> is the same: The receivers for the previous channel are still attached.
> "Volatile" would obsolete an other workaround in streamdev.

Definitely *no* "volatile"!

PrimaryLimit is going to be dropped, since the old FF-DVB cards can now (since
version 1.7.21) be run with the --outputonly option to avoid problems with recording
high bandwidth channels. Besides, with HDTV becoming ever more popular those cards
are pretty much obsolete by now (the TT S2-6400 has no problems recording and replaying
high bandwidth channels simultaneously). And, last but not least, people using software
players won't notice this change, anyway.

There was also apparently some misunderstanding about what PrimaryLimit was supposed
to do. It was *never* meant to allow "Channel switching can cancel timers with priority <= Setup.PrimaryLimit" (as noted at the bottom of http://projects.vdr-developer.org/issues/show/10).
Its sole purpose was to not use the primary device for recording low priority
timers and leave the user with a black screen. Those days are long gone, and PrimaryLimit
is obsolete and causing nothing but trouble.

A recording shall *always* have priority over live viewing.

Since cReceivers can have priorities between -99 and 99, the priority
for an unused device has been changed from -1 to -100.

The attached patch implements all these changes (*.po files left out for
clarity). Please try this and let me know if anything doesn't work as
expected.
I did try running a recording on the primary device, so that live view
would be done in Transfer mode from the secondary device (only two devices
activated for testing) and had no problem with zapping through channels
with Up/Down. I also tried starting a recording on device 2 while in
Transfer Mode, and the live channel was switched to device 1 when the
recording kicked in.

Klaus
  

On Sat, 25 Feb 2012 15:39:17 +0100, Klaus Schmidinger wrote
> There was also apparently some misunderstanding about what 
> PrimaryLimit was supposed to do. It was *never* meant to allow 
> "Channel switching can cancel timers with priority <= 
> Setup.PrimaryLimit" (as noted at the bottom of http://projects.vdr-
> developer.org/issues/show/10). Its sole purpose was to not use the 
> primary device for recording low priority timers and leave the user 
> with a black screen. Those days are long gone, and PrimaryLimit is 
> obsolete and causing nothing but trouble.
> 
> A recording shall *always* have priority over live viewing.

I would be fine with that with respect to recordings, but this shouldn't be
generally true for cReceivers. What I'm hoping to get is the possiblity to
attach a cReceiver with a lower priority than live TV but without the
"cReceivers with negative priority do not count".

> Since cReceivers can have priorities between -99 and 99, the priority
> for an unused device has been changed from -1 to -100.

Udo Richter's patch basically turned "PrimaryLimit" into a configurable
"LiveTV priority". A "LiveTV priority" > 0 gains you cReceivers with a
priority less than live TV but still non-negative. To fix the "Transfer mode
receiver device has priority -1" problem, he introduced "volatile".

Instead of a configurable "LiveTV priority", your approach uses the fixed
priority value 0 for LiveTV. The new idle priority of -100 opens the range for
cReceivers with negative priority. The problem is, that *any* negative
priority is still considered as "may be detached anytime", so there's still no
real "cReceiver with less priority than live TV".

I suggest the following additional changes:
- instead of any negative priority, only priority -MAXPRIORITY gets the
special meaning of "may be detached anytime"
- the constructor of cReceiver should use default priority -MAXPRIORITY, so
not all plugins have to be updated to keep their previous behaviour
- use LIVEPRIORITY-1 as priority for cTransfer

I can't however overlook the impact these modifications have.

Regards,
Frank
  

On 27.02.2012 14:33, Frank Schmirler wrote:
> On Sat, 25 Feb 2012 15:39:17 +0100, Klaus Schmidinger wrote
>> There was also apparently some misunderstanding about what
>> PrimaryLimit was supposed to do. It was *never* meant to allow
>> "Channel switching can cancel timers with priority<=
>> Setup.PrimaryLimit" (as noted at the bottom of http://projects.vdr-
>> developer.org/issues/show/10). Its sole purpose was to not use the
>> primary device for recording low priority timers and leave the user
>> with a black screen. Those days are long gone, and PrimaryLimit is
>> obsolete and causing nothing but trouble.
>>
>> A recording shall *always* have priority over live viewing.
>
> I would be fine with that with respect to recordings, but this shouldn't be
> generally true for cReceivers. What I'm hoping to get is the possiblity to
> attach a cReceiver with a lower priority than live TV but without the
> "cReceivers with negative priority do not count".
>
>> Since cReceivers can have priorities between -99 and 99, the priority
>> for an unused device has been changed from -1 to -100.
>
> Udo Richter's patch basically turned "PrimaryLimit" into a configurable
> "LiveTV priority". A "LiveTV priority">  0 gains you cReceivers with a
> priority less than live TV but still non-negative. To fix the "Transfer mode
> receiver device has priority -1" problem, he introduced "volatile".
>
> Instead of a configurable "LiveTV priority", your approach uses the fixed
> priority value 0 for LiveTV. The new idle priority of -100 opens the range for
> cReceivers with negative priority. The problem is, that *any* negative
> priority is still considered as "may be detached anytime", so there's still no
> real "cReceiver with less priority than live TV".
>
> I suggest the following additional changes:
> - instead of any negative priority, only priority -MAXPRIORITY gets the
> special meaning of "may be detached anytime"
> - the constructor of cReceiver should use default priority -MAXPRIORITY, so
> not all plugins have to be updated to keep their previous behaviour
> - use LIVEPRIORITY-1 as priority for cTransfer
>
> I can't however overlook the impact these modifications have.

Me neither - and that's why I strongly oppose them ;-)

What exactly is the use case for this, anyway?

VDR has two purposes: "live view" and "recording". And the current
priority scheme handles this pretty well IMO.

Klaus
  

Am 27.02.2012 14:33, schrieb Frank Schmirler:
> Instead of a configurable "LiveTV priority", your approach uses the fixed
> priority value 0 for LiveTV. The new idle priority of -100 opens the range for
> cReceivers with negative priority. The problem is, that *any* negative
> priority is still considered as "may be detached anytime", so there's still no
> real "cReceiver with less priority than live TV".

Unfortunately not, because "may be detached anytime" is intentionally
broken since VDR 1.3.7 (2004). Fixing it would reintroduce the "Live TV
freeze on recording start" bug. Extending this to priorities down to -99
doesn't change anything, and I currently see no real advantage in it:
Why would someone want an unimportant stream with priority -10, and
another with -20? VDR itself doesn't use them, so anything below 0 would
be the same.

Maybe, with some ugly hacks, Streamdev could emulate the old
PrimaryLimit by adding some kind of priority offset to all streams, but
as long as the rest is all broken, there's no real point in it.

> - instead of any negative priority, only priority -MAXPRIORITY gets the
> special meaning of "may be detached anytime"

See above. Would require transfer mode to run on -99 too, otherwise
would re-introduce live TV freeze.

> - the constructor of cReceiver should use default priority -MAXPRIORITY, so
> not all plugins have to be updated to keep their previous behaviour
> - use LIVEPRIORITY-1 as priority for cTransfer

Such -1 offset workarounds usually don't work, I would prefer not to
have them. For example, one transfer device can still block another
before detaching or via Streamdev. The only consistent solution is to
give transfer mode the same priority as primary device live priority,
either PrimaryLimit or 0.


Cheers,

Udo
  

On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote
> On 27.02.2012 14:33, Frank Schmirler wrote:
> > I suggest the following additional changes:
> > - instead of any negative priority, only priority -MAXPRIORITY gets the
> > special meaning of "may be detached anytime"
> > - the constructor of cReceiver should use default priority -MAXPRIORITY, so
> > not all plugins have to be updated to keep their previous behaviour
> > - use LIVEPRIORITY-1 as priority for cTransfer
> >
> > I can't however overlook the impact these modifications have.
> 
> Me neither - and that's why I strongly oppose them ;-)

Then maybe it's time to return to KISS - perhaps in VDR 2.1.x? Maybe there's
more obsolete stuff which can be thrown overboard. I feel it's time to start
from scratch with the device selection code, keeping also the new challenges
in mind (like e.g. the HD/SD or DVB-S/-T simulcast thingy).

> What exactly is the use case for this, anyway?
> 
> VDR has two purposes: "live view" and "recording". And the current
> priority scheme handles this pretty well IMO.

I guess in the meantime you could add "network streaming" to the list of
purposes, too. There are a lots of people using streamdev out there for
VDR-to-VDR-, HTTP- or Multicast-Streaming of live TV. Especially the
VDR-to-VDR-Streaming part is challenging. The easy case is a headless server
somewhere in the attic. No need to care about live TV. But some people's
"server" is their main VDR in the living room and they usually want clients
with a priority which is lower than local live TV. That's the use case.

At the moment it all works pretty well in streamdev, but the whole thing is
quite fragile with respect to API changes, time-consuming to maintain (e.g. an
almost 1:1 copy of cDevice::GetDevice) or laborious (e.g. synchronisation with
VDR main thread for switching LiveTV). So it's not that streamdev depends on
Udo Richter's patch or PrimaryLimit. But I was hoping for some perspective to
get rid of some of the most ugly workarounds in the long run. The patch would
have been a big step into that direction. Still, for a nice solution some more
(but probably much less dramatic) modifications in the VDR core would be
necessary.

Regards,
Frank
  

On 28.02.2012 09:32, Frank Schmirler wrote:
> On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote
>> On 27.02.2012 14:33, Frank Schmirler wrote:
>>> I suggest the following additional changes:
>>> - instead of any negative priority, only priority -MAXPRIORITY gets the
>>> special meaning of "may be detached anytime"
>>> - the constructor of cReceiver should use default priority -MAXPRIORITY, so
>>> not all plugins have to be updated to keep their previous behaviour
>>> - use LIVEPRIORITY-1 as priority for cTransfer
>>>
>>> I can't however overlook the impact these modifications have.
>>
>> Me neither - and that's why I strongly oppose them ;-)
>
> Then maybe it's time to return to KISS - perhaps in VDR 2.1.x? Maybe there's
> more obsolete stuff which can be thrown overboard. I feel it's time to start
> from scratch with the device selection code, keeping also the new challenges
> in mind (like e.g. the HD/SD or DVB-S/-T simulcast thingy).

That's surely something I'm going to lok at after version 2.0.

>> What exactly is the use case for this, anyway?
>>
>> VDR has two purposes: "live view" and "recording". And the current
>> priority scheme handles this pretty well IMO.
>
> I guess in the meantime you could add "network streaming" to the list of
> purposes, too. There are a lots of people using streamdev out there for
> VDR-to-VDR-, HTTP- or Multicast-Streaming of live TV. Especially the
> VDR-to-VDR-Streaming part is challenging. The easy case is a headless server
> somewhere in the attic. No need to care about live TV. But some people's
> "server" is their main VDR in the living room and they usually want clients
> with a priority which is lower than local live TV. That's the use case.
>
> At the moment it all works pretty well in streamdev, but the whole thing is
> quite fragile with respect to API changes, time-consuming to maintain (e.g. an
> almost 1:1 copy of cDevice::GetDevice) or laborious (e.g. synchronisation with
> VDR main thread for switching LiveTV). So it's not that streamdev depends on
> Udo Richter's patch or PrimaryLimit. But I was hoping for some perspective to
> get rid of some of the most ugly workarounds in the long run. The patch would
> have been a big step into that direction. Still, for a nice solution some more
> (but probably much less dramatic) modifications in the VDR core would be
> necessary.

I'll keep this in mind for "after version 2.0".

Klaus
  

On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote:
> On 28.02.2012 09:32, Frank Schmirler wrote:
> > On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote
> >> On 27.02.2012 14:33, Frank Schmirler wrote:
> >>> I can't however overlook the impact these modifications have.
> >> 
> >> Me neither - and that's why I strongly oppose them ;-)
> > 
> > Then maybe it's time to return to KISS - perhaps in VDR 2.1.x? 

Oups - this principle is good to start on any date. 
Best would be start using it today :)

> > Maybe there's more obsolete stuff which can be thrown overboard. I feel
> > it's time to start from scratch with the device selection code, keeping
> > also the new challenges in mind (like e.g. the HD/SD or DVB-S/-T simulcast
> > thingy).

This is only one aspect, that really needs to be redesigned / completely 
rewritten from scratch.

> >> What exactly is the use case for this, anyway?
> >> 
> >> VDR has two purposes: "live view" and "recording". And the current
> >> priority scheme handles this pretty well IMO.
> > 
> > I guess in the meantime you could add "network streaming" to the list of
> > purposes, too. 

Sure!

But talking about future, I think a good VDR-design would be a real 
client/server-design. Or lets say a modern VDR consists of a backend and a 
frontend, which may run on different machines, but may also be run on the same 
machine.

So networking is evident and vital.

If I understand things right, the decoding of streams is a frontend task, so 
it would be possible to abstract all datasources as input. That means, streams 
may come from dvb-card, network, files (any file, that might contain stream 
data) and of cause from plugins, that might generate streams from pictures or 
the like.

So the backend (beside the recording/timer part) just uniforms the streams and 
makes them available via network.
Frontend demuxes/decodes the streams (if necessary) and routes them to the 
real output devices. 

Taking into account, that networking can be broadcasted via UDP or streamed 
over single TCP-connection, it implies that different frontends might use the 
same stream from backend or each frontend might use a different stream. That 
also implies a complete different handling of setup and/or input/commands from 
frontend.

If connection between backend- and frontend-vdr could be established over 
network, as well as using shared memory, the 2 parts could behave like one, if 
they were run on the same machine.

With that design, vdr could handle all media, that make sense respect to 
looking and listening, so no more need for xbmc and other hacks ;) 

> > At the moment it all works pretty well in streamdev, ...

As far as I understood available docs, streamdev is not able to handle 
recordings, so I would not say "all works"


> I'll keep this in mind for "after version 2.0".

Why so far?

I think, many vdr-users crave for redesign and I'm sure, that some users are 
willing to participate.


kind regards

Gero
  

On 28/02/12 10:24, Gero wrote:
>>> At the moment it all works pretty well in streamdev, ...
>
> As far as I understood available docs, streamdev is not able to handle
> recordings, so I would not say "all works"

Streamdev does work fine for recordings. However, I tend to use e-tobi's 
fuse filesystem to export the recordings dir over NFS
  

On 02/28/2012 11:24 AM, Gero wrote:

> I think, many vdr-users crave for redesign and I'm sure, that some users are
> willing to participate.


I drooped vdr in favor of tvheadend just for many of the design reason 
you mentioned:

	1) Clear backend/front end design,
	2) Better network protocol between the two,
	3) code simplicity

So look at the features and principles when redesigning.

-- eric
  

On Dienstag 28 Februar 2012, Eric Valette wrote:
> On 02/28/2012 11:24 AM, Gero wrote:
> > I think, many vdr-users crave for redesign and I'm sure, that some users
> > are willing to participate.
> 
> I drooped vdr in favor of tvheadend just for many of the design reason ...

Whow - I'm impressed ;)

Installation and configuration (!) - really sexy.

... but it's not that dau-proof than vdr-distributions like linVDR or yaVDR, 
so I think it could be a good template for future vdr-development, but not 
serve as a vdr-replacement.
At least I think, that OSD is a must have.

Generation of channel-list - so fast and easy (just few mouseclicks)
 - I never could imagine such an ease of usage.

I think it would be hard to beat that configuration in ease of use, flexibility 
and supported variants. With the webinterface its already ready for using 
android as remote :O

challenging goal ;)


kind regards 

Gero
  

On 02/28/2012 03:08 PM, Gero wrote:

> ... but it's not that dau-proof than vdr-distributions like linVDR or yaVDR,
> so I think it could be a good template for future vdr-development, but not
> serve as a vdr-replacement.

Well openelec distrib does have means to use tvheadend...

> At least I think, that OSD is a must have.

I prefer to have it in a front end that is able to manage a 
sophisticated remote correctly.


--eric
  

Eric Valette <Eric.Valette@Free.fr> writes:

> On 02/28/2012 03:08 PM, Gero wrote:
>
>> ... but it's not that dau-proof than vdr-distributions like linVDR or yaVDR,
>> so I think it could be a good template for future vdr-development, but not
>> serve as a vdr-replacement.
>
> Well openelec distrib does have means to use tvheadend...
>
>> At least I think, that OSD is a must have.
>
> I prefer to have it in a front end that is able to manage a
> sophisticated remote correctly.

what do you use as a frontend ? xbmc, showtime ?
is it possible to have multiple independant osd ?
i like the xine and xinelibouput plugins way a lot, on my laptop no
need to install a huge (and sometimes bloaty) media center, just have
to run xine or vdr-sxfe and it comes with tv+osd+remote.

--
  

On 02/28/2012 03:49 PM, syrius.ml@no-log.org wrote:
> Eric Valette<Eric.Valette@Free.fr>  writes:
>
>> On 02/28/2012 03:08 PM, Gero wrote:
>>
>>> ... but it's not that dau-proof than vdr-distributions like linVDR or yaVDR,
>>> so I think it could be a good template for future vdr-development, but not
>>> serve as a vdr-replacement.
>>
>> Well openelec distrib does have means to use tvheadend...
>>
>>> At least I think, that OSD is a must have.
>>
>> I prefer to have it in a front end that is able to manage a
>> sophisticated remote correctly.
>
> what do you use as a frontend ? xbmc, showtime ?

I use XBMC in general, but may also use mplayer or vlc using the http 
streaming URL from the web GUI.

> is it possible to have multiple independant osd ?

You mean not on the same machine right?

> i like the xine and xinelibouput plugins way a lot, on my laptop no
> need to install a huge (and sometimes bloaty) media center, just have
> to run xine or vdr-sxfe and it comes with tv+osd+remote.
>

The tvheadend HTSP streaming library is really thin. I guess integrating 
it is like integrating a streamdev client/vnsi client.

-- eric
  

Hi,

On Tuesday 28 February 2012 - 15:49:32, syrius.ml@no-log.org wrote:
> i like the xine and xinelibouput plugins way a lot, on my laptop no
> need to install a huge (and sometimes bloaty) media center, ...

Agreed! That's why I like vdr-sxfe. On standard distributions one file to 
install and it works out of the box.

Even a self-compiled frontend with fresh home-brewed xinelib is not a big 
thing and works without having to touch anything on the backend ...
I can't do the same with xine, which is already somewhat bloated too.

So, Yes - that's why I like my current VDR-setup :)


kind regards

Gero
  

On Mon, 27 Feb 2012 21:29:44 +0100, Udo Richter wrote
> Am 27.02.2012 14:33, schrieb Frank Schmirler:
> > Instead of a configurable "LiveTV priority", your approach uses the fixed
> > priority value 0 for LiveTV. The new idle priority of -100 opens the range for
> > cReceivers with negative priority. The problem is, that *any* negative
> > priority is still considered as "may be detached anytime", so there's still no
> > real "cReceiver with less priority than live TV".
> 
> Unfortunately not, because "may be detached anytime" is intentionally
> broken since VDR 1.3.7 (2004). Fixing it would reintroduce the "Live 
> TV freeze on recording start" bug.

Ah, I see. The "Receiving(true)" in cDvbDevice::ProvidesChannel which came in
with 1.3.8. That was the missing piece. Thanks for pointing me there.

> > - the constructor of cReceiver should use default priority -MAXPRIORITY, so
> > not all plugins have to be updated to keep their previous behaviour
> > - use LIVEPRIORITY-1 as priority for cTransfer
> 
> Such -1 offset workarounds usually don't work, I would prefer not to
> have them. For example, one transfer device can still block another
> before detaching or via Streamdev. The only consistent solution is to
> give transfer mode the same priority as primary device live priority,
> either PrimaryLimit or 0.

That was an attempt to get a solution without "volatile". A "don't ever use
priority "PrimaryLimit" (or 0) elsewhere" would have been better than nothing.

Regards,
Frank
  

I'm included in the list of people that wished VDR supported real
server/client. I don't mean hacks and workarounds but real true
support, which of course means a major redesign. I know several users
who hated to but left VDR because it lacks this. Bringing VDR to
modern times/needs would be absolutely great but based on previous
posts it seems very unlikely this is going to happen. :(

Then again it looked like Klaus would never give HD & non-FF priority
and that need was meet so who knows?
  

28.02.2012 12:24, Gero kirjoitti:
> On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote:
>> On 28.02.2012 09:32, Frank Schmirler wrote:
>>> On Mon, 27 Feb 2012 18:05:39 +0100, Klaus Schmidinger wrote
>>>> What exactly is the use case for this, anyway?
>>>>
>>>> VDR has two purposes: "live view" and "recording". And the current
>>>> priority scheme handles this pretty well IMO.
>>>
>>> I guess in the meantime you could add "network streaming" to the list of
>>> purposes, too. 
> 
> Sure!
> 
> But talking about future, I think a good VDR-design would be a real 
> client/server-design. Or lets say a modern VDR consists of a backend and a 
> frontend, which may run on different machines, but may also be run on the same 
> machine.
> 
> So networking is evident and vital.
> 
> If I understand things right, the decoding of streams is a frontend task, so 
> it would be possible to abstract all datasources as input. That means, streams 
> may come from dvb-card, network, files (any file, that might contain stream 
> data) and of cause from plugins, that might generate streams from pictures or 
> the like.
> 
> So the backend (beside the recording/timer part) just uniforms the streams and 
> makes them available via network.
> Frontend demuxes/decodes the streams (if necessary) and routes them to the 
> real output devices. 
> 
> Taking into account, that networking can be broadcasted via UDP or streamed 
> over single TCP-connection, it implies that different frontends might use the 
> same stream from backend or each frontend might use a different stream. That 
> also implies a complete different handling of setup and/or input/commands from 
> frontend.
> 
> If connection between backend- and frontend-vdr could be established over 
> network, as well as using shared memory, the 2 parts could behave like one, if 
> they were run on the same machine.
> 
> With that design, vdr could handle all media, that make sense respect to 
> looking and listening, so no more need for xbmc and other hacks ;) 

I'd very much like something that would result in a better-behaving
server-client VDR system, i.e. so that clients just see the
recordings,timers,channels,epg just like they are on the server, instead
of duplication and the mess when they get out-of-sync.

I guess Klaus wants to keep VDR working as a monolithic entity like it
currently is, though, but maybe a "thin-client" (VDR instance with
viewing+menu only, with timers/recordings/channels transmitted from the
main VDR instance) support could be added as an optional feature.

(and probably a similar "headless" option to have VDR without
current-channel and GUI and stuff like that, for the backend)

>>> At the moment it all works pretty well in streamdev, ...
> 
> As far as I understood available docs, streamdev is not able to handle 
> recordings, so I would not say "all works"
> 
> 
>> I'll keep this in mind for "after version 2.0".
> 
> Why so far?

Because 1.6.0 was released a long time ago, and we want a new stable
version soon? :)

> I think, many vdr-users crave for redesign and I'm sure, that some users are 
> willing to participate.
  

On Tuesday 28 February 2012 - 20:12:54, Anssi Hannula wrote:
> 28.02.2012 12:24, Gero kirjoitti:
> > On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote:
> >>
> >> I'll keep this in mind for "after version 2.0".
> > 
> > Why so far?
> 
> Because 1.6.0 was released a long time ago, and we want a new stable
> version soon? :)

Sure! - But next stable version would be 1.8 - wouldn't it?

So why no start redeeming pledges with 1.9?
I believe any day would be a good point to start :)


...or is it preferable see people move to real client/server systems and make 
them fit their every day requirements?
Networking has become familiar to lots of people without any IT background - 
nowadays lot of homes have a fritzbox with Wlan and a netbook with wlan too. 
Fritzbox has startet to integrate android phones with wlan - so that all is 
quite natural for non IT people yet.

So integrating a headless vdr into existing network is no more restricted to 
nerds (or at least every male teenager is a nerd).


kind regards

Gero
  

> Because 1.6.0 was released a long time ago, and we want a new stable
> version soon? :)

I agree, 1.7 devel versions have many nice improvements like the support
for hvr-4000's multiple frontends in same adapter.
Even thought most active users in this mail list very likely uses
developer versions, there are probably lot of users still using stable
1.6.0 and would also prefer to run the Next stable once released.

But I hope that the mentioned real client-server redesign that could
handle many simultaneous clients watching different streams would be
then the main goals next version after that. Current way of doing it
at least with xineliboutput is just too complex and error prone.

Mika
  

On Wed, 29 Feb 2012 05:38:06 +0100
Gero <geronimo013@gmx.de> wrote:

> On Tuesday 28 February 2012 - 20:12:54, Anssi Hannula wrote:
> > 28.02.2012 12:24, Gero kirjoitti:
> > > On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote:
> > >>
> > >> I'll keep this in mind for "after version 2.0".
> > > 
> > > Why so far?
> > 
> > Because 1.6.0 was released a long time ago, and we want a new stable
> > version soon? :)
> 
> Sure! - But next stable version would be 1.8 - wouldn't it?


Next stable will be 2.0 AFAIK ...
  

On Wednesday 29 February 2012 05:58:21 Mika Laitio wrote:
> > Because 1.6.0 was released a long time ago, and we want a new stable
> > version soon? :)
> 
> I agree, 1.7 devel versions have many nice improvements like the support
> for hvr-4000's multiple frontends in same adapter.
> Even thought most active users in this mail list very likely uses
> developer versions, there are probably lot of users still using stable
> 1.6.0 and would also prefer to run the Next stable once released.

And the Linux distributions will generally only package 'stable' versions.
  

On 29.02.2012 08:17, Steffen Barszus wrote:
> On Wed, 29 Feb 2012 05:38:06 +0100
> Gero<geronimo013@gmx.de>  wrote:
>
>> On Tuesday 28 February 2012 - 20:12:54, Anssi Hannula wrote:
>>> 28.02.2012 12:24, Gero kirjoitti:
>>>> On Tuesday 28 February 2012 - 10:11:48, Klaus Schmidinger wrote:
>>>>>
>>>>> I'll keep this in mind for "after version 2.0".
>>>>
>>>> Why so far?
>>>
>>> Because 1.6.0 was released a long time ago, and we want a new stable
>>> version soon? :)
>>
>> Sure! - But next stable version would be 1.8 - wouldn't it?
>
>
> Next stable will be 2.0 AFAIK ...

Yes, the next stable version will be 2.0.
Version 1.0 was the "SD version", and version 2.0 shall be the "HD version" ;-).

I'll see to make "client/server" a priority after that.

Klaus
  

On 29.02.2012 08:24, Dave wrote:

> And the Linux distributions will generally only package 'stable' versions.

For Debian I'm already packaging 1.7.x, because 1.6 became pretty much
useless nowadays. Wheezy is going to freeze in June and I hope that VDR
becomes stable until then.

Tobias
  

On 28.02.2012 16:48, Frank Schmirler wrote:
> On Mon, 27 Feb 2012 21:29:44 +0100, Udo Richter wrote
>> Am 27.02.2012 14:33, schrieb Frank Schmirler:
>>> Instead of a configurable "LiveTV priority", your approach uses the fixed
>>> priority value 0 for LiveTV. The new idle priority of -100 opens the range for
>>> cReceivers with negative priority. The problem is, that *any* negative
>>> priority is still considered as "may be detached anytime", so there's still no
>>> real "cReceiver with less priority than live TV".
>>
>> Unfortunately not, because "may be detached anytime" is intentionally
>> broken since VDR 1.3.7 (2004). Fixing it would reintroduce the "Live
>> TV freeze on recording start" bug.
>
> Ah, I see. The "Receiving(true)" in cDvbDevice::ProvidesChannel which came in
> with 1.3.8. That was the missing piece. Thanks for pointing me there.
>
>>> - the constructor of cReceiver should use default priority -MAXPRIORITY, so
>>> not all plugins have to be updated to keep their previous behaviour
>>> - use LIVEPRIORITY-1 as priority for cTransfer
>>
>> Such -1 offset workarounds usually don't work, I would prefer not to
>> have them. For example, one transfer device can still block another
>> before detaching or via Streamdev. The only consistent solution is to
>> give transfer mode the same priority as primary device live priority,
>> either PrimaryLimit or 0.
>
> That was an attempt to get a solution without "volatile". A "don't ever use
> priority "PrimaryLimit" (or 0) elsewhere" would have been better than nothing.

Even though VDR itself doesn't have the necessity for "remote receivers"
(yet), I see the problem for streamdev. I have therefore reconsidered
this matter and will make the following changes for the next developer
version:

- Revised priority handling to allow receivers with a priority that is lower than
   that of live viewing (with suggestions from Frank Schmirler):
   + An idle device (one that is not used for live viewing and has no receiver
     attached to it) now has priority IDLEPRIORITY (-100).
   + An unused CAM slot now has priority IDLEPRIORITY.
   + The default priority of a cReceiver is now MINPRIORITY (-99).
   + A device that is used only for live viewing (no matter whether it's in Transfer
     Mode or real live mode) now has priority TRANSFERPRIORITY (-1).
   + The function cDevice::Receiving() now returns true if there is any receiver
     attached to the device. Its boolean parameter has no meaning any more.
   + The default value for the Priority parameter of the function cDevice::ProvidesChannel()
     has been changed to IDLEPRIORITY.

When searching for a device for live viewing, VDR uses priority 0 for
the search (thus avoiding any devices that are serving actual timer recordings),
and - if going into Transfer Mode - gives the cReceiver a priority of -1.
That way the next search for a live device will be able to use the one
that is currently serving the Transfer Mode, because the search has a
higher priority (this is pretty much the same as it was before).

Now a "remote transfer mode" (which I assume is what streamdev and the like
implement) can use a "search priority" of, say, -10, and a transfer priority
of -11. That way the remote mechanism will also be able to reuse devices,
just like local Transfer Mode. And local live mode can override remotely
used devices due to its higher priority.


I'm currently testing these changes in my own production VDR (local live and transfer mode
only) and will release them in version 1.7.25 shortly. Let me know then if this works
for you.

Klaus
  

Klaus Schmidinger wrote:
> Yes, the next stable version will be 2.0.
> Version 1.0 was the "SD version", and version 2.0 shall be the "HD version" ;-).
>
> I'll see to make "client/server" a priority after that.

What does this mean? Do you plan built-in networking support or do you plan to 
improve streamdev? IMHO it is a big task to make really good networking support. 
Keeping this code separate (means: A plugin) isn't a that bad idea, I think. Of 
course, this plugin could be delivered directly with VDR, like the other 
"built-in" plugins.

Yours

Manuel
  

29.02.2012 10:30, Tobi kirjoitti:
> On 29.02.2012 08:24, Dave wrote:
> 
>> And the Linux distributions will generally only package 'stable' versions.
> 
> For Debian I'm already packaging 1.7.x, because 1.6 became pretty much
> useless nowadays. Wheezy is going to freeze in June and I hope that VDR
> becomes stable until then.

For Mageia (upcoming mga2) I just recently updated the packages to
1.7.x, and Fedora seems to also be shipping 1.7.x already.
  

On 29.02.2012 16:48, Manuel Reimer wrote:
> Klaus Schmidinger wrote:
>> Yes, the next stable version will be 2.0.
>> Version 1.0 was the "SD version", and version 2.0 shall be the "HD version" ;-).
>>
>> I'll see to make "client/server" a priority after that.
>
> What does this mean? Do you plan built-in networking support or do you plan to improve streamdev? IMHO it is a big task to make really good networking support. Keeping this code separate (means: A plugin) isn't a that bad idea, I think. Of course, this plugin could be delivered directly with VDR,
> like the other "built-in" plugins.

I'll cross that bridge when I get there ;-)

Klaus
  

On Wed, 29 Feb 2012 16:17:07 +0100, Klaus Schmidinger wrote
> Even though VDR itself doesn't have the necessity for "remote receivers"
> (yet), I see the problem for streamdev. I have therefore reconsidered
> this matter and will make the following changes for the next 
> developer version:
> 
> - Revised priority handling to allow receivers with a priority that 
> is lower than   that of live viewing (with suggestions from Frank 
> Schmirler):   + An idle device (one that is not used for live 
> viewing and has no receiver     attached to it) now has priority 
> IDLEPRIORITY (-100).   + An unused CAM slot now has priority IDLEPRIORITY.
>    + The default priority of a cReceiver is now MINPRIORITY (-99).
>    + A device that is used only for live viewing (no matter whether 
> it's in Transfer     Mode or real live mode) now has priority 
> TRANSFERPRIORITY (-1).   + The function cDevice::Receiving() now 
> returns true if there is any receiver     attached to the device. 
> Its boolean parameter has no meaning any more.   + The default value 
> for the Priority parameter of the function cDevice::ProvidesChannel()
>      has been changed to IDLEPRIORITY.
> 
> When searching for a device for live viewing, VDR uses priority 0 for
> the search (thus avoiding any devices that are serving actual timer 
> recordings), and - if going into Transfer Mode - gives the cReceiver 
> a priority of -1. That way the next search for a live device will be 
> able to use the one that is currently serving the Transfer Mode, 
> because the search has a higher priority (this is pretty much the 
> same as it was before).
> 
> Now a "remote transfer mode" (which I assume is what streamdev and 
> the like implement) can use a "search priority" of, say, -10, and a 
> transfer priority of -11. That way the remote mechanism will also be 
> able to reuse devices, just like local Transfer Mode. And local live 
> mode can override remotely used devices due to its higher priority.
> 
> I'm currently testing these changes in my own production VDR (local 
> live and transfer mode only) and will release them in version 1.7.25 
> shortly. Let me know then if this works for you.

Wow - this is good news. Thanks for reconsidering!

Frank
  

On Wed, 29 Feb 2012 16:48:33 +0100
Manuel Reimer <manuel.reimer@gmx.de> wrote:

> Klaus Schmidinger wrote:
> > Yes, the next stable version will be 2.0.
> > Version 1.0 was the "SD version", and version 2.0 shall be the "HD
> > version" ;-).
> >
> > I'll see to make "client/server" a priority after that.
> 
> What does this mean? Do you plan built-in networking support or do
> you plan to improve streamdev? IMHO it is a big task to make really
> good networking support. Keeping this code separate (means: A plugin)
> isn't a that bad idea, I think. Of course, this plugin could be
> delivered directly with VDR, like the other "built-in" plugins.

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.
  

On Wed, Feb 29, 2012 at 12:20 AM, Klaus Schmidinger
<Klaus.Schmidinger@tvdr.de> wrote:
> Yes, the next stable version will be 2.0.
> Version 1.0 was the "SD version", and version 2.0 shall be the "HD version"
> ;-).

Sounds good! :)

> I'll see to make "client/server" a priority after that.

I honestly had to read this a couple times to make sure I wasn't
misunderstanding some how. This is a huge announcement and I think
everyone will agree a big step in the right direction to suit modern
needs. Since it sounds like true server/client will really happen for
VDR now, 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.

...What an awesome way to start off the day! You're my hero Klaus! :D
  

On Wednesday 29 February 2012 - 17:50:27, Tony Houghton wrote:
> On Wed, 29 Feb 2012 16:48:33 +0100
> Manuel Reimer <manuel.reimer@gmx.de> wrote:
> > Klaus Schmidinger wrote:
> > > Yes, the next stable version will be 2.0.
> > > Version 1.0 was the "SD version", and version 2.0 shall be the "HD
> > > version" ;-).
> > > 
> > > I'll see to make "client/server" a priority after that.
> > 
> > What does this mean? Do you plan built-in networking support or do
> > you plan to improve streamdev? IMHO it is a big task to make really
> > good networking support. Keeping this code separate (means: A plugin)
> > isn't a that bad idea, I think. Of course, this plugin could be
> > delivered directly with VDR, like the other "built-in" plugins.
> 
> I don't think a plugin is enough. 

I agree.

I think, it is evident not confuse plugin-networking with client/server 
networking. OK, currently the client/server support works only through 
plugins, as there is no vdr-frontend - but Klaus should not care about plugin-
networking on designing client/server functionality.

C/S-communication should be completely private to vdr - just like internal 
communication. Plugins may keep on doing their networking, i.e. to connect 
other frontends like xine or whatever - but that's not the internal 
communication, vdr relies on.

> For better client-server VDR needs to support multiple clients watching
> different channels with different OSDs simultaneously.

Yeah, that would be very nice :)


kind regards

Gero
  

Am 29.02.2012 17:50, schrieb Tony Houghton:
> On Wed, 29 Feb 2012 16:48:33 +0100
> Manuel Reimer <manuel.reimer@gmx.de> wrote:
>> What does this mean? Do you plan built-in networking support or do
>> you plan to improve streamdev? IMHO it is a big task to make really
>> good networking support. Keeping this code separate (means: A plugin)
>> isn't a that bad idea, I think. Of course, this plugin could be
>> delivered directly with VDR, like the other "built-in" plugins.
> 
> 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.


Not necessarily. I think the key solution is to modularize VDR's
internal structures, with well defined interfaces between them. A
receiving module that provides stream sources, a recording module that
does all the timer work, a frontend module that can display, a storage
module that can store and provide videos, for example.
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, and all can connect
to different sources.

With defined and pluggable structures between them, its easy to have
them either locally connected or linked over network. Whether that's
done by a plugin or VDR internally doesn't matter.

In any case this would be the biggest rewrite of major parts of VDR
ever, with lots of breakage, total loss of plugin compatibility and very
long development cycle.


Cheers,

Udo
  

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.



What about having yet another plugin callback that fires before
switching a live channel? Currently, plugins get notified after channel
change, and thats too late to disconnect receivers early. And since
receiving at -1 doesn't have any special meaning any more, there's no
way to get receivers out of way early enough.

Roughly, the callback should be at the places where these two get called:

    DELETENULL(liveSubtitle);
    DELETENULL(dvbSubtitleConverter);

(Thats how VDR's own receivers get out of way.) That way, GetDevice(ch,
0, true) will still have the weired behavior of returning different
devices before and after initiating the live view channel switch, but at
least after disconnecting all live related receivers, the correct device
will be returned.


Cheers,

Udo
  

On Wednesday 29 February 2012 - 20:45:54, Udo Richter wrote:
> Am 29.02.2012 17:50, schrieb Tony Houghton:
> > For better client-server VDR needs to support multiple clients watching
> > different channels with different OSDs simultaneously.
> 
> Not necessarily. I think the key solution is to modularize VDR's
> internal structures, with well defined interfaces between them.

Well, that task is overdue, but not necessary to provide real a C/S app.
But I think, the C/S task is easier to workout after a complete redesign and 
modularization.
Additionally the modules should be grouped by layers, which makes design 
cleaner.

> 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?
If several independent clients open a timer menu, they should not interfere 
each other. If the menu is tied to the recording module (which should be a 
singleton), timer-menu would be like a singleton and a keystroke of one client 
changes the menu of all other clients too. That's not desired.

Therefore menu representation should be decoupled from menu data, so i.e. the 
recording module (as all backend modules) provides their data (the timer-list) 
as list or tree structure only. 

The vdr provides a menu for each client, which is based on the same 
(singleton) list of timers.
This way, each client can operate independently and if one client changes a 
timer, every other client will see the change - but no client is disturbed by 
the actions of other clients.

So from my point of view, future design will have different types of plugins, 
like backend- and frontend-plugin (or name the plugin templates by the layer 
they belong to). They might have the same interface, but I think, it is better 
to differ the interfaces, so a plugin cannot be misused by accident.
So backend-plugin (like nowadays dvdswitch) will only be allowed to provide a 
list of items, which will be used by OSD-Providers, that will create a menu 
different for each client and of cause, each menu can have different/independent 
state.
For configuration a backend module may only say, I need an integer value called 
"value", ranged from 0 to 5 with default of 2 - and it is up to the OSD-
painter (skin), whether to use a slider or an input field, or what ever ...
The backend module should not be allowed to care about user input elements.

Thinking about configuration, the backend should be able to configure the number 
of possible clients and so the open ports.

When a client connects, the vdr looks for a free input-module, that serves 
life-stream. Having multiple independent clients, the command to change the 
channel should not have any side-effect to other clients, nor disturb an active 
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.
For FF-clients it is evident to have a preferred input device without any 
fallback.
I think, this way no further distinction between FF-client and other clients 
is necessary.
 
> With defined and pluggable structures between them, its easy to have
> them either locally connected or linked over network. Whether that's
> done by a plugin or VDR internally doesn't matter.

Oh - I think it does matter!

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. 
And the connection does not have to be tied to networking. Networking is just 
one implementation of internal communication, which could easily replaced by a 
communication, that uses shared memory or pipes or what ever - if backend and 
frontend reside at the same machine.
So modules of internal connection may be interchangeable, but they should be 
considered private to vdr-core.

Don't know, whether it makes sense to look a existing C/S protocols. If I got 
it right, there's no standard for it and each plugin uses its own protocol. 
C/S networking needs one channel for streaming from server to client and one 
channel for commands from client to server. 
This 2-channel networking is standard for any networking, so I don't see, 
where networking is a challenge. It might be the smallest and easiest part of 
the redesign.

Real challenge is the break down and distribution of responsibility.

> In any case this would be the biggest rewrite of major parts of VDR
> ever, with lots of breakage, total loss of plugin compatibility and very
> long development cycle.

:) so the earlier this task starts, the earlier it may finish :)


kind regards

Gero
  

On Wed, Feb 29, 2012 at 11:45 AM, Udo Richter <udo_richter@gmx.de> wrote:
> In any case this would be the biggest rewrite of major parts of VDR
> ever, with lots of breakage, total loss of plugin compatibility and very
> long development cycle.

It's not a small task, but I believe the end product will be well
worth the effort. VDR has the benefit of having coder support. If
people are willing (as I think they would be), 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..
It's a lot of work but there's no reason it should take years to
complete either. Especially if the design is well-thought out ahead of
time.

As far as plugin breakage..  I would expect there to be some growing
pains and plugin maintainers needing to fix/add support for this is
just a necessary part of the progression. 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.
  

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
  

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
  

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
  

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
  

On Thu, Mar 1, 2012 at 12:12 PM, Udo Richter <udo_richter@gmx.de> 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.
  

On 01.03.2012 22:17, VDR User wrote:
> On Thu, Mar 1, 2012 at 12:12 PM, Udo Richter<udo_richter@gmx.de>  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
  

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
  

On Thu, 01 Mar 2012 22:12:19 +0100
Manuel Reimer <manuel.reimer@gmx.de> 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.
  

On 29.02.2012 21:33, 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.)

I don't think so. I've rather added the following note:

(any negative value will allow a cReceiver to be detached from its cDevice at any time
*in favor of a timer recording or live viewing*).

> 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.
>
>
>
> What about having yet another plugin callback that fires before
> switching a live channel? Currently, plugins get notified after channel
> change, and thats too late to disconnect receivers early. And since
> receiving at -1 doesn't have any special meaning any more, there's no
> way to get receivers out of way early enough.
>
> Roughly, the callback should be at the places where these two get called:
>
>      DELETENULL(liveSubtitle);
>      DELETENULL(dvbSubtitleConverter);
>
> (Thats how VDR's own receivers get out of way.)

There are two places in GetDevice() where cStatus::MsgChannelSwitch(this, 0)
is called, but they are both *after* the final call to GetDevice().
And there is this comment

   // only report status if we are actually going to switch the channel

which refers to a change that was made in version 1.1.10:

- Only calling cStatus::MsgChannelSwitch() if a channel is actually going to
   be switched or has actually been switched successfully (thanks to Stefan
   Huelswitt).

So before moving the call to cStatus::MsgChannelSwitch() to where it was
before version 1.1.10 (which I believe would be what you suggested above)
this needs to be given some thought. Personally I wouldn't mind making this
change, so if nobody objects, I will.

>  That way, GetDevice(ch,
> 0, true) will still have the weired behavior of returning different
> devices before and after initiating the live view channel switch, but at
> least after disconnecting all live related receivers, the correct device
> will be returned.

The reason why different devices may be selected here is because
when zapping through channels with Up and Down, the first GetDevice()
call is done while the current live channel
is still active, so the device currently used for live viewing may
be avoided because of receivers attached to it. If there is an other
device without receivers, but otherwise having the same "impact",
that one will be chosen. When the actual SetChannel() call is made,
VDR detaches its own receivers from the device and does another
GetDevice() call. This time the original live device may be chosen.
I don't think that this really is a problem, because a device will
always be found, even if temporarily a different one will be preferred.
What I really see as a problem here now is that the first call to
GetDevice() may call a device's DetachAllReceivers() and the second
GetDevice() call may then decide to actually use a different device.
I'm currently considering giving GetDevice() another parameter:

   static cDevice *GetDevice(const cChannel *Channel, int Priority, bool LiveView, bool Query = false);

and make it not do any CAM assignments or receiver detachments if
Query is true, but only check whether there is any device available.

Klaus
  

On 01.03.2012 09:38, Frank Schmirler wrote:
> 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?

Wouldn't that get us back to square one? ;-)

> The default priority of cReceiver should become IDLEPRIORITY instead of
> MINPRIORITY then.

I don't like that. I want an idle device to have a lower priority
than one that has any kind of receiver attached to it.

Klaus
  

On 29.2.2012 10:20, Klaus Schmidinger wrote:
> Yes, the next stable version will be 2.0.

It would be great if next stable could include ttxtsubs-plugin 
readiness, i.e. recording/viewing teletext subtitles would not require 
patching of main VDR code anymore.
  

On 2.3.2012 12:17, Pertti Kosunen wrote:
> It would be great if next stable could include ttxtsubs-plugin
> readiness, i.e. recording/viewing teletext subtitles would not require
> patching of main VDR code anymore.

It would be also great if next stable could include mainmenuhooks-patch 
so extrecmenu- and epgsearch-plugins would not require patching VDR code 
anymore.
  

On 2.3.2012 12:35, Jarkko Kangas wrote:
> It would be also great if next stable could include mainmenuhooks-patch
> so extrecmenu- and epgsearch-plugins would not require patching VDR code
> anymore.

Epgsearch doesn't need patching.
  

On Fri, 02 Mar 2012 11:06:03 +0100, Klaus Schmidinger wrote
> I'm currently considering giving GetDevice() another parameter:
> 
>    static cDevice *GetDevice(const cChannel *Channel, int Priority,
>  bool LiveView, bool Query = false);
> 
> and make it not do any CAM assignments or receiver detachments if
> Query is true, but only check whether there is any device available.

Yes, please. This is on top of my "additional wishes" list and would finally
save me the copy of cDevice::GetDevice() I have in streamdev which became
necessary since GetDevice() got these "side effects" in VDR 1.5.0.

Regards,
Frank
  

On 2.3.2012 13:06, Pertti Kosunen wrote:
>
> Epgsearch doesn't need patching.
I think it does, if you want replace VDR's standard
schedule menu with epgsearch?
  

On Fri, 02 Mar 2012 11:08:42 +0100, Klaus Schmidinger wrote
> On 01.03.2012 09:38, Frank Schmirler wrote:
> > 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?
> 
> Wouldn't that get us back to square one? ;-)

Well, no. Previously live TV and related receivers were treated the same way
(same priority, both handled as if they were not present). Currently we have
different priorities (-1 and -99) and both are not ignored. So the -99
receiver is not in the way when switching live TV, but it will have an impact
on device selection. Ignoring receivers with IDLEPRIORITY (or likewise
MINPRIORITY) would solve this.

Regards,
Frank
  

On 02.03.2012 12:54, Frank Schmirler wrote:
> On Fri, 02 Mar 2012 11:08:42 +0100, Klaus Schmidinger wrote
>> On 01.03.2012 09:38, Frank Schmirler wrote:
>>> 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?
>>
>> Wouldn't that get us back to square one? ;-)
>
> Well, no. Previously live TV and related receivers were treated the same way
> (same priority, both handled as if they were not present). Currently we have
> different priorities (-1 and -99) and both are not ignored. So the -99
> receiver is not in the way when switching live TV, but it will have an impact
> on device selection. Ignoring receivers with IDLEPRIORITY (or likewise
> MINPRIORITY) would solve this.

But where would that be different from the previous version, where
all receivers with negative priorities have been ignored?
Now I'm confused...

Klaus
  

Am 02.03.2012 11:35, schrieb Jarkko Kangas:
> On 2.3.2012 12:17, Pertti Kosunen wrote:
>> It would be great if next stable could include ttxtsubs-plugin
>> readiness, i.e. recording/viewing teletext subtitles would not require
>> patching of main VDR code anymore.
> 
> It would be also great if next stable could include mainmenuhooks-patch
> so extrecmenu- and epgsearch-plugins would not require patching VDR code
> anymore.

It would be also great if next stable would include the other 13 patches
that I regularly use, but I doubt it. Throwing every wish into it would
probably delay it forever, esp. for patches like mainmenuhooks that is
planned to be superseded by more general planned changes at some point.

Cheers,

Udo
  

Am 02.03.2012 11:06, schrieb Klaus Schmidinger:
> On 29.02.2012 21:33, Udo Richter wrote:
>> Roughly, the callback should be at the places where these two get called:
>>
>>      DELETENULL(liveSubtitle);
>>      DELETENULL(dvbSubtitleConverter);
>>
>> (Thats how VDR's own receivers get out of way.)
> 
> There are two places in GetDevice() where
> cStatus::MsgChannelSwitch(this, 0)
> is called, but they are both *after* the final call to GetDevice().
> And there is this comment
> 
>   // only report status if we are actually going to switch the channel
> 
> which refers to a change that was made in version 1.1.10:
> 
> - Only calling cStatus::MsgChannelSwitch() if a channel is actually
> going to
>   be switched or has actually been switched successfully (thanks to Stefan
>   Huelswitt).


Good point. What if VDR wants to switch, but fails. Is it possible that
the channel change still fails after deleting liveSubtitle and
dvbSubtitleConverter? How does VDR itself handle this? Need to
investigate this.

If a call to MsgChannelSwitch(this, 0) was done on channel change, we
have to make sure that the corresponding call for the new channel does
happen, or - worst case - there's a call for the old channel again.


> What I really see as a problem here now is that the first call to
> GetDevice() may call a device's DetachAllReceivers() and the second
> GetDevice() call may then decide to actually use a different device.
> I'm currently considering giving GetDevice() another parameter:
> 
>   static cDevice *GetDevice(const cChannel *Channel, int Priority, bool
> LiveView, bool Query = false);

+1, as I know that something like this was on some wish lists for some
time. ;)


Cheers,

Udo
  

On Fri, 02 Mar 2012 13:01:23 +0100, Klaus Schmidinger wrote
> On 02.03.2012 12:54, Frank Schmirler wrote:
> > On Fri, 02 Mar 2012 11:08:42 +0100, Klaus Schmidinger wrote
> >> On 01.03.2012 09:38, Frank Schmirler wrote:
> >>> 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?
> >>
> >> Wouldn't that get us back to square one? ;-)
> >
> > Well, no. Previously live TV and related receivers were treated the same way
> > (same priority, both handled as if they were not present). Currently we have
> > different priorities (-1 and -99) and both are not ignored. So the -99
> > receiver is not in the way when switching live TV, but it will have an impact
> > on device selection. Ignoring receivers with IDLEPRIORITY (or likewise
> > MINPRIORITY) would solve this.
> 
> But where would that be different from the previous version, where
> all receivers with negative priorities have been ignored?
> Now I'm confused...

Currently there's no such thing like a "live TV related receiver" (like for
the osdteletext-plugin). A "live related receiver" will always follow the
current live channel. So it shouldn't be in the way when switching channels
and will probably never show up alone but always in company with the live TV
transfer mode receiver.

VDR up to 1.7.24 had transfer mode receiver at priority -1, live related
receivers at -1. All negative priorities treated the same way, i.e. either
totally ignored or not ignored at all. No black screen in transfer mode when a
recording starts as the transfer mode receiver at -1 is not ignored
(Receiving(true) in ProvidesChannel()). But for the same reason a live related
receiver at -1 (or any other negative priority) isn't detached when the live
channel is being switched. The same problem would also apply to low priority
"remote transfer mode" receivers.

The current state of the patch has transfer mode receiver at priority -1, live
related receivers by default at -99. No receivers are ignored. Black screen in
transfer mode when a recordings starts? Don't know if it's back but I assume
the impact in GetDevice takes care of it. The live related receiver is still
attached when switching live TV, but it no longer blocks the channel switch
due to its lower priority. So low priority "remote transfer mode" should be
fine, too. However the live related receiver isn't totally ignored.
Receiving() will detect it an so it e.g. has an impact on device selection
which is even higher than NumProvidedSystems().

Now lets assume, Receiving() would ignore a receiver at either IDLEPRIORITY or
MINPRIORITY. Black screen? Still don't know ;). Live related receiver? Still
attached when switching live TV and still not in the way due to low priority.
Same for "remote transfer mode". But now Receiving() no longer reports it, so
no impact on device selection. The boolean parameter of Receiving() must still
be ignored of course.

Moving cStatus::MsgChannelSwitch(this, 0) and plugins with "live related
receivers" reacting to it by detaching the receiver should achive the same.

Cheers,
Frank
  

On 02.03.2012 18:13, Udo Richter wrote:
> Am 02.03.2012 11:06, schrieb Klaus Schmidinger:
>> On 29.02.2012 21:33, Udo Richter wrote:
>>> Roughly, the callback should be at the places where these two get called:
>>>
>>>       DELETENULL(liveSubtitle);
>>>       DELETENULL(dvbSubtitleConverter);
>>>
>>> (Thats how VDR's own receivers get out of way.)
>>
>> There are two places in GetDevice() where
>> cStatus::MsgChannelSwitch(this, 0)
>> is called, but they are both *after* the final call to GetDevice().
>> And there is this comment
>>
>>    // only report status if we are actually going to switch the channel
>>
>> which refers to a change that was made in version 1.1.10:
>>
>> - Only calling cStatus::MsgChannelSwitch() if a channel is actually
>> going to
>>    be switched or has actually been switched successfully (thanks to Stefan
>>    Huelswitt).
>
>
> Good point. What if VDR wants to switch, but fails. Is it possible that
> the channel change still fails after deleting liveSubtitle and
> dvbSubtitleConverter? How does VDR itself handle this? Need to
> investigate this.

If switching to a certain channel fails, VDR will notice that the
primary device no longer HasProgramme() and will try to switch to
a different channel.

> If a call to MsgChannelSwitch(this, 0) was done on channel change, we
> have to make sure that the corresponding call for the new channel does
> happen, or - worst case - there's a call for the old channel again.
>
>
>> What I really see as a problem here now is that the first call to
>> GetDevice() may call a device's DetachAllReceivers() and the second
>> GetDevice() call may then decide to actually use a different device.
>> I'm currently considering giving GetDevice() another parameter:
>>
>>    static cDevice *GetDevice(const cChannel *Channel, int Priority, bool
>> LiveView, bool Query = false);
>
> +1, as I know that something like this was on some wish lists for some
> time. ;)

I'll release version 1.7.25 later today, so that all these changes can
be reviewed and tested.

Klaus
  

On 3/3/2012 4:48 AM, Klaus Schmidinger wrote:
> On 02.03.2012 18:13, Udo Richter wrote:
>> Am 02.03.2012 11:06, schrieb Klaus Schmidinger:
>>> On 29.02.2012 21:33, Udo Richter wrote:
>>>> Roughly, the callback should be at the places where these two get
>>>> called:
>>>>
>>>> DELETENULL(liveSubtitle);
>>>> DELETENULL(dvbSubtitleConverter);
>>>>
>>>> (Thats how VDR's own receivers get out of way.)
>>>
>>> There are two places in GetDevice() where
>>> cStatus::MsgChannelSwitch(this, 0)
>>> is called, but they are both *after* the final call to GetDevice().
>>> And there is this comment
>>>
>>> // only report status if we are actually going to switch the channel
>>>
>>> which refers to a change that was made in version 1.1.10:
>>>
>>> - Only calling cStatus::MsgChannelSwitch() if a channel is actually
>>> going to
>>> be switched or has actually been switched successfully (thanks to Stefan
>>> Huelswitt).
>>
>>
>> Good point. What if VDR wants to switch, but fails. Is it possible that
>> the channel change still fails after deleting liveSubtitle and
>> dvbSubtitleConverter? How does VDR itself handle this? Need to
>> investigate this.
>
> If switching to a certain channel fails, VDR will notice that the
> primary device no longer HasProgramme() and will try to switch to
> a different channel.
>
>> If a call to MsgChannelSwitch(this, 0) was done on channel change, we
>> have to make sure that the corresponding call for the new channel does
>> happen, or - worst case - there's a call for the old channel again.
>>
>>
>>> What I really see as a problem here now is that the first call to
>>> GetDevice() may call a device's DetachAllReceivers() and the second
>>> GetDevice() call may then decide to actually use a different device.
>>> I'm currently considering giving GetDevice() another parameter:
>>>
>>> static cDevice *GetDevice(const cChannel *Channel, int Priority, bool
>>> LiveView, bool Query = false);
>>
>> +1, as I know that something like this was on some wish lists for some
>> time. ;)
>
> I'll release version 1.7.25 later today, so that all these changes can
> be reviewed and tested.
>
> Klaus
>

A problem I have run into before is not that a channel is down, though 
that also happens, but that a tuner is down. I've had tuner crashes, but 
vdr just stayed with that tuner/chanel and recorded nothing. I currently 
have 5 ATA tuners. 2 Dual tuner cards and a single.
  

"Timothy D. Lenz" <tlenz@vorgon.com> writes:

[...]
> A problem I have run into before is not that a channel is down, though
> that also happens, but that a tuner is down. I've had tuner crashes,
> but vdr just stayed with that tuner/chanel and recorded nothing. I
> currently have 5 ATA tuners. 2 Dual tuner cards and a single.


You might want to have a look at the wonderful dynamite patch and
plugin:
http://projects.vdr-developer.org/projects/plg-dynamite

--
  

On 04.03.2012 19:04, Timothy D. Lenz wrote:
> ...
> A problem I have run into before is not that a channel is down, though that also happens, but that a tuner is down. I've had tuner crashes, but vdr just stayed with that tuner/chanel and recorded nothing. I currently have 5 ATA tuners. 2 Dual tuner cards and a single.

Didn't VDR report a "video data stream broken" and perform a restart?

Klaus
  

On Sunday 04 March 2012 - 22:51:36, Klaus Schmidinger wrote:
> On 04.03.2012 19:04, Timothy D. Lenz wrote:
> > ...
> > A problem I have run into before is not that a channel is down, though
> > that also happens, but that a tuner is down. I've had tuner crashes, but
> > vdr just stayed with that tuner/chanel and recorded nothing. I currently
> > have 5 ATA tuners. 2 Dual tuner cards and a single.
> 
> Didn't VDR report a "video data stream broken" and perform a restart?

That problem coincides with my problem of recordings with length 0 and filesize 
of few megabytes. Didn't know that it comes from a crashed tuner.

If I remember right, there was no "video data stream broken" message and after 
enabling the automatic shutdown I realized, that the vdr waits until no 
recording is active before initiating the restart.

So the automatic restart did not really help anything, especially in 
environments, where multiple parallel recordings are most probably to happen.

kind regards

Gero
  

On 05.03.2012 04:47, Gero wrote:
> On Sunday 04 March 2012 - 22:51:36, Klaus Schmidinger wrote:
>> On 04.03.2012 19:04, Timothy D. Lenz wrote:
>>> ...
>>> A problem I have run into before is not that a channel is down, though
>>> that also happens, but that a tuner is down. I've had tuner crashes, but
>>> vdr just stayed with that tuner/chanel and recorded nothing. I currently
>>> have 5 ATA tuners. 2 Dual tuner cards and a single.
>>
>> Didn't VDR report a "video data stream broken" and perform a restart?
>
> That problem coincides with my problem of recordings with length 0 and filesize
> of few megabytes. Didn't know that it comes from a crashed tuner.
>
> If I remember right, there was no "video data stream broken" message and after
> enabling the automatic shutdown I realized, that the vdr waits until no
> recording is active before initiating the restart.
>
> So the automatic restart did not really help anything, especially in
> environments, where multiple parallel recordings are most probably to happen.

It doesn't matter whether there is only one or multiple recordings.
Whenever a "video data stream broken" occurs, VDR performs an immediate
"emergency exit" (unless you turned that off, but then you're on
your own). So if a tuner doesn't deliver any more data, VDR restarts
and reloads the driver (provided you use a properly set up "runvdr"
script).

Klaus
  

On Monday 05 March 2012 - 09:02:56, Klaus Schmidinger wrote:
> On 05.03.2012 04:47, Gero wrote:
> > On Sunday 04 March 2012 - 22:51:36, Klaus Schmidinger wrote:
> >> On 04.03.2012 19:04, Timothy D. Lenz wrote:
> >>> ...
> >>> A problem I have run into before is not that a channel is down, though
> >>> that also happens, but that a tuner is down. I've had tuner crashes,
> >>> but vdr just stayed with that tuner/chanel and recorded nothing. I
> >>> currently have 5 ATA tuners. 2 Dual tuner cards and a single.
> >> 
> >> Didn't VDR report a "video data stream broken" and perform a restart?
> > 
> > That problem coincides with my problem of recordings with length 0 and
> > filesize of few megabytes. Didn't know that it comes from a crashed
> > tuner.
> > 
> > If I remember right, there was no "video data stream broken" message and
> > after enabling the automatic shutdown I realized, that the vdr waits
> > until no recording is active before initiating the restart.
> > 
> > So the automatic restart did not really help anything, especially in
> > environments, where multiple parallel recordings are most probably to
> > happen.
> 
> It doesn't matter whether there is only one or multiple recordings.
> Whenever a "video data stream broken" occurs, VDR performs an immediate
> "emergency exit" (unless you turned that off, but then you're on
> your own).

That might be true.

When I first reported recordings with length 0, the emergency exit was 
disabled. That time I had log-entries with "video data stream broken". 
According your advice, I enabled it, but since then I had no more log-entries 
with "video data stream broken", but had recordings with length 0

So there might be other reasons that stop vdr from recording without any 
notice / log entry

> So if a tuner doesn't deliver any more data, VDR restarts
> and reloads the driver (provided you use a properly set up "runvdr"
> script).

Hm, I gues my runvdr might be ok, since my backend does timer-controlled 
wakeup and shuts down in idle state.


kind regards

Gero
  

No, but I have the auto shutdown thing turned off because when signal is 
bad on 1 channel, it would disrupt everything with frequent restarts and 
as I recall, it often didn't restart. Might have been xine or something 
that stopped with the restart, I don't recall. Plus, restarting VDR in 
this case wouldn't fix the problem because it's a hardware crash that 
requires the drivers be restarted. One card finally died and had to be 
replaced which helped, but I know I have to leave power save off on 
those cards because the tuners get flaky when it's used and seems to be 
what killed the card. Poor craftsmanship.

On 3/4/2012 2:51 PM, Klaus Schmidinger wrote:
> On 04.03.2012 19:04, Timothy D. Lenz wrote:
>> ...
>> A problem I have run into before is not that a channel is down, though
>> that also happens, but that a tuner is down. I've had tuner crashes,
>> but vdr just stayed with that tuner/chanel and recorded nothing. I
>> currently have 5 ATA tuners. 2 Dual tuner cards and a single.
>
> Didn't VDR report a "video data stream broken" and perform a restart?
>
> Klaus
>
> _______________________________________________
> vdr mailing list
> vdr@linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
>
  

On 3/5/2012 2:52 AM, Gero wrote:
> On Monday 05 March 2012 - 09:02:56, Klaus Schmidinger wrote:
>> On 05.03.2012 04:47, Gero wrote:
>>> On Sunday 04 March 2012 - 22:51:36, Klaus Schmidinger wrote:
>>>> On 04.03.2012 19:04, Timothy D. Lenz wrote:
>>>>> ...
>>>>> A problem I have run into before is not that a channel is down, though
>>>>> that also happens, but that a tuner is down. I've had tuner crashes,
>>>>> but vdr just stayed with that tuner/chanel and recorded nothing. I
>>>>> currently have 5 ATA tuners. 2 Dual tuner cards and a single.
>>>>
>>>> Didn't VDR report a "video data stream broken" and perform a restart?
>>>
>>> That problem coincides with my problem of recordings with length 0 and
>>> filesize of few megabytes. Didn't know that it comes from a crashed
>>> tuner.
>>>
>>> If I remember right, there was no "video data stream broken" message and
>>> after enabling the automatic shutdown I realized, that the vdr waits
>>> until no recording is active before initiating the restart.
>>>
>>> So the automatic restart did not really help anything, especially in
>>> environments, where multiple parallel recordings are most probably to
>>> happen.
>>
>> It doesn't matter whether there is only one or multiple recordings.
>> Whenever a "video data stream broken" occurs, VDR performs an immediate
>> "emergency exit" (unless you turned that off, but then you're on
>> your own).
>
> That might be true.
>
> When I first reported recordings with length 0, the emergency exit was
> disabled. That time I had log-entries with "video data stream broken".
> According your advice, I enabled it, but since then I had no more log-entries
> with "video data stream broken", but had recordings with length 0
>
> So there might be other reasons that stop vdr from recording without any
> notice / log entry
>
>> So if a tuner doesn't deliver any more data, VDR restarts
>> and reloads the driver (provided you use a properly set up "runvdr"
>> script).
>
> Hm, I gues my runvdr might be ok, since my backend does timer-controlled
> wakeup and shuts down in idle state.
>
>
> kind regards
>
> Gero
>
>


Restarting when you have more then one recording screws up the working 
ones. The local broadcasters are morons about digital broadcast. Even 
with a good strong signal you can have broken up video which would 
trigger the restart making things even worse.
  

On 05.03.2012 19:50, Timothy D. Lenz wrote:
> No, but I have the auto shutdown thing turned off because when signal is bad on 1 channel, it would disrupt everything with frequent restarts and as I recall, it often didn't restart. Might have been xine or something that stopped with the restart, I don't recall. Plus, restarting VDR in this case
> wouldn't fix the problem because it's a hardware crash that requires the drivers be restarted.

That's what a properly configured runvdr script does if you fill in its
LoadDriver() and UnloadDriver() functions.

Klaus

> One card finally died and had to be replaced which helped, but I know I have to leave power save off on those cards because the tuners get flaky when it's used and seems to be what killed the card. Poor
> craftsmanship.
>
> On 3/4/2012 2:51 PM, Klaus Schmidinger wrote:
>> On 04.03.2012 19:04, Timothy D. Lenz wrote:
>>> ...
>>> A problem I have run into before is not that a channel is down, though
>>> that also happens, but that a tuner is down. I've had tuner crashes,
>>> but vdr just stayed with that tuner/chanel and recorded nothing. I
>>> currently have 5 ATA tuners. 2 Dual tuner cards and a single.
>>
>> Didn't VDR report a "video data stream broken" and perform a restart?
>>
>> Klaus
  

On 05.03.2012 19:54, Timothy D. Lenz wrote:
>
>
> On 3/5/2012 2:52 AM, Gero wrote:
>> On Monday 05 March 2012 - 09:02:56, Klaus Schmidinger wrote:
>>> On 05.03.2012 04:47, Gero wrote:
>>>> On Sunday 04 March 2012 - 22:51:36, Klaus Schmidinger wrote:
>>>>> On 04.03.2012 19:04, Timothy D. Lenz wrote:
>>>>>> ...
>>>>>> A problem I have run into before is not that a channel is down, though
>>>>>> that also happens, but that a tuner is down. I've had tuner crashes,
>>>>>> but vdr just stayed with that tuner/chanel and recorded nothing. I
>>>>>> currently have 5 ATA tuners. 2 Dual tuner cards and a single.
>>>>>
>>>>> Didn't VDR report a "video data stream broken" and perform a restart?
>>>>
>>>> That problem coincides with my problem of recordings with length 0 and
>>>> filesize of few megabytes. Didn't know that it comes from a crashed
>>>> tuner.
>>>>
>>>> If I remember right, there was no "video data stream broken" message and
>>>> after enabling the automatic shutdown I realized, that the vdr waits
>>>> until no recording is active before initiating the restart.
>>>>
>>>> So the automatic restart did not really help anything, especially in
>>>> environments, where multiple parallel recordings are most probably to
>>>> happen.
>>>
>>> It doesn't matter whether there is only one or multiple recordings.
>>> Whenever a "video data stream broken" occurs, VDR performs an immediate
>>> "emergency exit" (unless you turned that off, but then you're on
>>> your own).
>>
>> That might be true.
>>
>> When I first reported recordings with length 0, the emergency exit was
>> disabled. That time I had log-entries with "video data stream broken".
>> According your advice, I enabled it, but since then I had no more log-entries
>> with "video data stream broken", but had recordings with length 0
>>
>> So there might be other reasons that stop vdr from recording without any
>> notice / log entry
>>
>>> So if a tuner doesn't deliver any more data, VDR restarts
>>> and reloads the driver (provided you use a properly set up "runvdr"
>>> script).
>>
>> Hm, I gues my runvdr might be ok, since my backend does timer-controlled
>> wakeup and shuts down in idle state.
>>
>>
>> kind regards
>>
>> Gero
>>
>>
>
>
> Restarting when you have more then one recording screws up the working ones. The local broadcasters are morons about digital broadcast. Even with a good strong signal you can have broken up video which would trigger the restart making things even worse.

Well, then I guess you need to make your hardware/drivers work properly, so
that you can turn off the emergency exit. VDR can only work with what it gets.

Klaus