Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-05 Thread Klaus Schmidinger

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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-05 Thread Gero
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



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-05 Thread Timothy D. Lenz
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



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-05 Thread Timothy D. Lenz



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.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-05 Thread Klaus Schmidinger

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


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-05 Thread Klaus Schmidinger

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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-04 Thread Timothy D. Lenz



On 3/2/2012 11:06 AM, VDR User wrote:

On Fri, Mar 2, 2012 at 4:13 AM, Tony Houghtonh...@realh.co.uk  wrote:

Signal the server to start recording. But then the client has to be able
to match up its buffer with what the server has recorded after the
buffer filled and let the server know when the temp recording is no
longer needed. Complicated.


Maybe something like this would work...

User can define how much of his ram he wants used for buffering. VDR
uses x% of this for constant buffering. The remainder is only used
when pause/rewind has been pressed. When the remainder is filled, the
entire buffer is dumped to disk as a temp recording, which continued
to be recorded until a) live view has been resumed for X secs, or b)
until the show ends. The temp recording is then purged after a user
defined X minutes (or never if 0) of it's last modified timestamp.

If live buffering is to be added, it should have some flexibility, but
it still doesn't need to be overly complicated. Whatever the actual
live buffer behavior, I believe a ram-based solution is the best
choice for a number of reasons.


Have the server record everything it plays and not bother with buffering
in the client. I don't think most people want VDR to work that way
because of extra load on the hard drive.


HELL NO! I will not use software that forces my harddrive(s) into a
constant write state 24/7. I don't want the extra wear. I don't want
the extra heat. I don't want the extra power consumption. And I'm
certainly not alone.

I agree, this is what MythTV does and why I never tried to fully install 
it. I started to once to try it out, but I just didn't like the need for 
continous recording.  Would be ok with sold state drives that don't ware 
out with use like the current ones do. But even they are too costly for 
me to even look at.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-04 Thread Timothy D. Lenz



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.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-04 Thread syrius . ml
Timothy D. Lenz tl...@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

-- 

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-04 Thread Gero
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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-03 Thread Klaus Schmidinger

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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-02 Thread fnu
 about Pause and rewind live TV.

What is live TV there, as it is already recorded ... ?

Only users which didn't got into VDR and epgsearch timers do call for this
live buffer function. They hope for a kind of security, which this function
doesn't really provide.

You want to have a feeling how it feels, if a live buffer is the underlying
central function in a PVR solution, just go and test MythTV.

Cheers
fnu


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-02 Thread Klaus Schmidinger

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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-02 Thread Pertti Kosunen

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.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-02 Thread 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.


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-02 Thread Pertti Kosunen

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.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-02 Thread Frank Schmirler
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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-02 Thread Jarkko Kangas

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?

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-02 Thread Frank Schmirler
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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-02 Thread Klaus Schmidinger

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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-02 Thread Tony Houghton
On Fri, 02 Mar 2012 08:29:00 +0100
Gerald Dachs v...@dachsweb.de wrote:

 Am 2012-03-02 00:18, schrieb Tony Houghton:
  Going off on a tangent, there's been some discussion about Pause
  and rewind live TV. That could be implemented fairly easily in
  clients with
  a big RAM buffer, without adding any complexity to the server.
 
 Big RAM buffer means long breaks between channel changes.

Not necessarily, because you don't have to wait for the buffer to fill
before playing the content. I meant to play the stream as soon as
possible, but also keep the data in a buffer for a short time so the
viewer can rewind. It wouldn't need to be for long, not even more than a
minute, because what I had in mind is when you miss what someone said
and rewind to hear it again.

However, if the user pauses instead the buffer should be able to grow as
necessary. That gets complicated if the pause ends up being longer than
the available RAM. Possible strategies are:

Drop the buffer (LIFO or FIFO?) and miss some of the programme. Not
good.

Allow the client to write the buffer to disc. Partly duplicates server
functionality but I think it's probably the best plan.

