Re: [vdr] Blocking the playback of recordings in plugins

[Reinhard Nissl]

Hi,

Marko Mäkelä wrote:

 I believe that the easy fix would be to have these methods return 0 only
 when playing a recording.  Can the plugin detect this somehow?

For live TV, VDR runs a transfer thread and the replaying device may use
cDevice::Transferring() to detect this (works at least for vdr-xine in
cXineDevice::SetPlayMode() for PlayMode being != pmNone).

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:[EMAIL PROTECTED]

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

Re: [vdr] Blocking the playback of recordings in plugins

[Marko Mäkelä]

On Thu, Feb 01, 2007 at 07:57:20PM +0100, Reinhard Nissl wrote:
 Hi,
 
 Marko Mäkelä wrote:
 
  I believe that the easy fix would be to have these methods return 0 only
  when playing a recording.  Can the plugin detect this somehow?
 
 For live TV, VDR runs a transfer thread and the replaying device may use
 cDevice::Transferring() to detect this (works at least for vdr-xine in
 cXineDevice::SetPlayMode() for PlayMode being != pmNone).

Thanks, I knew there had to be some way.  Softdevice used to blank
the screen after a few seconds of missing video stream (tuned to an
audio channel).  A fix was introduced so that it wouldn't blank the
screen when a recording was paused.

Marko

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

[vdr] Blocking the playback of recordings in plugins

[Marko Mäkelä]

On Wed, Jan 31, 2007 at 08:38:29PM +0100, Klaus Schmidinger wrote:
  From what he's saying, the problem is buffer overrun's, not underrun's. 
  Too much data is being sent and the device isn't able to keep up.  If
  that's the case then it would make sense for vdr to have a user setting
  to limit how many seconds (or milliseconds perhaps?) worth of data is
  sent to the buffer.  I can't think of any reason not to add such a
  feature if it means better usability for the end-user.
 
 If the device can't take any more data, it should just refuse to
 accept it and return from the write() call without anything written.

I gather that in plugin-based playback, cDevice::PlayAudio() and
cDevice::PlayVideo() are overridden and may return 0 to indicate
that nothing was written.

I modified PlayAudio and PlayVideo in softdevice.c so that they return 0
when softdevice is in suspended state.  That is, I replaced
  if (! packetMode)
with
  if (!packetMode  !setupStore.shouldSuspend)
in both methods, so that they would return 0.

This seemed to work for recordings, but I am not sure if it worked for video.
If I suspended the playback for only a short while, it looked like the
playback resumed from where it was stopped, and maybe some frames were
dropped every now and then to reduce the lag.  I'd prefer the live
playback to resume without any lag, that is, to drop all live PES packets
during the time the playback was suspended in the plugin.  However,
the PES packets from recordings should be blocked.

I believe that the easy fix would be to have these methods return 0 only
when playing a recording.  Can the plugin detect this somehow?

Marko

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