Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Oliver Endriss]

Am Montag, den 02.04.2018, 18:40 +0200 schrieb Klaus Schmidinger:
> On 02.04.2018 14:20, Oliver Endriss wrote:
> > Am Montag, den 02.04.2018, 12:28 +0200 schrieb Klaus Schmidinger:
> >> On 01.04.2018 19:01, Oliver Endriss wrote:
> >> > ...
> >> >> >> >> Does it make a difference whether the progress display is active 
> >> >> >> >> or not
> >> >> >> >> when you set the mark?
> >> >> > 
> >> >> > If the progress bar is off, and you set a mark, progress bar and
> >> >> > mark show up immediately. -> No problem.
> >> >> 
> >> >> ...
> >> >> > Could it be that this action is triggered _before_ the mark has been
> >> >> > written to the OSD buffer? In this case, the OSD would be displayed
> >> >> > without the mark, and the mark would be displayed during the next
> >> >> > cycle, i.e. one second later.
> >> >> 
> >> >> I doubt that.
> >> 
> >> Well, meanwhile I think you were right here.
> >> In cReplayControl::MarkToggle() there is
> >> 
> >>lastCurrent = -1; // triggers redisplay
> >> 
> >> which it used to do until the switch to GetFrameNumber() ;-).
> >> 
> >> Now this has no immediate effect any more, and that may explain
> >> the sluggishness you observe.
> >> 
> >> Please try this:
> >> 
> >> --- menu.c  2018/03/24 11:43:40 4.70
> >> +++ menu.c  2018/04/02 10:07:05
> >> @@ -5728,7 +5728,7 @@
> >>   bool cReplayControl::ShowProgress(bool Initial)
> >>   {
> >> int Current, Total;
> >> -  if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) 
> >> {
> >> +  if (Initial || lastCurrent < 0 || lastSpeed != -1 || time(NULL) - 
> >> lastProgressUpdate >= 1) {
> >>if (GetFrameNumber(Current, Total) && Total > 0) {
> >>   if (!visible) {
> >>  displayReplay = Skins.Current()->DisplayReplay(modeOnly);
> >> 
> >> > I am pretty sure that something is wrong.
> >> > With the following (ugly) patch, the problem is gone:
> >> > ...
> >> > All it does is executing the code in 'if (Initial...)' one more time,
> >> > after lastProgressUpdate has been set to 0.
> >> 
> >> Thanks for pointing this out. This triggered my idea with lastCurrent 
> >> above.
> > 
> > Thanks, your patch fixed the issue.
> 
> Taking a step back and considering that GetFrameNumber() was supposed to
> be a drop-in replacement for GetIndex(), just returning the exact number
> of the currently replayed frame and not just the index into the 'index'
> file (which, apart from I-frames, is typically different) I revoked the
> whole change and simply replaced GetIndex() with GetFrameNumber(). That
> resulted in the sluggish progress display on the Raspberry Pi I reported
> earlier. I then found that this was caused by the extra Flush() calls in
> cReplayControl::ShowProgress(). So I removed them and now everything runs
> smoothly on the RasPi and also on softhddevice.
> So please try the attached patch instead of the previous one, and especially
> check whether it still works on the dvbsddevice. This should hopefully also
> fix the "jumping progress display".

Works fine with HD/SD/radio recordings. Tested with dvbhddevice
and dvbsddevice. Both problems are fixed. Thank you.

> There is, apparently, still a problem on the RasPi, where once you set
> a mark, a subsequent "play" doesn't take effect until a couple of seconds
> later. However, since this doesn't occur with softhddevice, I assume this
> is a RasPi specific problem. I'll discuss this with Thomas separately.

This does not occur with the FF cards.

Oliver

-- 

VDR Remote Plugin 0.7.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/



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

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Oliver Endriss]

Am Montag, den 02.04.2018, 12:28 +0200 schrieb Klaus Schmidinger:
> On 01.04.2018 19:01, Oliver Endriss wrote:
> > ...
> >> >> >> Does it make a difference whether the progress display is active or 
> >> >> >> not
> >> >> >> when you set the mark?
> >> > 
> >> > If the progress bar is off, and you set a mark, progress bar and
> >> > mark show up immediately. -> No problem.
> >> 
> >> ...
> >> > Could it be that this action is triggered _before_ the mark has been
> >> > written to the OSD buffer? In this case, the OSD would be displayed
> >> > without the mark, and the mark would be displayed during the next
> >> > cycle, i.e. one second later.
> >> 
> >> I doubt that.
> 
> Well, meanwhile I think you were right here.
> In cReplayControl::MarkToggle() there is
> 
>lastCurrent = -1; // triggers redisplay
> 
> which it used to do until the switch to GetFrameNumber() ;-).
> 
> Now this has no immediate effect any more, and that may explain
> the sluggishness you observe.
> 
> Please try this:
> 
> --- menu.c  2018/03/24 11:43:40 4.70
> +++ menu.c  2018/04/02 10:07:05
> @@ -5728,7 +5728,7 @@
>   bool cReplayControl::ShowProgress(bool Initial)
>   {
> int Current, Total;
> -  if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1) {
> +  if (Initial || lastCurrent < 0 || lastSpeed != -1 || time(NULL) - 
> lastProgressUpdate >= 1) {
>if (GetFrameNumber(Current, Total) && Total > 0) {
>   if (!visible) {
>  displayReplay = Skins.Current()->DisplayReplay(modeOnly);
> 
> > I am pretty sure that something is wrong.
> > With the following (ugly) patch, the problem is gone:
> > ...
> > All it does is executing the code in 'if (Initial...)' one more time,
> > after lastProgressUpdate has been set to 0.
> 
> Thanks for pointing this out. This triggered my idea with lastCurrent above.

Thanks, your patch fixed the issue.

> > Of course, it does not affect the 'jumping' progress bar. See below.
> > ...
> >> > Btw, with a short recording, you can see that the progress bar is
> >> > jumping in one second steps...
> >> 
> >> That's pretty much the distance between the I-frames, and thus the steps in
> >> which VDR updates the progress bar.
> > 
> > I don't care about I-frames. I use the cutter to produce small audio
> > or video clips. The current behavior of the progress bar is annoying,
> > when I play these clips. Anyway, I can easily revert the code to get
> > the old behavior.
> 
> Is the jumping mainly with radio recordings?

No, it happens with all types of recordings - radio, SD and HD.
It depends on the _length_ of the recording. The recording must
be short, otherwise the effect is not visible.

> If so, that could be explained by the lastProgressUpdate timeout, because
> in radio recordings every frame is considered to be an "I-frame", while
> in video recordings I-frames are typically spaced 0.5 to 1 second.

It has nothing to with I-frames. It is solely caused by the
lastProgressUpdate timeout, which is 1 second. Try this:

Create a 2..3 minutes recording. Play it. You will see that the
progress display is not moving smoothly, because it is updated
every second.

> Let's first see whether the above patch fixes your sluggish marks display,
> and then continue with the jumping progress bar.

I am not sure if you want to implement a dynamic update of the
progress bar: The progress bar should be updated more often,
when the recording is short...

Oliver

-- 

VDR Remote Plugin 0.7.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/



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

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Oliver Endriss]

Am Samstag, den 24.03.2018, 15:05 +0100 schrieb Klaus Schmidinger:
> On 19.03.2018 18:01, Oliver Endriss wrote:
> > Am Montag, den 19.03.2018, 14:45 +0100 schrieb Klaus Schmidinger:
> >> On 19.03.2018 01:33, Oliver Endriss wrote:
> >> > Am Sonntag, den 18.03.2018, 23:29 +0100 schrieb Klaus Schmidinger:
> >> >> On 18.03.2018 20:39, Oliver Endriss wrote:
> >> >> > Am Sonntag, den 18.03.2018, 19:15 +0100 schrieb Klaus Schmidinger:
> >> >> >> On 18.03.2018 18:55, Oliver Endriss wrote:
> >> >> >> > Hi,
> >> >> >> > 
> >> >> >> > just installed vdr 2.3.9 and noticed that there is a delay
> >> >> >> > when I try to set a recording mark, compared with vdr 2.2.0.
> >> >> >> > 
> >> >> >> > Steps to reproduce:
> >> >> >> > - Play a recording.
> >> >> >> > - Press ok to display the progress bar.
> >> >> >> > - Press 0 to set a mark.
> >> >> >> > 
> >> >> >> > There is a notable delay between the keypress
> >> >> >> > and the mark showing up.
> >> >> >> > 
> >> >> >> > Can someone confirm this?
> >> >> >> 
> >> >> >> Tried it while replaying on a Raspberry Pi, with the video directory
> >> >> >> mounted via NFS, and had no unusual delay.
> >> >> >> 
> >> >> >> - Which skin are you using?
> >> >> > Classic skin.
> >> >> > 
> >> >> >> - If applicable: Does it also happen with the LCARS skin?
> >> >> > Yes.
> >> >> > 
> >> >> >> - Are you running any plugins that utilize the 
> >> >> >> cStatus::MarksModified() function?
> >> >> > No. Test setup: vdr + dvbsddevice + remote.
> >> >> 
> >> >> I'm afraid I don't have a working VDR with the old FF card any more, so
> >> >> I can't test on that hardware. It doesn't happen with the Raspberry Pi, 
> >> >> though.
> >> >> 
> >> >> Does it make a difference whether the progress display is active or not
> >> >> when you set the mark?
> >> 
> >> Can you comment on this one?
> > 
> > If the progress bar is off, and you set a mark, progress bar and
> > mark show up immediately. -> No problem.
> 
> Very good!
> 
> >> >> >> - If none of the above: can you determine which version between 
> >> >> >> 2.2.0 and
> >> >> >>2.3.9 introduced this?
> >> >> > 
> >> >> > Ok. I went back in time and installed the older versions.
> >> >> > Problem appeared with vdr-2.3.2, vdr-2.3.1 tested ok.
> >> >> 
> >> >> The only change that was introduced in that area between these two 
> >> >> versions
> >> >> is in cReplayControl::ShowProgress():
> >> >> 
> >> >>if (Initial || time(NULL) - lastProgressUpdate >= 1) {
> >> >> 
> >> >> Please try commenting out that line and the corresponding closing '}'.
> >> >> While I don't see why this would only be a problem on dvbsddevice and 
> >> >> not
> >> >> on rpihddevice, I strongly suspect it to be the culprit.
> >> > 
> >> > Yes, this fixes the issue completely!
> >> 
> >> If I do the same on the Raspberry Pi, the display *becomes* sluggish ;-).
> > 
> > So is this a workaround for the Raspberry?
> 
> Not in particular.
> At the time this was done, I was still using the TT S2-6400 as output device.

Hm, this is not required for my S2-6400.

> >> > In vdr-2.3.9 the line looks like
> >> >   if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1)
> >> > 
> >> > As a consequence, the mark shows up immediately during fast-forward,
> >> > while it is displayed with (variable) delay in play mode.
> >> 
> >> In cReplayControl::ProcessKey() there is
> >> 
> >>if (Key != kNone)
> >>   lastProgressUpdate = 0;
> >> 
> >> so I would expect the condition 'time(NULL) - lastProgressUpdate >= 1' to
> >> always be true immediately after a key has been pressed ('0' in case of
> >> setting a ma

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Oliver Endriss]

Am Montag, den 19.03.2018, 14:45 +0100 schrieb Klaus Schmidinger:
> On 19.03.2018 01:33, Oliver Endriss wrote:
> > Am Sonntag, den 18.03.2018, 23:29 +0100 schrieb Klaus Schmidinger:
> >> On 18.03.2018 20:39, Oliver Endriss wrote:
> >> > Am Sonntag, den 18.03.2018, 19:15 +0100 schrieb Klaus Schmidinger:
> >> >> On 18.03.2018 18:55, Oliver Endriss wrote:
> >> >> > Hi,
> >> >> > 
> >> >> > just installed vdr 2.3.9 and noticed that there is a delay
> >> >> > when I try to set a recording mark, compared with vdr 2.2.0.
> >> >> > 
> >> >> > Steps to reproduce:
> >> >> > - Play a recording.
> >> >> > - Press ok to display the progress bar.
> >> >> > - Press 0 to set a mark.
> >> >> > 
> >> >> > There is a notable delay between the keypress
> >> >> > and the mark showing up.
> >> >> > 
> >> >> > Can someone confirm this?
> >> >> 
> >> >> Tried it while replaying on a Raspberry Pi, with the video directory
> >> >> mounted via NFS, and had no unusual delay.
> >> >> 
> >> >> - Which skin are you using?
> >> > Classic skin.
> >> > 
> >> >> - If applicable: Does it also happen with the LCARS skin?
> >> > Yes.
> >> > 
> >> >> - Are you running any plugins that utilize the cStatus::MarksModified() 
> >> >> function?
> >> > No. Test setup: vdr + dvbsddevice + remote.
> >> 
> >> I'm afraid I don't have a working VDR with the old FF card any more, so
> >> I can't test on that hardware. It doesn't happen with the Raspberry Pi, 
> >> though.
> >> 
> >> Does it make a difference whether the progress display is active or not
> >> when you set the mark?
> 
> Can you comment on this one?

If the progress bar is off, and you set a mark, progress bar and
mark show up immediately. -> No problem.

> >> >> - If none of the above: can you determine which version between 2.2.0 
> >> >> and
> >> >>2.3.9 introduced this?
> >> > 
> >> > Ok. I went back in time and installed the older versions.
> >> > Problem appeared with vdr-2.3.2, vdr-2.3.1 tested ok.
> >> 
> >> The only change that was introduced in that area between these two versions
> >> is in cReplayControl::ShowProgress():
> >> 
> >>if (Initial || time(NULL) - lastProgressUpdate >= 1) {
> >> 
> >> Please try commenting out that line and the corresponding closing '}'.
> >> While I don't see why this would only be a problem on dvbsddevice and not
> >> on rpihddevice, I strongly suspect it to be the culprit.
> > 
> > Yes, this fixes the issue completely!
> 
> If I do the same on the Raspberry Pi, the display *becomes* sluggish ;-).

So is this a workaround for the Raspberry?

> > In vdr-2.3.9 the line looks like
> >   if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1)
> > 
> > As a consequence, the mark shows up immediately during fast-forward,
> > while it is displayed with (variable) delay in play mode.
> 
> In cReplayControl::ProcessKey() there is
> 
>if (Key != kNone)
>   lastProgressUpdate = 0;
> 
> so I would expect the condition 'time(NULL) - lastProgressUpdate >= 1' to
> always be true immediately after a key has been pressed ('0' in case of
> setting a mark).
> Can you verify this by adding some debug output?

Debug output indicates that this is true.

Could it be that this action is triggered _before_ the mark has been
written to the OSD buffer? In this case, the OSD would be displayed
without the mark, and the mark would be displayed during the next
cycle, i.e. one second later.

> > In vdr-2.3.2, "lastSpeed != -1" is missing, so fast-forward
> > is affected, too.
> > 
> > Anyway, I do not understand why rpihddevice should behave differently.
> > Does this device have a slow OSD? In this case you might not notice...
> 
> The OSD on the RasPi is a lot faster than that on the old FF cards.
> 
> > I will update my dvbhddevice vdr to vdr-2.3.9 soon.
> > I expect that it affected the same way.
> 
> I used a TT S2-6400 until recently (the motherboard is broken) and had no
> problems setting editing marks. I'm curious to see what your experience
> will be.

Update: The HD FF behaves exactly the same way as the SD FF.

Btw, with a short recording, you can see that the progress bar is
jumping in one second steps...

Oliver

-- 

VDR Remote Plugin 0.7.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/



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

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Oliver Endriss]

Am Sonntag, den 18.03.2018, 23:29 +0100 schrieb Klaus Schmidinger:
> On 18.03.2018 20:39, Oliver Endriss wrote:
> > Am Sonntag, den 18.03.2018, 19:15 +0100 schrieb Klaus Schmidinger:
> >> On 18.03.2018 18:55, Oliver Endriss wrote:
> >> > Hi,
> >> > 
> >> > just installed vdr 2.3.9 and noticed that there is a delay
> >> > when I try to set a recording mark, compared with vdr 2.2.0.
> >> > 
> >> > Steps to reproduce:
> >> > - Play a recording.
> >> > - Press ok to display the progress bar.
> >> > - Press 0 to set a mark.
> >> > 
> >> > There is a notable delay between the keypress
> >> > and the mark showing up.
> >> > 
> >> > Can someone confirm this?
> >> 
> >> Tried it while replaying on a Raspberry Pi, with the video directory
> >> mounted via NFS, and had no unusual delay.
> >> 
> >> - Which skin are you using?
> > Classic skin.
> > 
> >> - If applicable: Does it also happen with the LCARS skin?
> > Yes.
> > 
> >> - Are you running any plugins that utilize the cStatus::MarksModified() 
> >> function?
> > No. Test setup: vdr + dvbsddevice + remote.
> 
> I'm afraid I don't have a working VDR with the old FF card any more, so
> I can't test on that hardware. It doesn't happen with the Raspberry Pi, 
> though.
> 
> Does it make a difference whether the progress display is active or not
> when you set the mark?
> 
> >> - If none of the above: can you determine which version between 2.2.0 and
> >>2.3.9 introduced this?
> > 
> > Ok. I went back in time and installed the older versions.
> > Problem appeared with vdr-2.3.2, vdr-2.3.1 tested ok.
> 
> The only change that was introduced in that area between these two versions
> is in cReplayControl::ShowProgress():
> 
>if (Initial || time(NULL) - lastProgressUpdate >= 1) {
> 
> Please try commenting out that line and the corresponding closing '}'.
> While I don't see why this would only be a problem on dvbsddevice and not
> on rpihddevice, I strongly suspect it to be the culprit.

Yes, this fixes the issue completely!

In vdr-2.3.9 the line looks like
 if (Initial || lastSpeed != -1 || time(NULL) - lastProgressUpdate >= 1)

As a consequence, the mark shows up immediately during fast-forward,
while it is displayed with (variable) delay in play mode.

In vdr-2.3.2, "lastSpeed != -1" is missing, so fast-forward
is affected, too.

Anyway, I do not understand why rpihddevice should behave differently.
Does this device have a slow OSD? In this case you might not notice...

I will update my dvbhddevice vdr to vdr-2.3.9 soon.
I expect that it affected the same way.

Oliver

-- 

VDR Remote Plugin 0.7.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/



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

Re: [vdr] [vdr 2.3.9] Setting a mark is sluggish

[Oliver Endriss]

Am Sonntag, den 18.03.2018, 19:15 +0100 schrieb Klaus Schmidinger:
> On 18.03.2018 18:55, Oliver Endriss wrote:
> > Hi,
> > 
> > just installed vdr 2.3.9 and noticed that there is a delay
> > when I try to set a recording mark, compared with vdr 2.2.0.
> > 
> > Steps to reproduce:
> > - Play a recording.
> > - Press ok to display the progress bar.
> > - Press 0 to set a mark.
> > 
> > There is a notable delay between the keypress
> > and the mark showing up.
> > 
> > Can someone confirm this?
> 
> Tried it while replaying on a Raspberry Pi, with the video directory
> mounted via NFS, and had no unusual delay.
> 
> - Which skin are you using?
Classic skin.

> - If applicable: Does it also happen with the LCARS skin?
Yes.

> - Are you running any plugins that utilize the cStatus::MarksModified() 
> function?
No. Test setup: vdr + dvbsddevice + remote.

> - If none of the above: can you determine which version between 2.2.0 and
>2.3.9 introduced this?

Ok. I went back in time and installed the older versions.
Problem appeared with vdr-2.3.2, vdr-2.3.1 tested ok.

Oliver

-- 

VDR Remote Plugin 0.7.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/




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

[vdr] [vdr 2.3.9] Setting a mark is sluggish

[Oliver Endriss]

Hi,

just installed vdr 2.3.9 and noticed that there is a delay
when I try to set a recording mark, compared with vdr 2.2.0.

Steps to reproduce:
- Play a recording.
- Press ok to display the progress bar.
- Press 0 to set a mark.

There is a notable delay between the keypress
and the mark showing up.

Can someone confirm this?

Oliver
 
-- 

VDR Remote Plugin 0.7.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/




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

[vdr] [ANNOUNCE] Remote Control Plugin 0.6.0

[Oliver Endriss]

Hi,

there is an new release of the remote control plugin.


History:

2015-04-12: Version 0.6.0
- Use Repeat Delay/Repeat Delta settings (VDR->Setup->Miscellaneous).
- Support event type 2 (mouse wheel, rotary-encoder) as a remote control
  (thanks to Thomas Reufer).
- Improved OSD emulation:
  o Reworked tabulator processing.
  o Optimal use of limited screen width.
  o Avoid display errors with VDR 2.2.0.
  o Fixed misaligned output caused by multi-byte characters.
  o Some speed improvements.


It can be downloaded from 
http://www.escape-edv.de/endriss/vdr/

See README for details.


Short description:
--
This plugin extends the remote control capabilities of vdr.
The following remote control devices are supported:

(a) linux input device driver ('/dev/input/eventX', X=0,1,2,...)
- Built-in remote control port of the TT DVB-S2 6400
  (HD full-featured card).
- Built-in remote control port of the av711x-based DVB cards
  (SD full-featured cards), e.g. DVB-S Nexus.
- Remote control port of some budget cards, e.g. Nova-CI.
- Other input devices (rotary-encoder, wheel mouse).
See file FAQ for a list of cards which have been reported to work.

(b) keyboard (tty driver): /dev/console, /dev/ttyX

(c) TCP connection (telnet)

(d) LIRC


Have fun,

Oliver

-- 

VDR Remote Plugin 0.6.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/


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

Re: [vdr] VDR jumps to old position after ff/rew

[Oliver Endriss]

Stefan Schallenberg  wrote:
> Am 27.08.2013 22:05, schrieb Klaus Schmidinger:
> > On 27.08.2013 20:47, Stefan Schallenberg wrote:
> >> Hi all,
> >>
> >> Thanks for your ideas.
> >>
> >> I am using an old (SD but not HD) FF PCI card and non-HD recordings. 
> >> So neither of the situations you described applies as far as I 
> >> understan.
> >
> > Are you sure you are using the latest driver and firmware for that card?
> > Old versions might not return the actual STC value.
>
> Hi Klaus,
> 
> I am using OpenSUSE 12.3 with standard kernel 3.7.10. - do you think I 
> need to switch to Liplianin or other driver packages forcing me to 
> recompile parts of the kernel?
> 
> On the same system VDR 1.6 did not show the problem, does VDR 2.x handle 
> DVB device (dvbsddevice plugin) different than 1.6?


>From HISTORY:
| 2009-04-12: Version 1.7.5
| ...
|  + cDevice::GetSTC() is now required to deliver the STC even in trick modes.
|It is sufficient if it returns the PTS of the most recently presented
|audio/video frame.
|  + The full-featured DVB cards need an improved firmware in order to return
|proper STC values in trick modes.
| ...

You can download an updated firmware from
http://www.escape-edv.de/endriss/firmware/

CU
Oliver

-- 

VDR Remote Plugin 0.5.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/


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

Re: [vdr] Channel update on HD transponders broken?

[Oliver Endriss]

Udo Richter  wrote:
> Hi list,
> 
> I've noticed that I don't get channel updates any more on most of the
> German HD transponders, since my update from 1.7.37 to 1.7.41 on
> 2013-03-16. I'm running VDR in "add new transponders" full update mode.
> I didn't check 1.7.42 yet, sorry.
> 
> I'm running a very minimal old patch that tracks the time of the last
> channel update, so I'm pretty sure that the channel update stopped
> exactly at 2013-03-16 for all channels on the following 19.2E transponders:
> 
> 10773 (ANIXE HD/BetaDigital),
> 10802 (ASTRA 3D Demo/BetaDigital),
> 11082 (RTL HD Austria),
> 11170 (OrangeSAT),
> 11302 (ORF1 HD),
> 11332 (Syfy HD/SKY),
> 11361 (ZDF HD),
> 11464 (ProSieben HD),
> 11493 (Das Erste HD).
> 
> All other transponders get updated normally. To check whether channel
> update works, try to edit the channel name of Das Erste HD. Channel
> update should restore the original name almost instantly.
> 
> First, can someone reproduce this with their VDR? I don't want to stop
> the presses unnecessarily.

Could you test whether the patch in the VDR portal post
http://www.vdr-portal.de/board17-developer/board97-vdr-core/p1135671-gelöst-keine-epg-anzeige-für-das-erste-hd-zdf-hd-und-ndr-mv-hd-nach-wechsel-von-1-7-29-auf-1-7-42/#post1135671
fixes your problem?

CU
Oliver

-- 

VDR Remote Plugin 0.5.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/


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

[vdr] [ANNOUNCE] Remote Control Plugin 0.5.0

[Oliver Endriss]

Hi,

there is an update for the remote control plugin.

Compilation has been tested with VDR 1.4.7, 1.6.0, 1.7.31 and 1.7.34.
Other releases should work as well.


History:

2012-12-26: Version 0.5.0
- gettext detection modified to use $(VDRDIR)/i18n.h (thanks to Tobias Grimm).
- Updated Italian language texts.
- Fixed some compiler warnings.
- Telnet section added to FAQ.
- GPL text added to all source files.
- Fixed crash with TTY and/or Telnet remotes when VDR terminated.
- Access /proc/av7110_ir in write-only mode (required by kernel 2.6.34+).
- Adopt Makefile for vdr 1.7.34+.

It can be downloaded from 
http://www.escape-edv.de/endriss/vdr/

See README for details.


Short description:
--
This plugin extends the remote control capabilities of vdr.
The following remote control devices are supported:

(a) linux input device driver ('/dev/input/eventX', X=0,1,2,...)
- Built-in remote control port of the TT DVB-S2 6400
  (HD full-featured card).
- Built-in remote control port of the av711x-based DVB cards
  (SD full-featured cards), e.g. DVB-S Nexus.
- Remote control port of some budget cards, e.g. Nova-CI.
- Other input devices.
See file FAQ for a list of cards which have been reported to work.

(b) keyboard (tty driver): /dev/console, /dev/ttyX

(c) TCP connection (telnet)

(d) LIRC


Have fun,

Oliver
-- 

VDR Remote Plugin 0.5.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/


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

Re: [vdr] vdr-1.7.32 plugin dvbhddevice fails

[Oliver Endriss]

Richard Scobie  wrote:
> Hi Gerald,
> 
> Gerald Dachs wrote:
> 
> > If you would take a deeper look into your post you would have noticed 
> > that the mentioned file bitbuffer.o is not
> > build to this time. It must have been build in a former stage. So there 
> > is still no proof that it
> > has been build with -fPIC.
> > 
> 
> You are correct. It appears none of the object files in 
> dvbhddevice/libhdffcmd are being built without -fPIC, whereas all other 
> object files in all the other plugins are, so I will investigate further.


The attached patch should fix this problem.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/

diff -pur dvbhddevice.org/Makefile dvbhddevice/Makefile
--- dvbhddevice.org/Makefile	2012-03-11 16:34:00.0 +0100
+++ dvbhddevice/Makefile	2012-11-20 15:06:37.0 +0100
@@ -99,7 +99,7 @@ i18n: $(I18Nmsgs) $(I18Npot)
 ### Targets:
 
 libvdr-$(PLUGIN).so: $(OBJS) libhdffcmd
-	$(MAKE) -C libhdffcmd all
+	$(MAKE) -C libhdffcmd PLUGIN=$(PLUGIN) all
 	$(CXX) $(CXXFLAGS) -shared $(OBJS) libhdffcmd/libhdffcmd.a -o $@
 	@cp --remove-destination $@ $(LIBDIR)/$@.$(APIVERSION)
 
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr

Re: [vdr] playback problems with recordings with vdr-1.7.20 and newer

[Oliver Endriss]

On Friday 27 January 2012 15:30:18 Andreas Albert wrote:
> Hello,
> 
> this problem have already been posted at the mailing list in post
> http://www.linuxtv.org/pipermail/vdr/2012-January/025616.html
> 
> > Then i got an other problem. When watching a recording, and i
> > fastforward of rewind the program, i get to a situation that the
> > "timecounter" get's stuck to the frame i start from. The film moves, but
> > when i hit play, i end up back to the frame from where i started to
> > rewind/fastforwad. The only way to fix this is to jump with the
> > yellow/green buttons. AFter this i can rewind/fastforwad normally. This
> > again works for a while, but again if it fails to stop to the place i
> > rewind to, i have to "reset" the rewind-issue with the yellow/green
> > buttons...
> 
> My output device is a Technotrend FF S-2300 with the dvbsddevice-plugin.
> 
> I wrote this topic again, because there isn't an answer in the topic above.
> 
> Can anyone help me?

>From HISTORY:
| 2009-04-12: Version 1.7.5
| ...
|  + cDevice::GetSTC() is now required to deliver the STC even in trick modes.
|It is sufficient if it returns the PTS of the most recently presented
|audio/video frame.
|  + The full-featured DVB cards need an improved firmware in order to return
|proper STC values in trick modes.
| ...


You can download an updated firmware from
http://www.escape-edv.de/endriss/firmware/

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/


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

Re: [vdr] vdr 1.7.23: patch for handling symlinks in recordings directory as earlier

[Oliver Endriss]

On Thursday 26 January 2012 11:07:18 Klaus Schmidinger wrote:
> On 25.01.2012 14:11, Oliver Endriss wrote:
> > On Wednesday 25 January 2012 10:29:16 Klaus Schmidinger wrote:
> >> On 17.01.2012 14:26, sundararaj reel wrote:
> >>> Hi,
> >>>
> >>> I am attaching a patch for vdr 1.7.23 for the problem described here:
> >>> http://www.vdr-portal.de/board1-news/board2-vdr-news/p1047199-announce-vdr-developer-version-1-7-23/#post1047199
> >>>
> >>> There appears to be a problem in listing recordings due to a bug fix
> >>> in vdr 1.7.23. "Fixed handling symbolic links in
> >>> cRecordings::ScanVideoDir()"
> >>>
> >>> The attached patch just disables the translation of symbolic links to
> >>> "real" paths. So that all recordings appear to be under the same
> >>> (recordings) directory tree, as it was earlier.
> >>>
> >>> Please reply with your results.
> >>
> >> Can somebody who has actually this use case please confirm
> >> whether this patch fixes the problem?
> >
> > Confirmed.
> >
> > Without this patch, symbolic links are not displayed
> > correctly on my machine.
> >
> > Oliver
> 
> Thanks.
> 
> I believe the second call to stat() is now superfluous.
> Can you please confirm that the following patch still works
> as expected?
> 
> --- recording.c 2012/01/25 09:32:39 2.45
> +++ recording.c 2012/01/26 10:02:29
> @@ -1120,11 +1120,6 @@
>   continue;
>   }
>Link = 1;
> - buffer = ReadLink(buffer);
> - if (!*buffer)
> -continue;
> - if (stat(buffer, &st) != 0)
> -continue;
>}
> if (S_ISDIR(st.st_mode)) {
>if (endswith(buffer, deleted ? DELEXT : RECEXT)) {

Yes, it does not make any difference here.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/


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

Re: [vdr] vdr 1.7.23: patch for handling symlinks in recordings directory as earlier

[Oliver Endriss]

On Wednesday 25 January 2012 10:29:16 Klaus Schmidinger wrote:
> On 17.01.2012 14:26, sundararaj reel wrote:
> > Hi,
> >
> > I am attaching a patch for vdr 1.7.23 for the problem described here:
> > http://www.vdr-portal.de/board1-news/board2-vdr-news/p1047199-announce-vdr-developer-version-1-7-23/#post1047199
> >
> > There appears to be a problem in listing recordings due to a bug fix
> > in vdr 1.7.23. "Fixed handling symbolic links in
> > cRecordings::ScanVideoDir()"
> >
> > The attached patch just disables the translation of symbolic links to
> > "real" paths. So that all recordings appear to be under the same
> > (recordings) directory tree, as it was earlier.
> >
> > Please reply with your results.
> 
> Can somebody who has actually this use case please confirm
> whether this patch fixes the problem?

Confirmed.

Without this patch, symbolic links are not displayed
correctly on my machine.

Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/


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

Re: [vdr] OT: Applications for the living room

[Oliver Endriss]

Paul Menzel wrote:
> > I just checked my archives and found that VDR replaced my analogue SAT
> > receiver around July 2002. From the beginning it was the most useful
> > linux application I ever tried. And it is still the only one which made
> > it into the living room.
> 
> Just out of curiosity, what other applications do you use in your living
> room? And do you have different system or just one on which virtual
> machines are running?

The VDR machine is the only PC-like hardware in the living-room.
It is based on old PIII 800 MHz hardware, and it runs rock-stable.
:-)

It will not be replaced before the HDTV VDR is mature. The biggest
problem is that my eyes do not like the picture quality of current LCDs.

Of course, there is more PC hardware outside of the living-room
(server, workstations).

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/


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

Re: [vdr] 10 Year Anniversary of VDR

[Oliver Endriss]

Happy Birthday VDR!

Klaus Schmidinger wrote:
> It has been exactly 10 years since version 0.01 of VDR (originally
> named "OSM" - On Screen Menu) was released.
> 
> I want to use the occasion to thank everybody who has contributed
> to VDR, but also those who simply use VDR in their every day life.
> I for one couldn't imagine watching tv without VDR any more. Special
> thanks go to the people running the VDR-Portal (www.vdr-portal.de).

Thank you, Klaus, for this great software!

I just checked my archives and found that VDR replaced my analogue SAT
receiver around July 2002. From the beginning it was the most useful
linux application I ever tried. And it is still the only one which made
it into the living room.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/


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

Re: [vdr] vdr-1.7.12 & folders.conf

[Oliver Endriss]

Klaus Schmidinger wrote:
> On 06.02.2010 12:27, Halim Sahin wrote:
> > Hi,
> > Just my opinion about the problem:
> > The fat filesystem has many limitations and I vote for dropping special
> > support for it in VDR because if someone wants to use a windows system,
> > he/she can use ntfs which works fine in current distributions (ntfs-3g).
> > Just my 2 Cents.
> 
> I would do that in a heartbeat - but I guess that would cause
> a huge flame war... ;-)

...and you would loose the ability to use vanilla USB sticks. Bad idea.

Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/


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

Re: [vdr] multiple non-independent frontends (was: Re: [ANNOUNCE] VDR developer version 1.7.11)

[Oliver Endriss]

Manu Abraham wrote:
> On Wed, Jan 6, 2010 at 7:52 PM, Oliver Endriss  wrote:
> > Manu Abraham wrote:
> >> On Wed, Jan 6, 2010 at 5:55 PM, Klaus Schmidinger
> >>  wrote:
> >> > On 06.01.2010 14:22, Tomasz Bubel wrote:
> >> >> [...]
> >> >>> - Added support for DVB cards with multiple fontends. Note that this 
> >> >>> only
> >> >>>  works for DVB cards where each frontend can be used independently of 
> >> >>> all
> >> >>>  the others on the same adapter.
> >> >> [...]
> >> >> Any chance of using using DVB-T frontend on HVR-4000? This card have 2
> >> >> separate frontends. And as quoted on
> >> >> http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000:
> >> >>
> >> >> "Multiple frontends are supported: DVB-S/S2 and DVB-T appear as
> >> >> /dev/dvb/adapterN/frontend0 and /dev/dvb/adapterN/frontend1
> >> >> respectively.
> >> >>
> >> >> Due to a hardware limitation, the two frontends cannot be used
> >> >> simultaneously. However they can be used sequentially within the same
> >> >> application. The driver handles the mutual exclusion appropriately."
> >> >
> >> > Well, that's still a problem.
> >> > Is there a defined way (via the LinuxDVB driver API) through which VDR
> >> > can find out whether the frontends can be used independently?
> >>
> >> Some more food for thought ..
> >>
> >> There is also one more added problem: Say there are two adapters and
> >> two frontends. I will try to convey the thought as simplest as
> >> possible by me...
> >>
> >> A case in which frontend0 is bound to adapter0 and frontend1 is bound
> >> to adapter 1
> >>
> >> This would seem like a classical case of having 2 independent
> >> adapters. But let's analyze it a bit more deeply. The two adapters A0
> >> and A1 are on the same physical A (adapter) chip and can send you data
> >> simultaneously on both the devices. Likewise F0 and F1 can be on the
> >> same physical F (frontend) chip and can send you simultaneous data to
> >> both A0 and A1.
> >>
> >> Now suppose that you are having F0 and F1 operational: The F chip
> >> would have a limitation on some parameter, which is based on a
> >> combination of F0 and F1. If the sum parameter is exceeded on the
> >> whole F chip, the entire F chip would crash and might need a Reset.
> >>
> >> Likewise the same holds good for the A chip too ..
> >>
> >> Another case is where you have A0, A1 and F0, F1 on the same chip
> >> while additionally providing F2 and F3 on virtual A0' and A1'.
> >>
> >> But in all cases, the question remains the same. How would the
> >> application like to handle a situation, when a certain parameter will
> >> be exceed on the next operation on the next 'Fx' interface ? (If the
> >> application feels free and does the operation which might cause some
> >> parameter to exceed, the chip as a whole would not respond, unless
> >> reset again)
> >>
> >> Operations like this might be common on cards having dual, quad and
> >> hex frontends. The card itself might be able to stream dual, quad and
> >> hex simultaneous streams.
> >
> > Imho limitations or dependencies between different *adapters* are not
> > acceptable. If a driver maps frontends to different adapters, the driver
> > pretends that they can be used independent of each other and without
> > limitations.
> >
> > If there are limitations, the frontends must be assigned to the same
> > adapter. Anything else does not make any sense to me.
> 
> Ok, I agree to your point. But it all depends on what we define an adapter is:

I define an adapter as the entity /dev/dvb/adapterX,
as seen by the application software.

An application may assume that devices from adapter X do not interfere
with devices from adapterY (X != Y).

It does not matter, whether two adapters reside on the same hardware
(PCI card, whatever), if (and only if) the driver can guarantee that
they do not interfere.

In this case it is the choice of the driver developer, whether he uses
one or more adapters. I prefer one adapter.

> Is the adapter specified by the I2C interface, or is it by the actual
> number of DMA interface ?

No, these are internals of the driver. User space software should not
have to care about this stuff.

> In the case o

Re: [vdr] multiple non-independent frontends (was: Re: [ANNOUNCE] VDR developer version 1.7.11)

[Oliver Endriss]

Manu Abraham wrote:
> On Wed, Jan 6, 2010 at 5:55 PM, Klaus Schmidinger
>  wrote:
> > On 06.01.2010 14:22, Tomasz Bubel wrote:
> >> [...]
> >>> - Added support for DVB cards with multiple fontends. Note that this only
> >>>  works for DVB cards where each frontend can be used independently of all
> >>>  the others on the same adapter.
> >> [...]
> >> Any chance of using using DVB-T frontend on HVR-4000? This card have 2
> >> separate frontends. And as quoted on
> >> http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000:
> >>
> >> "Multiple frontends are supported: DVB-S/S2 and DVB-T appear as
> >> /dev/dvb/adapterN/frontend0 and /dev/dvb/adapterN/frontend1
> >> respectively.
> >>
> >> Due to a hardware limitation, the two frontends cannot be used
> >> simultaneously. However they can be used sequentially within the same
> >> application. The driver handles the mutual exclusion appropriately."
> >
> > Well, that's still a problem.
> > Is there a defined way (via the LinuxDVB driver API) through which VDR
> > can find out whether the frontends can be used independently?
> 
> Some more food for thought ..
> 
> There is also one more added problem: Say there are two adapters and
> two frontends. I will try to convey the thought as simplest as
> possible by me...
> 
> A case in which frontend0 is bound to adapter0 and frontend1 is bound
> to adapter 1
> 
> This would seem like a classical case of having 2 independent
> adapters. But let's analyze it a bit more deeply. The two adapters A0
> and A1 are on the same physical A (adapter) chip and can send you data
> simultaneously on both the devices. Likewise F0 and F1 can be on the
> same physical F (frontend) chip and can send you simultaneous data to
> both A0 and A1.
> 
> Now suppose that you are having F0 and F1 operational: The F chip
> would have a limitation on some parameter, which is based on a
> combination of F0 and F1. If the sum parameter is exceeded on the
> whole F chip, the entire F chip would crash and might need a Reset.
> 
> Likewise the same holds good for the A chip too ..
> 
> Another case is where you have A0, A1 and F0, F1 on the same chip
> while additionally providing F2 and F3 on virtual A0' and A1'.
> 
> But in all cases, the question remains the same. How would the
> application like to handle a situation, when a certain parameter will
> be exceed on the next operation on the next 'Fx' interface ? (If the
> application feels free and does the operation which might cause some
> parameter to exceed, the chip as a whole would not respond, unless
> reset again)
> 
> Operations like this might be common on cards having dual, quad and
> hex frontends. The card itself might be able to stream dual, quad and
> hex simultaneous streams.

Imho limitations or dependencies between different *adapters* are not
acceptable. If a driver maps frontends to different adapters, the driver
pretends that they can be used independent of each other and without
limitations.

If there are limitations, the frontends must be assigned to the same
adapter. Anything else does not make any sense to me.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/


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

Re: [vdr] multiple non-independent frontends (was: Re: [ANNOUNCE] VDR developer version 1.7.11)

[Oliver Endriss]

Klaus Schmidinger wrote:
> On 06.01.2010 14:22, Tomasz Bubel wrote:
> > [...]
> >> - Added support for DVB cards with multiple fontends. Note that this only
> >>  works for DVB cards where each frontend can be used independently of all
> >>  the others on the same adapter.
> > [...]
> > Any chance of using using DVB-T frontend on HVR-4000? This card have 2
> > separate frontends. And as quoted on
> > http://www.linuxtv.org/wiki/index.php/Hauppauge_WinTV-HVR-4000:
> > 
> > "Multiple frontends are supported: DVB-S/S2 and DVB-T appear as
> > /dev/dvb/adapterN/frontend0 and /dev/dvb/adapterN/frontend1
> > respectively.
> > 
> > Due to a hardware limitation, the two frontends cannot be used
> > simultaneously. However they can be used sequentially within the same
> > application. The driver handles the mutual exclusion appropriately."
> 
> Well, that's still a problem.
> Is there a defined way (via the LinuxDVB driver API) through which VDR
> can find out whether the frontends can be used independently?

Afaik DVB API does not specify any way to do that.

For now, I suggest that you simply try to open the frontend.
If this fails, you may assume some kind of ressource limitation...

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/


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

Re: [vdr] DW-TV Hotbird Reception

[Oliver Endriss]

Marco Göbenich wrote:
> Will I get this problem too with any newer version of vdr?

Yes, same problem with VDR 1.7.10.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/


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

Re: [vdr] femon plugin doesn't work "ERROR (femonosd.c, 504): Function not implemented"

[Oliver Endriss]

Hi,

please re-read my message. I was not referring to the osd size stuff,
but to this error message:

| Sep 15 08:37:36 video vdr: [18526] ERROR (femonosd.c,504): Function not 
implemented

femon must not assume that drivers support all ioctls...

CU
Oliver

Theunis Potgieter wrote:
> Why not state the real error which is not enough ram on device X for
> osd? with a hint message like: Require xyz KB, only have 2048KB.
> 
> On 9/15/09, Oliver Endriss  wrote:
> > Rolf Ahrenberg wrote:
> >> > Sep 15 08:37:36 video vdr: [18526] ERROR (femonosd.c,504): Function not
> >> > implemented
> >>
> >> Your DVB driver doesn't provide the FE_READ_UNCORRECTED_BLOCKS ioctl -
> >> it shouldn't be fatal.
> >
> > Hm, wouldn't it be better to display something like 'n/a' in the osd
> > instead of logging an error?

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/


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

Re: [vdr] femon plugin doesn't work "ERROR (femonosd.c, 504): Function not implemented"

[Oliver Endriss]

Rolf Ahrenberg wrote:
> > Sep 15 08:37:36 video vdr: [18526] ERROR (femonosd.c,504): Function not 
> > implemented
> 
> Your DVB driver doesn't provide the FE_READ_UNCORRECTED_BLOCKS ioctl - 
> it shouldn't be fatal.

Hm, wouldn't it be better to display something like 'n/a' in the osd
instead of logging an error?

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/
4 MByte Mod: http://www.escape-edv.de/endriss/dvb-mem-mod/
Full-TS Mod: http://www.escape-edv.de/endriss/dvb-full-ts-mod/


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

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

[Oliver Endriss]

Timothy D. Lenz wrote:
> I just got an updated v4l today because it has fixes for xc5000 based cards 
> as of monday along with new firmware for that card. I
> also use nexus and the first patch below seems to now be included, but the 
> second patch uas a lot of both succeeded and failed:
> 
> patching file linux/drivers/media/dvb/ttpci/av7110.h
> patching file linux/drivers/media/dvb/ttpci/av7110_av.c
> Hunk #2 succeeded at 972 (offset 3 lines).
> Hunk #3 succeeded at 985 (offset 3 lines).
> Hunk #4 succeeded at 1022 (offset 3 lines).
> Hunk #5 succeeded at 1034 (offset 3 lines).
> Hunk #6 succeeded at 1128 (offset 3 lines).
> Hunk #7 succeeded at 1140 (offset 3 lines).
> Hunk #8 FAILED at 1153.
> Hunk #9 succeeded at 1168 (offset 2 lines).
> Hunk #10 succeeded at 1180 (offset 2 lines).
> Hunk #11 succeeded at 1258 (offset -2 lines).
> Hunk #12 succeeded at 1273 with fuzz 2 (offset -2 lines).
> Hunk #13 FAILED at 1321.
> Hunk #14 succeeded at 1347 (offset -2 lines).
> Hunk #15 succeeded at 1357 (offset -2 lines).
> Hunk #16 succeeded at 1371 (offset -2 lines).
> Hunk #17 FAILED at 1469.
> Hunk #18 FAILED at 1480.
> 4 out of 18 hunks FAILED -- saving rejects to file 
> linux/drivers/media/dvb/ttpci/av7110_av.c.rej
> 
> Is it still needed or has it been replaced with another patch?

Please do not apply these patches to current v4ldvb drivers.
They are no longer required. v4ldvb supports TS replay now.

Btw, vdr 1.7.5 is outdated, too.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [vdr] need help with Remote Control Plugin 0.4.0

[Oliver Endriss]

BRUNETON Béranger wrote:
> > Because different telnet clients produce different key codes, it is
> > recommended to go through the normal key learning process.
> > This way you will always have a correct key mapping.
> 
> Sure, but the learning process is not displayed on telnet :(

Correct. Unfortunately, key learning messages are only displayed on the
real OSD. They are not delivered through the cStatus interface. ;-(

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [vdr] need help with Remote Control Plugin 0.4.0

[Oliver Endriss]

BRUNETON Béranger wrote:
> On Tue, May 12, 2009 at 11:17 PM, BRUNETON Béranger  
> wrote:
> > I'm unable to navigate throw the OSD using keyboard in telnet mode.
> > "svdrpsend.pl hitk ..." command display the OSD in the telnet window.
> > I using vdr 1.7.4 and remote-0.4.0  with this option -P'remote -p tcp:'
> 
> 
> It's working now using a proper remote.conf file.

Of course. ;-)

Because different telnet clients produce different key codes, it is
recommended to go through the normal key learning process.
This way you will always have a correct key mapping.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [vdr] PMT in multiple TS packet bug

[Oliver Endriss]

Klaus Schmidinger wrote:
> On 20.01.2009 16:01, Frank Schmirler wrote:
> > On Tue, 20 Jan 2009 14:43:22 +0100, Alexw wrote
> >> I have attached a raw TS capture (~10M) containing the PMT pid 132 
> >> which is revealing the problem.
> > 
> > Hum - PID 132 is a french dolby track, not a PMT PID...
> 
> VDR uses the (fixed) "pseudo" PMT pid 0x0084, which is 132.
> This was taken from some patch that implemented PAT/PMT handling
> (don't remember which one it was, maybe it was even the code from
> reel multimedia - not sure if I've missed mentioning that in the
> CONTRIBUTORS file).
> 
> Anyway, I was already wondering if simply using some fixed PMT
> pid was such a good idea. What if some other stream uses exactly
> that pid? Apparently this is the case in this example.
> 
> So I guess it will be necessary to first collect all pids and then
> check whether the default pseudo PMT pid is still free, and if
> not, incresase it until a free one is found...

Hm - why don't you use the PID of the original PMT?

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [vdr] [v4l-dvb-maintainer] [Wanted] dvb-ttpci maintainer

[Oliver Endriss]

hermann pitton wrote:
> Except of course a majority of plumbers at the same place at the same
> time can create/propose some facts.

IMO decisions must be made where the community is, i.e. on the mailing
list. Not at a conference, no matter whether it is at one end of the
world or on the dark side of the moon. ;-(

To make it absolutely clear: 
I did not leave _because_ S2API was selected.
I left because it was done _this_way_.

Good for those, who are fine with these methods. I am not.

> If you attack people such hard as Manu did, also behind the visible
> lines sometimes, Marcel had a copy from me concerning Mauro and did say
> nothing, you must not wonder about people starting to defend themselves.

I consider flame wars ridiculous. I did not participate, and I will not
participate in the future.

I believe that I know very well what is going on. (During more than 30
years in software development I have seen all kinds of problems. I know
how people react and why things happen.)

> For sure the dirt was not started from v4l people.
>
> Think it over.

Unlikely. I made this decision after sleeping over it for a few days.
Now I feel much better.

Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [vdr] [linux-dvb] [Wanted] dvb-ttpci maintainer

[Oliver Endriss]

Oliver Endriss wrote:
> ...

I would appreciate if people would stop the flame wars - at least
in this thread.

It was not my objective to start another thread which is worth to be
redirected to /dev/null.

Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [vdr] [v4l-dvb-maintainer] [Wanted] dvb-ttpci maintainer

[Oliver Endriss]

hermann pitton wrote:
> 
> Am Mittwoch, den 24.09.2008, 19:22 +0200 schrieb Oliver Endriss:
> > Hi,
> > 
> > due to the way S2API was pushed through (I would call it a plot)
> > there is not much motivation left to spend my time with DVB.
> > 
> > So - if someone wants to take over the dvb-ttpci drivers he should speak
> > up now. The sooner the better.
>
> Oliver,
> 
> you and Manu still stand for dvb with highest respect from _all_ I know
> about.
> 
> And for all I know else, maybe I know nothing, this was for sure not a
> plot.
> 
> Except of course a majority of plumbers at the same place at the same
> time can create/propose some facts.

No. They can discuss/propose anything they like, but 8 people don't have
any right to make decisions. (This is why I call it a plot.)

There are basic democratic rules which must be followed in a community:

(1) Make a proposal
(2) Discuss the proposal
(3) Finally, _after_ the discussion: A poll to find a decision.

> ...
> Think it over.

Well, I had enough time to think about it...

Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [vdr] [linux-dvb] [Wanted] dvb-ttpci maintainer

[Oliver Endriss]

Goga777 wrote:
> Oliver Endriss wrote:
> > So - if someone wants to take over the dvb-ttpci drivers he should speak
> > up now. The sooner the better.
> 
> ah, it's very pity :(
> 
> will you stay with VDR project ?

Sure.

Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

[vdr] [Wanted] dvb-ttpci maintainer

[Oliver Endriss]

Hi,

due to the way S2API was pushed through (I would call it a plot)
there is not much motivation left to spend my time with DVB.

So - if someone wants to take over the dvb-ttpci drivers he should speak
up now. The sooner the better.

Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [vdr] VDR Development

[Oliver Endriss]

Georg Acher wrote:
> I also don't think that a vdr-repository would help in the development
> speed. Either the whole development procedure needs to be changed (more
> maintainer with KLS's approval) or it has no advantage compared to the
> .tgz-distribution.
> 
> But I think the repository stuff is only marginal. The design itself
> matters. When looking at the experiences at Reel, there are some things to
> be considered in the (far) future of vdr 2.0:
> 
> - vdr has grown/evolved since 2000, but is still based in its design on the FF
> card and its capabilities. There are now different signal source setups
> (LNBs, rotor, multiproto, mixed tuners or shared tuners/CAMs like in the
> NetCeiver, and not forgetting the IPTV variants), various output types and
> devices (FF, DXR3, HDE, X11, ...) and especially more expectations what a
> PC-based STB should be able to do (playback of other media, "home
> automatisation", etc.).
> 
> - It allows no real server/client distinction. It is quite common to have a
> real file server somewhere in the house, but it's hard to get a vdr running
> on it and viewing on other clients. Even the recordings sharing of two vdrs
> is not that easy (touch update here and there...). One of the main
> advantages of Unix was resource sharing and distribution in heterogenous
> networks (like X over network), but vdr is currently focused only on "its"
> platform.
> 
> - The current plugin concept allows only a very limited access or
> modfications in the core behaviour. At least without core patches...
> 
> - Based on the long evolution history, vdr IMO also has some design
> problems. Every object interacts with each other, I'm personally lost in the
> inheritance-graph of dozens of identically named
> Get/Put/Add/Del/Action/Process-calls. Also the main loop (almost 1500LOC) is
> a bit fat ;-) This makes it hard for newcomers and potential contributors. I
> guess that there are only very few people that actually know what is going
> on in the device/devbdevice/remux/libsi-core.
> 
> I still favour vdr over mythTV or MCE, because their neglect the TV side.
> But we have to face it: Radio is dying already. Old fashioned TV over
> antenna is also getting more and more unimportant and is merged with other
> data sources (IPTV, internet radio, podcasts, ...). Full convergence is no
> "if", it's a "when".
> 
> So, the main discussion topic should be: What is needed for a future-proof
> design? It is not about XML or SQL or other hype buzzwords, it's about the
> overall design and how individual modules/plugins interact with each other.
> 
> Just my EUR0.01...

Indeed this would be a very interesting discussion.

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [vdr] VDR Development

[Oliver Endriss]

Guys, I can't stand this blabla any longer.

Klaus stated clearly how he wants to do VDR development, and he has the
right to do it his way! No matter whether you like it or not!

My suggestion for those who are unhappy with the current situation:
0. Stop this discussion.
1. Read the GPL.
2. Understand the GPL.
2. Clone the existing VDR code.
3. Give it a new name to make clear, that it is not VDR.
4. Make it better (if you can).
5. Last but not least: Maintain it for 8 years or longer.

Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [vdr] [linux-dvb] DVB-S2 / Multiproto and future modulation support

[Oliver Endriss]

Steven Toth wrote:
> Regarding the multiproto situation:
> 
> A number of developers, maintainers and users are unhappy with the
> multiproto situation, actually they've been unhappy for a considerable
> amount of time. The linuxtv developer community (to some degree) is seen
> as a joke and a bunch in-fighting people. Multiproto is a great
> demonstration of this. [1] The multiproto project has gone too far, for
> too long and no longer has any credibility in the eyes of many people.
> 
> In response, a number developers have agreed that "enough is enough" and
> "it's time to take a new direction", for these developers the technical,
> political and personal cost of multiproto is too high. These developers
> have decided to make an announcement.
> 
> Mauro Chehab, Michael Krufky, Patrick Boettcher and myself are hereby
> announcing that we no longer support multiproto and are forming a
> smaller dedicated project group which is focusing on adding next
> generation S2/ISDB-T/DVB-H/DVB-T2/DVB-SH support to the kernel through a 
> different and simpler API.
>
> Basic patches and demo code for this API is currently available here.
> 
> http://www.steventoth.net/linux/s2
> 
> Does it even work? Yes
> Is this new API complete? No
> Is it perfect? No, we've already had feedback on structural and
> namingspace changes that people would like to see.
> Does it have bugs? Of course, we have a list of things we already know
> we want to fix.
> 
> but ...
> 
> Is the new approach flexible? Yes, we're moving away from passing fixed
> modulation structures into the kernel.
> Can we add to it without breaking the future ABI when unforseen
> modulations types occur? Yes
> Does it preserve backwards compatibility? Yes
> Importantly, is the overall direction correct? Yes
> Does it impact existing frontend drivers? No.
> What's the impact to dvb-core? Small.
> What's the impact to application developers? None, unless an application 
> developer wants to support the new standards - binary compatibility!
> 
> We want feedback and we want progress, we aim to achieve it.
> 
> Importantly, this project group seeks your support.
> 
> If you also feel frustrated by the multiproto situation and agree in
> principle with this new approach, and the overall direction of the API
> changes, then we welcome you and ask you to help us.
> 
> Growing the list of supporting names by 100%, and allowing us to publish
> your name on the public mailing list, would show the non-maintainer
> development community that we recognize the problem and we're taking
> steps to correct the problem. We want to make LinuxTV a perfect platform
> for S2, ISDB-T and other advanced modulation types, without using the
> multiproto patches.
> 
> We're not asking you for technical help, although we'd like that  :) ,
> we're just asking for your encouragement to move away from multiproto.
> 
> If you feel that you want to support our movement then please help us by
> acking this email.
> 
> Regards - Steve, Mike, Patrick and Mauro.
> 
> Acked-by: Patrick Boettcher <[EMAIL PROTECTED]>
> Acked-by: Michael Krufky <[EMAIL PROTECTED]>
> Acked-by: Steven Toth <[EMAIL PROTECTED]>
> Acked-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]>
> 
> * [1]. Rather than point out the issues with multiproto here, take a
> look at the patches and/or read the comments on the mailing lists.

Guys, I don't like the way you do this. ;-(

Why didn't you propose this API when we reviewed multiproto?
Meanwhile there are applications (vdr, others?) which implement the
multiproto API.

As I am not willing to spend a single minute of my time with API wars,
I will ack this API only if the multiproto developer and the users agree
with this approach.

Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/


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

Re: [vdr] [linux-dvb] Possible SMP problems with budget_av/saa7134

[Oliver Endriss]

Matthias Dahl wrote:
> Hello all.
> 
> I am resending the following message because I didn't get any response so far 
> and in addition I am putting it on cc' to the vdr devel list. I'd look into 
> this issue myself, yet I don't have the necessary time to dive into the DVB 
> tree. So please, if anyone knows how to debug this or has any hint where the 
> problem could be located... I'd be more than grateful to hear about it.
> 
> By the way, just today after a few minutes of uptime with vdr 1.7.0, I got 
> those (increased the CAM check interval to 5 seconds btw):
> 
> vdr: [3280] ERROR: can't write to CI adapter on device 0: Input/output error
> vdr: [3280] ERROR: can't write to CI adapter on device 0: Invalid argument
> 
> And the CAM stopped working until I restarted vdr. In one forum post someone 
> reported about similar problems with MythTV, so it's becoming more and more 
> likely that this is indeed a problem within the dvb tree. And if it's a SMP 
> problem, it should get fixed because multicore systems will be everywhere 
> pretty soon.
> 
> Thanks again.
> 
> --
> 
> Hello all.
> 
> After minutes or hours or days of running vdr 1.4.7, I get the following 
> messages in my syslog: 
> 
>dvb_ca adapter 0: CAM tried to send a buffer larger than the ecount size!
>dvb_ca adapter 0: DVB CAM link initialisation failed :(
> 
> When running vdr 1.6.x, the problems are even more frequent/worse and I get
> those:
> 
>   dvb_ca adapter 0: CAM tried to send a buffer larger than the link buffer
>   size (192 > 128)!
>   vdr: [3140] ERROR: can't write to CI adapter on device 0: Input/output error
>   dvb_ca adapter 0: CAM tried to send a buffer larger than the ecount size!
>   dvb_ca adapter 0: DVB CAM link initialisation failed :(
> 
> The result is always the same, the CAM stops decrypting and I have to restart 
> vdr. After a lot of searching around, I've learnt that I am not the only one 
> with those problems and they seem to be related to multi core systems. I read 
> that pining vdr down to one CPU core might help... and indeed it did.
> 
> This cannot be a hardware related issue because...
> 
>  1) meanwhile I switched from a NForce 590 SLI to a X48 chipset and thus also
> from an AMD64 X2 5600+ (Winchester) to an Intel Core2Duo E8400 (Wolfdale)
> 
>  2) I swapped my KNC One DVB-C Plus for a new one
> 
> And the problems persist.
> 
> I've already written a report to the vdr list which was unfortunately ignored 
> and besides it looks more like a dvb issue itself.
> 
> I was unable to test the kernel with nosmp or similar (which was reported by 
> others to work just fine) because I need this machine to work on.
> 
> I've attached detailed informations about my system and I'd be more than 
> happy 
> to help fix this once and for all, so one can savely rely on vdr again.
> 
> Last but not least, I am using a AlphaCrypt Light module with 3.15 firmware.
> 
> Thanks a lot in advance for every help.
> 
> Best regards,
> Matthias Dahl

Please test the attached patch (untested because I do not own this kind
of hardware). Please save your work before loading the patched driver,
since a locking bug might crash your machine...

CU
Oliver

-- 

VDR Remote Plugin 0.4.0: http://www.escape-edv.de/endriss/vdr/

diff -r cbfa05ad2711 linux/drivers/media/dvb/ttpci/budget-av.c
--- a/linux/drivers/media/dvb/ttpci/budget-av.c	Fri Aug 01 08:23:41 2008 -0300
+++ b/linux/drivers/media/dvb/ttpci/budget-av.c	Sat Aug 16 06:21:58 2008 +0200
@@ -65,6 +65,7 @@ struct budget_av {
 	struct tasklet_struct ciintf_irq_tasklet;
 	int slot_status;
 	struct dvb_ca_en50221 ca;
+	struct mutex camlock;
 	u8 reinitialise_demod:1;
 };
 
@@ -136,6 +137,8 @@ static int ciintf_read_attribute_mem(str
 	if (slot != 0)
 		return -EINVAL;
 
+	mutex_lock(&budget_av->camlock);
+
 	saa7146_setgpio(budget_av->budget.dev, 1, SAA7146_GPIO_OUTHI);
 	udelay(1);
 
@@ -144,6 +147,9 @@ static int ciintf_read_attribute_mem(str
 		ciintf_slot_shutdown(ca, slot);
 		printk(KERN_INFO "budget-av: cam ejected 1\n");
 	}
+
+	mutex_unlock(&budget_av->camlock);
+
 	return result;
 }
 
@@ -155,6 +161,8 @@ static int ciintf_write_attribute_mem(st
 	if (slot != 0)
 		return -EINVAL;
 
+	mutex_lock(&budget_av->camlock);
+
 	saa7146_setgpio(budget_av->budget.dev, 1, SAA7146_GPIO_OUTHI);
 	udelay(1);
 
@@ -163,6 +171,9 @@ static int ciintf_write_attribute_mem(st
 		ciintf_slot_shutdown(ca, slot);
 		printk(KERN_INFO "budget-av: cam ejected 2\n");
 	}
+
+	mutex_unlock(&budget_av->camlock);
+
 	return result;
 }
 
@@ -174,6 +185,8 @@ static int ciintf_read_cam_control(struc
 	if (slot != 0)
 		return -EINVAL;
 
+	mutex_lock(&budget_av->camlock);
+
 	saa7146_setgpio(budget_av->budget.dev, 1, SAA7146_GPIO_OUTLO);
 	udelay(1);
 
@@ -181,8 +194,10 @@ static int ciin

[vdr] [ANNOUNCE] Remote Control Plugin 0.4.0

[Oliver Endriss]

Hi,

there is an update for the remote control plugin.


History:

2007-10-06: Version 0.4.0
- Implemented gettext support for VDR >= 1.5.7,
  i18n is still used for older vdr releases.
- If supported by udev, an input device can be selected by pci slot now.
  For example:
vdr -P"remote -i /dev/input/by-path/pci-:02:06.0--event-ir"
  (Thanks to Joachim Selinger for suggesting to add this feature.)


It can be downloaded from 
    http://www.escape-edv.de/endriss/vdr/

See README for details.


Short description:
--
This plugin extends the remote control capabilities of vdr.
The following remote control devices are supported:

(a) linux input device driver ('/dev/input/eventX', X=0,1,2,...)
- built-in remote control port of the av711x-based DVB cards
  (aka full-featured cards), e.g. DVB-S Nexus [1]
- remote control port of some budget cards, e.g. Nova-CI [2]
- other input devices (not tested, please report success!)
See file FAQ for a list of cards which have been reported to work.

(b) keyboard (tty driver): /dev/console, /dev/ttyX

(c) TCP connection (telnet)

(d) LIRC


Summary of command line options:

-i dev,   --input=dev   select device which supports the /dev/input protocol
-l dev,   --lirc=devselect LIRC device
-t dev,   --tty=dev select terminal device
-T dev,   --TTY=dev select terminal device with 'OSD'
-p tcp:n, --port=tcp:n  select connection on tcp port 


Examples:
-
vdr -Premote
vdr -P"remote -i autodetect"
Try to autodetect device '/dev/input/eventX' (X = 0,1,2,...).
If no device can be identified, '-i /dev/input/ir' is used.

vdr -P"remote -i /dev/input/event2"
use specified input device '/dev/input/event2'

vdr -P"remote -i /dev/input/by-path/pci-:02:06.0--event-ir"
select input device by pci slot (udev support required)

vdr -P"remote -l /dev/lircd"
select LIRC remote control

vdr -P"remote -p tcp:"
wait for a telnet connection on tcp port 
(use 'telnet vdr ' to access this port)

vdr -P"remote -t /dev/tty10"
use terminal device without 'OSD'

vdr -P"remote -T /dev/tty10"
use terminal device with 'OSD'

vdr -P"remote -i autodetect -p tcp: -t /dev/tty10"
use multiple devices


Have fun,

Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/


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

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

[Oliver Endriss]

Klaus Schmidinger wrote:
> - Added the "...or (at your option) any later version" phrase to the license
>   information of all plugins, and also the 'newplugin' script (suggested by
>   Ville Skyttä). Plugin authors may want to consider doing the same.

Hm - are you sure that it is a good idea to accept a license if you did
not have a chance to read it?
That's like signing a contract without reading it...

CU
Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [vdr] setting tv standard in /dev/video0

[Oliver Endriss]

Stone wrote:
> >
> >
> > Basically there are two ways to select NTSC mode:
> > - v4lctl setnorm NTSC
> > - module parameter 'tv_standard' for dvb-ttpci
> >
> > modinfo dvb-ttpci:
> > ...
> > parmtype:   tv_standard:int
> > parm:   tv_standard:TV standard: 0 PAL (default), 1 NTSC
> > ...
> 
> 
> When tv_standard=1 is used, why does VDR still startup with these PAL
> resolutions:
> 
> vdr: [7841] starting plugin: screenshot
> vdr: [7841] grabbing to PNM 100 768 576
> vdr: [7841] grabbed image to /dev/null
> 
> And after I run VLC, I get these new resolutions:
> 
> vdr: [7841] connect from 127.0.0.1, port 49972 - accepted
> vdr: [7841] grabbing to JPEG 70 384 288
> 
> Can I hardcode the default resolution from within VDR or the kernel driver?
> Best Regards.

Does it work if you use the v4lctl method?

Are there any FTA NTSC transmissions on Astra 19.2°
or Eutelsat 13°? I'd like to do some tests...

Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [vdr] setting tv standard in /dev/video0

[Oliver Endriss]

Stone wrote:
> Hi,
> 
> I am currently using VDR with a Nexus-S FF card in an NTSC environment. For
> a long time, I could never get the correct tv standard (NTSC) while trying
> to watch television via VDRAdmin. I recently noticed that once I stream VDR
> using VLC and its v4l interface, something in /dev/video0 gets set to NTSC,
> because from then on, the video is correctly set to NTSC mode and I can
> watch television via the VDRAdmin television interface.

Basically there are two ways to select NTSC mode:
- v4lctl setnorm NTSC
- module parameter 'tv_standard' for dvb-ttpci

modinfo dvb-ttpci:
...
parmtype:   tv_standard:int
parm:   tv_standard:TV standard: 0 PAL (default), 1 NTSC
...

Oliver

-- 

VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/



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

Re: [vdr] How to change Pro7 SAT1 Channels via Menu

[Oliver Endriss]

Helmut Auer wrote:
> Hello List,
> 
> What is the preferred way to change the settings of the channels Pro7 ... ?
> I have a lot of  users which do not have a pc to take the easy way 
> (shutting down vdr and editing channels.conf)

That's the hard way. ;-)

> Yesterday I had a phone call with one of these and changing the channel 
> settings via the menu is horrible, because after changing the channel 
> some minutes later vdr replaces the channel with the old settings.
> Looks like he has to turn the automagic channel update off for doing this ?
> Now the next persons have the same problem and I don't like to spent 
> more time on the phone then necessary ;)

Basically it's very easy:

0. Set 'Update channels' to 'add new transponder'.
   Wait until vdr has added the new channels (EPG scan).

1. Enter Channels menu:
- Move cursor to 'ProSieben'
- Press '0' until channels are sorted alphabetically.
- Move cursor to the new 'ProSieben' channel.
- Press  (mark).
- Either enter new channel number directly and press ,
  or use / to select the channel which should be replaced
  (i.e. old ProSieben) and press .

2. Update timers in the Timer Menu to use the new channel.

3. Finally delete old channels (Channels menu).
   Note: It is very convenient that vdr issues a warning,
 if there is a timer for the channel to be deleted.

Oliver

-- 

VDR Remote Plugin 0.3.9 available at
http://www.escape-edv.de/endriss/vdr/


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

Re: [vdr] FF card AV sync problems, possible fix to VDR

[Oliver Endriss]

Ville Rannikko wrote:
> Hi!
> 
> The newest firmware for FF cards did not completely fix the AV desync 
> problems 
> for me.

Can you provide a sample recording where A/V sync fails with the current
firmware?

> According to information from Werner the problem happens when small  
> video frames fill the decoder buffer with over 2 seconds of data. So I made  
> this patch for dvbplayer.c to stop it from uploading more PES frames to 
> decoder 
> when STC/PTS difference is more than 2 seconds. This seems to fix the 
> remaining 
> problems for me, but I have not tested it much. The PTS/STC-code has been 
> mostly taken from the dvb-subtitles plugin. Comments, please

The driver accepts as much data as the driver buffers can hold:
- max. 192 KByte video
- max.  64 KByte audio

The firmware requests data from the driver. The driver does not push
data to the firmware without request from the firmware.

Until now I do not understand how there could be any over/underflows
during normal operation.

> --- dvbplayer.c.orig  2007-01-31 18:21:42.0 +0200
> +++ dvbplayer.c   2007-01-31 18:35:36.0 +0200
> @@ -495,6 +495,51 @@
>}
> }
> if (p) {
> + if(playMode == pmPlay && pc > 13)
> +   {
> + int64_t stc = -1;
> + int64_t pts = -1;
> +
> + if ( p[0] == 0x00 && p[1] == 0x00 && p[2] == 0x01)
> +   {
> + if(p[7] & 0x80)
> +   {
> + switch( p[3] )
> +   {
> +   case 0xE0 ... 0xEF: // video
> +   case 0xC0 ... 0xDF: // audio
> + pts  = (int64_t) (p[ 9] & 0x0E) << 29 ;
> + pts |= (int64_t)  p[ 10] << 22 ;
> + pts |= (int64_t) (p[ 11] & 0xFE) << 14 ;
> + pts |= (int64_t)  p[ 12] <<  7 ;
> + pts |= (int64_t) (p[ 13] & 0xFE) >>  1 ;
> +   }
> +   }
> +   }
> + if(pts != -1)
> +   {
> + cDevice *pd = cDevice::PrimaryDevice();
> + if(pd)
> +   {
> + stc = pd->GetSTC();
> + if(stc != 0)
> +   {
> + if(pts & (int64_t)1<<32)
> +   {
> + stc |= (int64_t)1<<32;
> +   }
> + int64_t timeDiff = (pts-stc);
> + if (pts +   {
> + timeDiff += (int64_t)1<<33;
> +   }
> + timeDiff /= 90;
> + if(timeDiff > 2000)
> +cCondWait::SleepMs(timeDiff - 2000);
> +   }
> +}
> +}
> +}
> int w = PlayPes(p, pc, playMode != pmPlay);
> if (w > 0) {
>p += w;

Hm, that patch does not look like a real bug fix to me. ;-)
It is a workaround which limits the total buffer capacity to max 2s.
I guess this works because it somehow triggers a resync in the firmware.

Anyway, fixes must be applied to the firmware or driver, not to VDR.

But let's analyse the problem first. We need a sample recording...

Oliver

-- 

VDR Remote Plugin 0.3.9 available at
http://www.escape-edv.de/endriss/vdr/



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

Re: [vdr] FF card AV sync problems, possible fix to VDR

[Oliver Endriss]

Klaus Schmidinger wrote:
> VDR User wrote:
> > On 1/31/07, *Klaus Schmidinger* <[EMAIL PROTECTED]
> > > wrote:
> > 
> > VDR User wrote:
> > > From what he's saying, the problem is buffer overrun's, not
> > underrun's.

Afaics this is just a guess. We need a sample recording and track down
what happens in the driver/firmware.

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

Code from the driver:
|...
|if (nonblock && !FREE_COND)
|return -EWOULDBLOCK;
|
|while (todo > 0) {
|if (!FREE_COND) {
|if (nonblock)
|return count - todo;
|if (wait_event_interruptible(av7110->avout.queue,
| FREE_COND))
|return count - todo;
|}
| ...

Looks ok to me. The driver does not accept more data than it can handle.

> > I disagree.  Simply returning from write() implies the data was written
> > and the device is ready for more.
> 
> The write() function returns the number of bytes actually written,
> which is not necessarily the same as the number of bytes the caller
> wanted to write. So the device can chose not to accept all of the data.
> If the device is currently unable to accept any data (and the file handle
> is in O_NONBLOCK mode) it shall return EAGAIN to inform the caller that
> it is currently busy and that the caller should try again later.
> 
> >  If this is not true then you risk
> > making the sync even worse.  I consulted with people familiar with this
> > type of stuff and it was suggested the problem could (and should) be
> > fixed at the driver level so I'm following up on that now.
> 
> Well, that's exactly what I was suggesting. The write() function has
> everything it takes to block data from coming into the device if its
> buffer is full. No need for the caller to do any funny estimates here.

Fullack. There is no reason to add workarounds like this to VDR.

@all:
Don't panic. Provide samples. :-)

Oliver

-- 

VDR Remote Plugin 0.3.9 available at
http://www.escape-edv.de/endriss/vdr/



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

Re: [vdr] FF card A/V sync - in progress?

[Oliver Endriss]

Oliver Endriss wrote:
> Marco Skambraks wrote:
> > hi,
> > 
> > are there any new information about the FF a/v sync problem?
> > is the firmware development still in progress?
> 
> Sorry, no success yet.

Werner fixed the A/V sync problem. Please test firmware f12623.
See http://www.vdr-portal.de/board/thread.php?postid=566692#post566692

Oliver

-- 

VDR Remote Plugin 0.3.9 available at
http://www.escape-edv.de/endriss/vdr/



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

Re: [vdr] Problem with aspect ratio after update

[Oliver Endriss]

Matthias Fechner wrote:
> Hi,
> 
> I updated these days my system from kernel 2.6.15.4 to 2.6.19 and now
> every movie on every program is now in 16:9 even the movies which had
> been 4:3 before.
> 
> Is there something broken in the driver from the kernel or is it a
> problem with the firmware or VDR?
> 
> I have VDR 1.4.4 running and 2xFF card (DVB-S).

Which firmware revision are you using? If you are running a xx2623 test
version you should update to the latest one (F22623).

Oliver

-- 

VDR Remote Plugin 0.3.9 available at
http://www.escape-edv.de/endriss/vdr/



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

Re: [vdr] [ANNOUNCE] VDR maintenance patch 1.4.4-1

[Oliver Endriss]

Klaus Schmidinger wrote:
> - Replaced 'unsigned long long' with 'uint32_t' and 'uint64' with 'uint64_t' 
> to
>avoid problems on 64-bit machines.

Should read:
> - Replaced 'unsigned long' with 'uint32_t' and ...

Oliver

-- 

VDR Remote Plugin 0.3.9 available at
http://www.escape-edv.de/endriss/vdr/



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

[vdr] [ANNOUNCE] Remote Control Plugin 0.3.9

[Oliver Endriss]

Hi,

there is an update for the remote control plugin.


History:

2006-12-03: Version 0.3.9
- Added Russian language texts (thanks to Waldemar Nikel).
- Replaced uint64 by uint64_t for APIVERSION >= 1.4.5.


It can be downloaded from 
    http://www.escape-edv.de/endriss/vdr/

See README for details.


Short description:
--
This plugin extends the remote control capabilities of vdr.
The following remote control devices are supported:

(a) linux input device driver ('/dev/input/eventX', X=0,1,2,...)
    - built-in remote control port of the av711x-based DVB cards
      (aka full-featured cards), e.g. DVB-S Nexus [1]
    - remote control port of some budget cards, e.g. Nova-CI [2]
    - other input devices (not tested, please report success!)
    See file FAQ for a list of cards which have been reported to work.

(b) keyboard (tty driver): /dev/console, /dev/ttyX

(c) TCP connection (telnet)

(d) LIRC

Notes:
[1] supported by DVB and dvb-kernel
[2] supported by dvb-kernel only


Summary of command line options:

-i dev,   --input=dev   select device which supports the /dev/input protocol
-l dev,   --lirc=dev    select LIRC device
-t dev,   --tty=dev     select terminal device
-T dev,   --TTY=dev     select terminal device with 'OSD'
-p tcp:n, --port=tcp:n  select connection on tcp port 


Examples:
-
vdr -Premote
vdr -P"remote -i autodetect"
    Try to autodetect device '/dev/input/eventX' (X = 0,1,2,...).
    If no device can be identified, '-i /dev/input/event0' is used.

vdr -P"remote -i /dev/input/event2"
    use specified input device '/dev/input/event2'

vdr -P"remote -l /dev/lircd"
    select LIRC remote control

vdr -P"remote -p tcp:"
    wait for a telnet connection on tcp port 
    (use 'telnet vdr ' to access this port)

vdr -P"remote -t /dev/tty10"
    use terminal device without 'OSD'

vdr -P"remote -T /dev/tty10"
    use terminal device with 'OSD'

vdr -P"remote -i autodetect -p tcp: -t /dev/tty10"
    use multiple devices


Have fun,

Oliver

-- 

VDR Remote Plugin 0.3.9 available at
http://www.escape-edv.de/endriss/vdr/



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

Re: [vdr] FF card A/V sync - in progress?

[Oliver Endriss]

Carsten Koch wrote:
> Maybe VDR is behaving according to the specified interface
> and the firmware fails.
> Maybe mplayer is working around firmware bugs by behaving
> differently - which may or may not be according to the
> specified interface.
> 
> What we can agree upon is the fact that the problem *can* be
> solved within the application program.
> IMHO, the fact that mplayer works where VDR does not
> proves just that, but not more.
> 
> However, if VDR behaves 100% according to specification,
> the problem *should* be solved in the driver and/or
> firmware, because that would fix all programs that also
> behave 100% according to specification and fail.
> 
> If fixing it where it should be fixed turns out to be
> too difficult, it might still be a good idea to fix it
> in VDR.

Has anyone been able to identify the differences in the MPEG data if
(a) mplayer
(b) vdr
play the sample stream?

Imho that's the key to the problem.

Oliver

-- 

VDR Remote Plugin 0.3.8 available at
http://www.escape-edv.de/endriss/vdr/



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

Re: [vdr] FF card A/V sync - in progress?

[Oliver Endriss]

VDR User wrote:
> Can you confirm that the firmware abides fully to specification?

I'm pretty sure that it doesn't. Neither do mplayer, vdr and the DVB
driver. All complex programs have bugs... ;-)

CU
Oliver

-- 

VDR Remote Plugin 0.3.8 available at
http://www.escape-edv.de/endriss/vdr/



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

Re: [vdr] FF card A/V sync - in progress?

[Oliver Endriss]

Marco Skambraks wrote:
> hi,
> 
> are there any new information about the FF a/v sync problem?
> is the firmware development still in progress?

Sorry, no success yet.

Oliver

-- 

VDR Remote Plugin 0.3.8 available at
http://www.escape-edv.de/endriss/vdr/



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

Re: [vdr] FF card A/V sync suggestion

[Oliver Endriss]

Klaus Schmidinger wrote:
> Udo Richter wrote:
> > Klaus Schmidinger wrote:
> >> Morfsta wrote:
> >>> I second that, please don't let it drop again.. Is anyone actually 
> >>> working on this, Klaus, Oliver, ANYONE?
> >>
> >> I'm not working on this, because ATM I wouldn't know what to do.
> > 
> > Any comments on C.Y.M's point that PCR should be recorded/used?
> > -> http://www.linuxtv.org/pipermail/vdr/2006-October/011061.html
> > 
> > As far as I understand this, VDR ignores the TS-layer PCR timing data 
> > (which, as far as I understand this, controls the raw data rate fed to 
> > the decoders) and the syncing is done by DVB driver/firmware based on 
> > the timing information in the underlying PES headers. Since the DVB 
> > playback also works on PES layer and accepts data on all-you-can-eat 
> > base, I'm not sure whether feeding the DVB device on PCR based data 
> > rates would help, or how PCR should be forwarded to the DVB hardware.
> 
> I'm afraid my knowledge here is too limited.
> If somebody can come up with an idea of how additional timing information
> should be inserted in the PES data, let's hear it.

Imho there is no need to add anything to the PES data format.

In live mode PCR is required to synchronize the internal clock of the
decoder to the master clock of the transmitter.

In replay mode the clock of the decoder is running free, i.e. it is the
master clock. No need for a PCR or something like that.

> Generally I don't think that VDR should have to to anything regarding
> A/V sync during replay. It simply feeds the data to the device as fast
> as the device can take it, and syncing audio and video is the device's
> job. Maybe mplayer just generates additional PES headers for this?

Does mplayer really play PES data 'as is'?
Afaik it recodes data to MPEG-1.(?)

Afaics it is a firmware/driver problem. It should be fixed there.
Werner is currently working on a modified A/V sync code.
We will see whether is improves things. Please be patient.

Oliver

-- 

VDR Remote Plugin 0.3.8 available at
http://www.escape-edv.de/endriss/vdr/



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

Re: [vdr] FF card A/V sync suggestion

[Oliver Endriss]

Udo Richter wrote:
> Tero Siironen wrote:
> > However, like Pasi Juppo told earlier in other thread, in last weeks episode
> > of Lost there was many fadeout-fadeins between scenes and a/v desync
> > happened on every one of these.
> 
> I've 'heard of such problems' on ATV+ and Lost. Whenever there's a fade 
> into black, the data stream seems to get stuck, frames get delayed, and 
> as consequence A/V desyncs and playback gets jerky, with lots of audio 
> and video frame drops. This can be fixed by pausing and jumping a few 
> frames backwards.
> 
> My theory is that since audio is typically 600ms ahead of video, maybe 
> the audio buffers run over. Strange thing is why this happens 
> reproducible on blackness. Maybe due to extremely low bit rate in this 
> situation, more frames get packed into one data block, causing data flow 
> to be disturbed beyond some limit. It cant be too high data rate, ATV+ 
> has just 2mbit avg, 4mbit max data rate.

Does it also occur with the latest test firmware?
  http://www.suse.de/~werner/test_av-f22623.tar.bz2

If yes, please provide short sample clips.
Please verify that the clips are not damaged, i.e. they play fine with
mplayer or xine.

Oliver

-- 

VDR Remote Plugin 0.3.8 available at
http://www.escape-edv.de/endriss/vdr/



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

Re: [vdr] multiple keypresses with remote plugin

[Oliver Endriss]

Torgeir Veimo wrote:
> 
> On 21 Sep 2006, at 09:03, Marko Mäkelä wrote:
> 
> > On Sun, Sep 17, 2006 at 11:43:09AM +0100, Torgeir Veimo wrote:
> >> Using the remote plugin with a /dev/input/eventX setup for a
> >> hauppauge grey remote via a nova-t sensor with X11/Xv using
> >> softdevice works perfectly. With the same setup with directfb single
> >> button presses very often are detected as multiple button presses.
> >
> > I don't remember seeing a reply to this.  What does "evtest" report
> > when you press a button?
> 
> It appears to be correct, it's just too fast, see below

Please post the output of evtest for
- a single (short) keypress 
- a long keypress

Oliver

-- 

VDR Remote Plugin 0.3.8 available at
http://www.escape-edv.de/endriss/vdr/



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

[vdr] [ANNOUNCE] Remote Control Plugin 0.3.8

[Oliver Endriss]

Hi,

there is a minor update for the remote control plugin.


History:

2006-09-02: Version 0.3.8
- cRemoteDevInput: Ignore all event types except type 1 (key).
- Added Italian language texts (thanks to Nicola Franchi).
- Added Polish language texts (thanks to Jakub Wolnicki).
- Fixed cTtyStatus::SetVolume() for API version 1.4.2.

It can be downloaded from 
    http://www.escape-edv.de/endriss/vdr/

See README for details.


Short description:
--
This plugin extends the remote control capabilities of vdr.
The following remote control devices are supported:

(a) linux input device driver ('/dev/input/eventX', X=0,1,2,...)
    - built-in remote control port of the av711x-based DVB cards
      (aka full-featured cards), e.g. DVB-S Nexus [1]
    - remote control port of some budget cards, e.g. Nova-CI [2]
    - other input devices (not tested, please report success!)
    See file FAQ for a list of cards which have been reported to work.

(b) keyboard (tty driver): /dev/console, /dev/ttyX

(c) TCP connection (telnet)

(d) LIRC

Notes:
[1] supported by DVB and dvb-kernel
[2] supported by dvb-kernel only


Summary of command line options:

-i dev,   --input=dev   select device which supports the /dev/input protocol
-l dev,   --lirc=dev    select LIRC device
-t dev,   --tty=dev     select terminal device
-T dev,   --TTY=dev     select terminal device with 'OSD'
-p tcp:n, --port=tcp:n  select connection on tcp port 


Examples:
-
vdr -Premote
vdr -P"remote -i autodetect"
    Try to autodetect device '/dev/input/eventX' (X = 0,1,2,...).
    If no device can be identified, '-i /dev/input/event0' is used.

vdr -P"remote -i /dev/input/event2"
    use specified input device '/dev/input/event2'

vdr -P"remote -l /dev/lircd"
    select LIRC remote control

vdr -P"remote -p tcp:"
    wait for a telnet connection on tcp port 
    (use 'telnet vdr ' to access this port)

vdr -P"remote -t /dev/tty10"
    use terminal device without 'OSD'

vdr -P"remote -T /dev/tty10"
    use terminal device with 'OSD'

vdr -P"remote -i autodetect -p tcp: -t /dev/tty10"
    use multiple devices


Have fun,

Oliver

-- 

VDR Remote Plugin available at
http://www.escape-edv.de/endriss/vdr/



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