Signal the server to start recording. But then the client has to be able
to match up its buffer with what the server has recorded after the
buffer filled and let the server know when the temp recording is no
longer needed. Complicated.

Have the server record everything it plays and not bother with buffering
in the client. I don't think most people want VDR to work that way
because of extra load on the hard drive.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-02 Thread Tony Houghton
On Fri, 2 Mar 2012 10:30:37 +0100
fnu v...@auktion.hostingkunde.de wrote:

  about Pause and rewind live TV.
 
 What is live TV there, as it is already recorded ... ?
 
 Only users which didn't got into VDR and epgsearch timers do call for
 this live buffer function. They hope for a kind of security, which
 this function doesn't really provide.

I disagree, my sister's got a Humax which can pause and rewind, it's
really useful. She's even willing to have inferior picture quality
(older MPEG decoder, analogue SCART etc vs modern TV's inbuilt decoder)
just to be able to pause and rewind.

VDR can already pause, but what if there's a sudden distraction and you
miss something before you can press the pause button? Then rewind is
very nice.

 You want to have a feeling how it feels, if a live buffer is the
 underlying central function in a PVR solution, just go and test
 MythTV.

Do you mean because of slow channel switching? A buffer doesn't have to
cause that, see my other post.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-02 Thread Udo Richter
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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-02 Thread Udo Richter
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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-02 Thread Frank Schmirler
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


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-02 Thread Udo Richter
Am 02.03.2012 10:30, schrieb fnu:
 You want to have a feeling how it feels, if a live buffer is the underlying
 central function in a PVR solution, just go and test MythTV.

I think the main objection against buffering was that for old FF cards,
this also forces transfer mode, resulting in additional lag and
bandwidth issues. Since HDFF cards AFAIK can split their stream on card
for live view and recording, this isn't valid any more.

Live viewing could be just like its currently, with an additional (RAM?)
recording running in the background, and VDR could jump to that
recording on rewind/pause key hit.


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-02 Thread VDR User
On Fri, Mar 2, 2012 at 4:13 AM, Tony Houghton h...@realh.co.uk wrote:
 Signal the server to start recording. But then the client has to be able
 to match up its buffer with what the server has recorded after the
 buffer filled and let the server know when the temp recording is no
 longer needed. Complicated.

Maybe something like this would work...

User can define how much of his ram he wants used for buffering. VDR
uses x% of this for constant buffering. The remainder is only used
when pause/rewind has been pressed. When the remainder is filled, the
entire buffer is dumped to disk as a temp recording, which continued
to be recorded until a) live view has been resumed for X secs, or b)
until the show ends. The temp recording is then purged after a user
defined X minutes (or never if 0) of it's last modified timestamp.

If live buffering is to be added, it should have some flexibility, but
it still doesn't need to be overly complicated. Whatever the actual
live buffer behavior, I believe a ram-based solution is the best
choice for a number of reasons.

 Have the server record everything it plays and not bother with buffering
 in the client. I don't think most people want VDR to work that way
 because of extra load on the hard drive.

HELL NO! I will not use software that forces my harddrive(s) into a
constant write state 24/7. I don't want the extra wear. I don't want
the extra heat. I don't want the extra power consumption. And I'm
certainly not alone.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-01 Thread Frank Schmirler
On Wed, 29 Feb 2012 21:33:31 +0100, Udo Richter wrote
 Am 29.02.2012 16:17, schrieb Klaus Schmidinger:
+ The function cDevice::Receiving() now returns true if there is any
  receiver
  attached to the device. Its boolean parameter has no meaning any more.
 
 Please remember to drop the following line from PLUGINS.html, as it 
 is now finally completely void:
 
  (any negative value will allow a cReceiver to be detached from its cDevice
at any time.)
 
 This was handled via Receiving(true).
 
 This still leaves the live related receivers unhandled, and since
 there's no way to port the 'volatile' patch without reverting your
 changes, we still have the old osdteletext-channel-blocking bug.

Wouldn't it help to run those live related receivers with priority
IDLEPRIORITY and having cDevice::Receiving() ignore receivers with priority
IDLEPRIORITY?

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

Regards,
Frank

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-01 Thread Udo Richter
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 streamOSD display. Or keep
latency low and put a more complex frontend on the client, that acts
independently of the server backend.

A high-level frontend could connect to one or more receiver backends to
get channels on demand, would be able to schedule timers on recording
backend(s), and would be able to play back from storage sources. Why not
allow a storage plugin to act as a media player instead of just VDR
recording server? Or on-the-fly transcoding on recording?

 Additionally it should be possible to configure the preferred input device 
 used 
 by this client for life-view. Other devices may be configured as fallback, in 
 case the preferred device is not available.

Thought of that. Generally, the default link between video frontend and
receiver backend should be handled like transfer mode, to make things
more unique. For the case of FF cards, there could be an additional
prefer-this-backend-for-this-frontend rule, and a shortcut in transfer
control that routes the video stream within the card instead of user space.


 As I already wrote, from my point of view, plugins may continue do 
 networking, 
 but the connection between backend- and frontend-part of vdr should not be 
 public nor affected by any plugin. 

Well, I have a different vision: More like recording server and
streaming client, where all the UI logic resides in the client, and the
server doesn't need to know about UI at all. One advantage: Allow a
frontend to connect to more than one backend. For example, have two
'full' VDR systems with receivers, recording capabilities and storage,
and some streaming clients. And then let each of them use any receiver,
any recording capability, and any recording storage that is available.

As said, the server itself could spawn several clients, so sxfe-like
lightweight viewers can connect to it. There could also be shortcuts if
backends are on the same machine or in the same executable, so not
everything must go over network.



However, thats all pretty much vision and far from being reality.



Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-01 Thread Udo Richter
Am 01.03.2012 07:03, schrieb VDR User:
 one option to spread
 the workload could be Klaus assigning different portions to different
 contributors that would like to work on it. If Klaus is clear about
 what he wants and is in good communication with other coders, perhaps
 it could become more of a team effort with Klaus as team captain..

The number of Klaus per VDR has always been quite limited. A developer
team would surely speed things up, but I also understand that Klaus
prefers to keep all development in his own hands instead of delegating
and supervising. Letting 'his baby' off the hook isn't easy, and I would
understand if he prefers to keep it under control.


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-01 Thread VDR User
On Thu, Mar 1, 2012 at 12:12 PM, Udo Richter udo_rich...@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.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-01 Thread Klaus Schmidinger

On 01.03.2012 22:17, VDR User wrote:

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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-01 Thread Udo Richter
Am 01.03.2012 22:25, schrieb Klaus Schmidinger:
 Guys, *please*! I stated earlier that I am currently concentrating
 on making a stable version 2.0, and that I will see to make client/server
 a priority *after* that.

Agreed, lets focus on 2.0 for now. We just got carried away dreaming of
VDR 3.0 already. ;)


Its never too early to dream tho'...


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-01 Thread Tony Houghton
On Thu, 01 Mar 2012 22:12:19 +0100
Manuel Reimer manuel.rei...@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.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-03-01 Thread Gerald Dachs

Am 2012-03-02 00:18, schrieb Tony Houghton:

Going off on a tangent, there's been some discussion about Pause and
rewind live TV. That could be implemented fairly easily in clients 
with

a big RAM buffer, without adding any complexity to the server.


Big RAM buffer means long breaks between channel changes.

Gerald


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-29 Thread Klaus Schmidinger

On 29.02.2012 08:17, Steffen Barszus wrote:

On Wed, 29 Feb 2012 05:38:06 +0100
Gerogeronimo...@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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-29 Thread Tobi
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




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-29 Thread Klaus Schmidinger

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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-29 Thread Manuel Reimer

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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-29 Thread Anssi Hannula
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.

-- 
Anssi Hannula

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-29 Thread Klaus Schmidinger

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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-29 Thread Frank Schmirler
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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-29 Thread Tony Houghton
On Wed, 29 Feb 2012 16:48:33 +0100
Manuel Reimer manuel.rei...@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.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-29 Thread VDR User
On Wed, Feb 29, 2012 at 12:20 AM, Klaus Schmidinger
klaus.schmidin...@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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-29 Thread Gero
On Wednesday 29 February 2012 - 17:50:27, Tony Houghton wrote:
 On Wed, 29 Feb 2012 16:48:33 +0100
 Manuel Reimer manuel.rei...@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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-29 Thread Udo Richter
Am 29.02.2012 17:50, schrieb Tony Houghton:
 On Wed, 29 Feb 2012 16:48:33 +0100
 Manuel Reimer manuel.rei...@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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-29 Thread Udo Richter
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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-29 Thread Gero
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

___
vdr mailing list
vdr@linuxtv.org

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-29 Thread VDR User
On Wed, Feb 29, 2012 at 11:45 AM, Udo Richter udo_rich...@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.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-28 Thread Frank Schmirler
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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-28 Thread Klaus Schmidinger

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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-28 Thread Gero
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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-28 Thread Dominic Evans

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




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-28 Thread Eric Valette

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





___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-28 Thread Gero
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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-28 Thread Eric Valette

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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-28 Thread syrius . ml
Eric Valette eric.vale...@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.

-- 

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-28 Thread Eric Valette

On 02/28/2012 03:49 PM, syrius...@no-log.org wrote:

Eric Valetteeric.vale...@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


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-28 Thread Gero
Hi,

On Tuesday 28 February 2012 - 15:49:32, syrius...@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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-28 Thread Frank Schmirler
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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-28 Thread VDR User
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?

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-28 Thread Anssi Hannula
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.


-- 
Anssi Hannula

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-28 Thread Gero
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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-28 Thread Mika Laitio
 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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-28 Thread Steffen Barszus
On Wed, 29 Feb 2012 05:38:06 +0100
Gero geronimo...@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 ...

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-28 Thread Dave
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.
-- 
Dave

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-27 Thread Frank Schmirler
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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-27 Thread Klaus Schmidinger

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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-27 Thread Udo Richter
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

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-25 Thread Klaus Schmidinger

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
===
RCS file: ./RCS/MANUAL
retrieving revision 2.15
diff -u -b -r2.15 ./MANUAL
--- ./MANUAL	2012/01/14 13:03:21	2.15
+++ ./MANUAL	2012/02/25 

Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-24 Thread Frank Schmirler
Hi,

On Sun, 19 Feb 2012 14:54:48 +0100, Klaus Schmidinger wrote
 - Fixed handling the  PrimaryLimit when requesting a device for live viewing
(reported by Uwe Scheffler).

Refers to the following change in device.c:
-  if (device[i]-ProvidesChannel(Channel, Priority, ndr)) { // this
device is basicly able to do the job
+  if (device[i]-ProvidesChannel(Channel, (LiveView 
device[i]-IsPrimaryDevice()) ? Setup.PrimaryLimit : Priority, ndr)) { //
this device is basicly able to do the job

With this modification the GetDevice parameter Priority becomes meaningless in
case LiveView is true. This should at least be mentioned in the function's
documentation in device.h.

Anyway, I think a better way to fix the problem would be to change the
priority parameter of the GetDevice calls involved from GetDevice(channel, 0,
true) to GetDevice(channel, Setup.PrimaryLimit, true). There are two calls
in device.c and one call in menu.c.

Imagine a two card system with PrimaryLimit 20, a high priority recording
(e.g. 50) running on the PrimaryDevice and a low priority recording (e.g. 10)
on the second card. With 1.7.24 live TV would not interrupt the low priority
recording, as PrimaryLimit priority is only used when checking the
PrimaryDevice, but priority 0 is used when checking the second card.

The way 1.7.24 resolves the problem is not wrong as according to MANUAL
PrimaryLimit is not meant to affect transfer mode. IMHO it should, as the
intention of this parameter is prefering LiveTV to low priority recordings.
I'm still hoping to get a more priority driven device selection. BTW: Any
update on this related issue:
http://www.mail-archive.com/vdr@linuxtv.org/msg14166.html?

Regards,
Frank


___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-24 Thread Klaus Schmidinger

On 24.02.2012 15:37, Frank Schmirler wrote:

Hi,

On Sun, 19 Feb 2012 14:54:48 +0100, Klaus Schmidinger wrote

- Fixed handling the  PrimaryLimit when requesting a device for live viewing
(reported by Uwe Scheffler).


Refers to the following change in device.c:
-  if (device[i]-ProvidesChannel(Channel, Priority,ndr)) { // this
device is basicly able to do the job
+  if (device[i]-ProvidesChannel(Channel, (LiveView
device[i]-IsPrimaryDevice()) ? Setup.PrimaryLimit : Priority,ndr)) { //
this device is basicly able to do the job

With this modification the GetDevice parameter Priority becomes meaningless in
case LiveView is true. This should at least be mentioned in the function's
documentation in device.h.

Anyway, I think a better way to fix the problem would be to change the
priority parameter of the GetDevice calls involved from GetDevice(channel, 0,
true) to GetDevice(channel, Setup.PrimaryLimit, true). There are two calls
in device.c and one call in menu.c.

Imagine a two card system with PrimaryLimit 20, a high priority recording
(e.g. 50) running on the PrimaryDevice and a low priority recording (e.g. 10)
on the second card. With 1.7.24 live TV would not interrupt the low priority
recording, as PrimaryLimit priority is only used when checking the
PrimaryDevice, but priority 0 is used when checking the second card.

The way 1.7.24 resolves the problem is not wrong as according to MANUAL
PrimaryLimit is not meant to affect transfer mode. IMHO it should, as the
intention of this parameter is prefering LiveTV to low priority recordings.
I'm still hoping to get a more priority driven device selection.


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 
;-)

So, is there anybody who would *really* miss the Primary Limit if it were 
gone?


BTW: Any update on this related issue:
http://www.mail-archive.com/vdr@linuxtv.org/msg14166.html?


I assume you are referring to

  
http://projects.vdr-developer.org/attachments/355/vdr-1.7.12-detachreceiver-4.diff

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 ;-)

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-24 Thread Udo Richter
Am 24.02.2012 17:23, schrieb Klaus Schmidinger:
 On 24.02.2012 15:37, Frank Schmirler wrote:
 On Sun, 19 Feb 2012 14:54:48 +0100, Klaus Schmidinger wrote
 - Fixed handling the  PrimaryLimit when requesting a device for live
 viewing
 (reported by Uwe Scheffler).

Hmmm, didn't even notice that change...

 Anyway, I think a better way to fix the problem would be to change the
 priority parameter of the GetDevice calls involved from
 GetDevice(channel, 0,
 true) to GetDevice(channel, Setup.PrimaryLimit, true). There are
 two calls
 in device.c and one call in menu.c.

My 'volatile' patch did this, and it worked so far. I like that a lot
more than the 1.7.24 solution that just adds another quirk to the
priority system. If in doubt, this should just raise the priority on
channel switching. I don't think that it would cause any negative side
effects, esp. since this priority is ignored at the end anyway. (see below)

 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 ;-)

Keep in mind that a recording on an un-modded SD-FF device nowadays can
cause broken recordings because of limited bandwidth. Being able to
record and play at the same time is a rather theoretical ability,
especially if its transfer mode playback.

However, I never had PrimaryLimit set to anything but 0.

 http://projects.vdr-developer.org/attachments/355/vdr-1.7.12-detachreceiver-4.diff

For description:
http://projects.vdr-developer.org/issues/show/10


 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 ;-)


That patch actually goes the same way as the above fix, but beside that
its more about the detaching issue, and just fixed the PrimaryLimit
issue on the way, so its not directly related. Even dropping
PrimaryLimit wouldn't solve this issue.

One of the core problems is that VDR selects a new device for live
viewing before disconnecting the old live device. Thus, all live related
receivers will still be present and will block the current device from
being re-used. VDR works around this just because live view has no
receivers (FF cards) or -1 priority receivers (transfer mode,
subtitles), that are always of lower priority than anything.

As a conequence, VDR has to ignore the '-1 can always be disconnected'
rule, or it would also disconnect transfer mode on timers, regardless of
free devices. And this leads to the osdteletext issue that the teletext
receiver still blocks the device on channel switch. VDR's own receivers
also work around this because they get disconnected before doing the
final and counting GetDevice call, but plugins cannot do that at that time.


A clean solution should imho do these things:
- Fix the find-device-before-disconnecting loop
- Transfer mode devices with 'real' priorities
- Honor the -1 priority as always-detachable

In the end, you need to know at a very early point (ChUp pressed etc.)
whether a device will be available for live view, even if it is still
used right now, and might be used on (if ChUp fails).

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...


Cheers,

Udo

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-24 Thread Frank Schmirler
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.

Regards,
Frank

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-20 Thread Klaus Schmidinger

On 20.02.2012 00:06, Joerg Riechardt wrote:

Am 19.02.2012 22:04, schrieb Klaus Schmidinger:

On 19.02.2012 20:45, Joerg Riechardt wrote:

Am 19.02.2012 19:51, schrieb Joerg Riechardt:

Hi,
when I replay a recording with 1.7.24 and switch several times from
replay to fast replay and back, it takes too long until VDR responds to
the remote. Happens with old recordings and recordings made with 1.7.24.
With 1.7.23 no problem.


This happens with the vdr-xine plugin only.
With softhddevice or xineliboutput it is ok.
Jörg


It also works fine with the TT S2-6400.

The only thing I could image to be causing this are the changes
in dvbplayer.c regarding Fixed a possible deadlock in time shift mode.
Can you please try with dvbplayer.[hc] from version 1.7.23?
This will also remove the fix for pausing live video, but that should be
independent from this problem.

Oh, and just to make sure: you haven't applied any other patches, have you?

Klaus


With dvbplayer.[hc] from version 1.7.23 and adjusted menu.[hc] it is ok again.
Other patches were not involved.
Jörg


Well, then I guess it's best if I revoke that change.
Any objections? Or maybe a fix for the vdr-xine problem?

(See also 
http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/p1054305-geloest-timeshift-problem-mit-1-7-x/#post1054305).

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-20 Thread Ville Skyttä
On 2012-02-20 11:18, Klaus Schmidinger wrote:
 On 20.02.2012 00:06, Joerg Riechardt wrote:

 With dvbplayer.[hc] from version 1.7.23 and adjusted menu.[hc] it is ok 
 again.
 Other patches were not involved.
 Jörg
 
 Well, then I guess it's best if I revoke that change.
 Any objections? Or maybe a fix for the vdr-xine problem?

It seems that the dxr3 plugin is similarly affected, and reverting to
the 1.7.23 versions gets rid of the problem for it as well.

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-20 Thread Udo Richter
Am 20.02.2012 10:18, schrieb Klaus Schmidinger:
 On 20.02.2012 00:06, Joerg Riechardt wrote:
 With dvbplayer.[hc] from version 1.7.23 and adjusted menu.[hc] it is
 ok again.
 Other patches were not involved.
 Jörg
 
 Well, then I guess it's best if I revoke that change.
 Any objections? Or maybe a fix for the vdr-xine problem?
 
 (See also
 http://www.vdr-portal.de/board16-video-disk-recorder/board8-vdr-grundlagen/p1054305-geloest-timeshift-problem-mit-1-7-x/#post1054305).

I'm also seeing (hearing) reproducible glitches on playback with a
TT-6400, on 1.7.24. I've reverted just the changes from the patch at
vdr-portal, and the glitches were gone. So +1 for reverting.

For ease of use the attached patch sums up the revert. Because of an
indenting issue the original patch doesn't revert cleanly.


Cheers,

Udo
--- vdr-1.7.24/dvbplayer.c.bak	2012-02-20 22:51:24.0 +0100
+++ vdr-1.7.24/dvbplayer.c	2012-02-20 22:55:26.0 +0100
@@ -87,7 +87,6 @@
 private:
   cUnbufferedFile *f;
   uchar *buffer;
-  uchar *result;
   int wanted;
   int length;
   cCondWait newSet;
@@ -101,7 +100,7 @@
   void Clear(void);
   void Request(cUnbufferedFile *File, int Length);
   int Result(uchar **Buffer);
-  bool Reading(void) { return result; }
+  bool Reading(void) { return buffer; }
   bool WaitForDataMs(int msToWait);
   };
 
@@ -110,7 +109,6 @@
 {
   f = NULL;
   buffer = NULL;
-  result = NULL;
   wanted = length = 0;
   Start();
 }
@@ -120,7 +118,6 @@
   newSet.Signal();
   Cancel(3);
   free(buffer);
-  free(result);
 }
 
 void cNonBlockingFileReader::Clear(void)
@@ -129,8 +126,6 @@
   f = NULL;
   free(buffer);
   buffer = NULL;
-  free(result);
-  result = NULL;
   wanted = length = 0;
   Unlock();
 }
@@ -142,18 +137,18 @@
   wanted = Length;
   buffer = MALLOC(uchar, wanted);
   f = File;
-  newSet.Signal();
   Unlock();
+  newSet.Signal();
 }
 
 int cNonBlockingFileReader::Result(uchar **Buffer)
 {
   LOCK_THREAD;
-  if (result  length == wanted) {
- *Buffer = result;
- result = NULL;
+  if (buffer  length == wanted) {
+ *Buffer = buffer;
+ buffer = NULL;
  return wanted;
-  }
+ }
   errno = EAGAIN;
   return -1;
 }
@@ -177,8 +172,6 @@
   length = wanted = r; // this will forward the error status to the caller
   }
if (length == wanted) {
-  result = buffer;
-  buffer = NULL;
   cMutexLock NewDataLock(newDataMutex);
   newDataCond.Broadcast();
   }
@@ -190,9 +183,9 @@
 
 bool cNonBlockingFileReader::WaitForDataMs(int msToWait)
 {
-  if (result  length == wanted)
- return true;
   cMutexLock NewDataLock(newDataMutex);
+  if (buffer  length == wanted)
+ return true;
   return newDataCond.TimedWait(newDataMutex, msToWait);
 }
 
@@ -415,13 +408,13 @@
  Goto(0, true);
   while (Running()) {
 if (WaitingForData)
-   nonBlockingFileReader-WaitForDataMs(10); // this keeps the CPU load low, but reacts immediately on new data
+   nonBlockingFileReader-WaitForDataMs(3); // this keeps the CPU load low, but reacts immediately on new data
 else if (Sleep) {
cPoller Poller;
DevicePoll(Poller, 10);
Sleep = false;
if (playMode == pmStill || playMode == pmPause)
-  cCondWait::SleepMs(10);
+  cCondWait::SleepMs(3);
}
 {
   LOCK_THREAD;
@@ -483,15 +476,7 @@
}
 if (!eof) {
uchar *b = NULL;
-   int Retries = 5;
-   int r;
-   while (true) {
- r = nonBlockingFileReader-Result(b);
- if (r == -1  errno == EAGAIN  --Retries)
-nonBlockingFileReader-WaitForDataMs(10); 
- else 
-break;
- }
+   int r = nonBlockingFileReader-Result(b);
if (r  0) {
   WaitingForData = false;
   uint32_t Pts = 0;
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-19 Thread Klaus Schmidinger

On 19.02.2012 14:54, Klaus Schmidinger wrote:

VDR developer version 1.7.24 is now available ...
...
- Fixed switching into time shift mode when pausing live video (thanks to 
Reinhard
  Nissl for helping to debug this one).


Just realized that on channels with 50fps the info file needs
to be re-read to get the actual fps rate after the index file
has been written:


--- dvbplayer.c 2012/02/19 10:48:02 2.23
+++ dvbplayer.c 2012/02/19 14:21:22
@@ -291,6 +291,8 @@
  delete index;
  index = NULL;
  }
+  else if (PauseLive)
+ framesPerSecond = cRecording(FileName).FramesPerSecond(); // the fps rate 
might have changed from the default
 }

 cDvbPlayer::~cDvbPlayer()



Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-19 Thread Joerg Riechardt

Hi,
when I replay a recording with 1.7.24 and switch several times from 
replay to fast replay and back, it takes too long until VDR responds to 
the remote. Happens with old recordings and recordings made with 1.7.24.

With 1.7.23 no problem.
Jörg

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-19 Thread Joerg Riechardt

Am 19.02.2012 19:51, schrieb Joerg Riechardt:

Hi,
when I replay a recording with 1.7.24 and switch several times from
replay to fast replay and back, it takes too long until VDR responds to
the remote. Happens with old recordings and recordings made with 1.7.24.
With 1.7.23 no problem.


This happens with the vdr-xine plugin only.
With softhddevice or xineliboutput it is ok.
Jörg








Jörg

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-19 Thread Klaus Schmidinger

On 19.02.2012 20:45, Joerg Riechardt wrote:

Am 19.02.2012 19:51, schrieb Joerg Riechardt:

Hi,
when I replay a recording with 1.7.24 and switch several times from
replay to fast replay and back, it takes too long until VDR responds to
the remote. Happens with old recordings and recordings made with 1.7.24.
With 1.7.23 no problem.


This happens with the vdr-xine plugin only.
With softhddevice or xineliboutput it is ok.
Jörg


It also works fine with the TT S2-6400.

The only thing I could image to be causing this are the changes
in dvbplayer.c regarding Fixed a possible deadlock in time shift mode.
Can you please try with dvbplayer.[hc] from version 1.7.23?
This will also remove the fix for pausing live video, but that should be
independent from this problem.

Oh, and just to make sure: you haven't applied any other patches, have you?

Klaus

___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr


Re: [vdr] [ANNOUNCE] VDR developer version 1.7.24

2012-02-19 Thread Joerg Riechardt

Am 19.02.2012 22:04, schrieb Klaus Schmidinger:

On 19.02.2012 20:45, Joerg Riechardt wrote:

Am 19.02.2012 19:51, schrieb Joerg Riechardt:

Hi,
when I replay a recording with 1.7.24 and switch several times from
replay to fast replay and back, it takes too long until VDR responds to
the remote. Happens with old recordings and recordings made with 1.7.24.
With 1.7.23 no problem.


This happens with the vdr-xine plugin only.
With softhddevice or xineliboutput it is ok.
Jörg


It also works fine with the TT S2-6400.

The only thing I could image to be causing this are the changes
in dvbplayer.c regarding Fixed a possible deadlock in time shift mode.
Can you please try with dvbplayer.[hc] from version 1.7.23?
This will also remove the fix for pausing live video, but that should be
independent from this problem.

Oh, and just to make sure: you haven't applied any other patches, have you?

Klaus


With dvbplayer.[hc] from version 1.7.23 and adjusted menu.[hc] it is ok 
again.

Other patches were not involved.
Jörg




___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr



___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr