headers
Oliver Schinagl | 1 Apr 2011 09:42
Picon
Favicon
Gravatar

Re: [Patch] Make RGYB buttons customizeable

Ah, I use a lirc based remote and don't learn anything. I've just told
VDR, that my VDR_RED is LIRC_RED etc, so when I press the red button,
the action that is bound to VDR_RED is executed, regardless of the
location of the button. This patch only changes the OSD location of the
button, to match the location on the remote.

On 03/31/11 15:40, Rainer Blickle wrote:
> 2011/3/30 Steffen Barszus <steffenbpunkt <at> googlemail.com>:
>> 2011/3/30 Oliver Schinagl <oliver <at> schinagl.nl>:
>>> I belive that is exactly only what this patch does, it changes the
>>> positions on the screen for the ST-NG theme I think (it's been a while I
>>> admit).
>>>
>>> So if VDR is told that the red button performs the job of the red
>>> button, then everything is ok.
>>>
>>> To recap, the problem I had with VDR that caused me to write this patch,
>>> was:
>>>
>>> My Remote control had 2 buttons different from where VDR expected the
>>> buttons to be. E.g. VDR wants Red Yellow Green Blue, but my remote
>>> control was Red Yellow Blue Green.
> My remote has the color order Yellow, Red, Blue, Green (only an
> example, i dont have the remote at hand). Lets say the buttons are
> Button0, Button1, Button2, Button3
>
> When learning, vdr wants the keys Red,Yellow, Green, Blue to get pressed.
>
> In the vdr layout Button0 is Red, Button1 is Yellow and so on ...
> while watching a recording vdr jumps 1 minute in the past when
(Continue reading)

Permalink | Reply | 0 comments |
headers
fnu | 1 Apr 2011 12:13
Picon

Re: [Patch] Make RGYB buttons customizeable

> My remote has the color order Yellow, Red, Blue, Green (only an example, i
dont have the remote at hand). Lets say the buttons are Button0, Button1,
Button2, Button3

> My (and perhaps only my) opinion is that vdr should request the leftmost
color button, then the color right next to it (and so on) while learning.
The color displayed in the osd should be assigned via the setup menu.

Are you seriously asking for a major change like this, just for your most
propably unique remote control?

The color order of the RGYB buttons is a common standard, defined for
Teletext centuries ago. So, 99.999% of all remotes providing these keys do
have this order.

http://en.wikipedia.org/wiki/Teletext

Regards
fnu

_______________________________________________
vdr mailing list
vdr <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Permalink | Reply | 15 comments |
headers
Rainer Blickle | 1 Apr 2011 14:54

Re: [Patch] Make RGYB buttons customizeable

Yes i do. But the request can be refused, of course. Why not asking.

I have a hama MCE ir. Dont know how many people use this remote.

2011/4/1 fnu <vdr <at> auktion.hostingkunde.de>:
>> My remote has the color order Yellow, Red, Blue, Green (only an example, i
> dont have the remote at hand). Lets say the buttons are Button0, Button1,
> Button2, Button3
>
>> My (and perhaps only my) opinion is that vdr should request the leftmost
> color button, then the color right next to it (and so on) while learning.
> The color displayed in the osd should be assigned via the setup menu.
>
> Are you seriously asking for a major change like this, just for your most
> propably unique remote control?
>
> The color order of the RGYB buttons is a common standard, defined for
> Teletext centuries ago. So, 99.999% of all remotes providing these keys do
> have this order.
>
> http://en.wikipedia.org/wiki/Teletext
>
> Regards
> fnu
>
>
> _______________________________________________
> vdr mailing list
> vdr <at> linuxtv.org
> http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
(Continue reading)

Permalink | Reply | 8 comments |
headers
Joerg Riechardt | 1 Apr 2011 15:16
Picon
Picon

Re: vdr <-> vdr-xine <-> xine-lib and vdpau and HD recordings

Am 31.03.2011 17:27, schrieb Joerg Riechardt:
> Hi,
> I have a problem with skipping during a replay of a HD recording.
> Running xine --verbose=2 I see after pressing the yellow button (skip
> +60 sec) lots of
> video_out: throwing away image with pts xxxxxxx because it's too old
> (diff : yyyyy)
> messages.
> This is for a few seconds or forever, depending on system load, and
> causes 100% Cpu, and spoils recordings on my slow system. On faster
> systems you will hardly notice this.
> If I patch cDvbPlayer::SkipSeconds with
> - readIndex = Index - 1; // Action() will first increment it!
> + readIndex = Index; // Index - 1 causes problems in xine
> I no longer get those „throwing away image“ messages and the Cpu peak is
> only short and not that high.
>
> This happens also for starting a replay and for resuming replay after
> fast forward, but for those I have no vdr patch.

Well, for fast forward I do have a patch now, which is similar to the above:
-     readIndex = ptsIndex.FindIndex(DeviceGetSTC()) - 1;  // Action() 
will first increment it!
+     readIndex = ptsIndex.FindIndex(DeviceGetSTC());  // -1 causes 
problems in xine

_______________________________________________
vdr mailing list
vdr <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
(Continue reading)

Permalink | Reply | 1 comment |
headers
Oliver Schinagl | 1 Apr 2011 15:23
Picon
Favicon
Gravatar

Re: [Patch] Make RGYB buttons customizeable

I actually wrote the patch and posted it on this list, about 4? months
ago. It was maybe 20 lines total? It is a realyl small patch.

And so far, I have not found 99.999% to follow the same coloring
standard at all actually. Personally, I wasn't aware that the order of
buttons was standarized on remotes (I could agree that most teletekst
screens would be identical).

On 04/01/11 12:13, fnu wrote:
>> My remote has the color order Yellow, Red, Blue, Green (only an example, i
> dont have the remote at hand). Lets say the buttons are Button0, Button1,
> Button2, Button3
>
>> My (and perhaps only my) opinion is that vdr should request the leftmost
> color button, then the color right next to it (and so on) while learning.
> The color displayed in the osd should be assigned via the setup menu.
>
> Are you seriously asking for a major change like this, just for your most
> propably unique remote control?
>
> The color order of the RGYB buttons is a common standard, defined for
> Teletext centuries ago. So, 99.999% of all remotes providing these keys do
> have this order.
>
> http://en.wikipedia.org/wiki/Teletext
>
> Regards
> fnu
>
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Oliver Schinagl | 1 Apr 2011 15:26
Picon
Favicon
Gravatar

Re: [Patch] Make RGYB buttons customizeable

I have a iMon remote control, which also doesn't use this 'standard'
order ;)

Additionally on my previous mail (I hit send by accident actually :p) I
checked the wikipage, and i couldn't find any mention of color or colour
in relation to the order of the buttons. Also searching for Yellow
didn't result in a single hit, nor did RGYB.

So I'm not so sure of this 'standard order for remotes' yet?

On 04/01/11 14:54, Rainer Blickle wrote:
> Yes i do. But the request can be refused, of course. Why not asking.
>
> I have a hama MCE ir. Dont know how many people use this remote.
>
> 2011/4/1 fnu <vdr <at> auktion.hostingkunde.de>:
>>> My remote has the color order Yellow, Red, Blue, Green (only an example, i
>> dont have the remote at hand). Lets say the buttons are Button0, Button1,
>> Button2, Button3
>>
>>> My (and perhaps only my) opinion is that vdr should request the leftmost
>> color button, then the color right next to it (and so on) while learning.
>> The color displayed in the osd should be assigned via the setup menu.
>>
>> Are you seriously asking for a major change like this, just for your most
>> propably unique remote control?
>>
>> The color order of the RGYB buttons is a common standard, defined for
>> Teletext centuries ago. So, 99.999% of all remotes providing these keys do
>> have this order.
(Continue reading)

Permalink | Reply | 7 comments |
headers
VDR User | 1 Apr 2011 17:54
Picon

Re: vdr <-> vdr-xine <-> xine-lib and vdpau and HD recordings

I applied both your patches and skipping does seem to be improved
quite a bit.  Something still seems a little off however.

_______________________________________________
vdr mailing list
vdr <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Permalink | Reply | 0 comments |
headers
VDR User | 1 Apr 2011 18:08
Picon

Re: [Patch] Make RGYB buttons customizeable

On Fri, Apr 1, 2011 at 3:13 AM, fnu <vdr <at> auktion.hostingkunde.de> wrote:
> The color order of the RGYB buttons is a common standard, defined for
> Teletext centuries ago. So, 99.999% of all remotes providing these keys do
> have this order.

That's definitely not true.  I have about 8 different remotes and at
least half don't use that button order.  In addition, not every remote
has color buttons 4 in a row.  Plenty of them make a square around
other buttons such as 'ok/enter' for example.

_______________________________________________
vdr mailing list
vdr <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Permalink | Reply | 4 comments |
headers
fnu | 1 Apr 2011 23:54
Picon

Re: [Patch] Make RGYB buttons customizeable

vdr-user:
> That's definitely not true.  I have about 8 different remotes and at least half don't use that button order. 
In addition, not every remote has color buttons 4 in a row.  Plenty of them make a square around other buttons
such as 'ok/enter' for example.

Oliver Schinagl:
> I wasn't aware that the order of buttons was standarized on remotes

===

Well, could be that not all remotes for each pinchy device might provide color keys at all or in this order.
But if they are somehow TV oriented, they follow this order in a global manner, even the M$ ones, if they have
colored keys.

You want an evidence? Just check out the universal remotes form the big three manufactures, Philips,
Logitech & One-for-All, if the devices do offer colored keys, the order is RGYB, nothing left, nothing
right, and you should really ask yourself, why?

And, the most important point, global standard or not, it has been defined as standard in VDR a century ago,
and this is a fact.

Regards
fnu

_______________________________________________
vdr mailing list
vdr <at> linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
(Continue reading)

Permalink | Reply | 3 comments |
headers
Joerg Riechardt | 2 Apr 2011 02:38
Picon
Picon

Re: vdr <-> vdr-xine <-> xine-lib and vdpau and HD recordings

Problem solved with this patch:
--- dvbplayer.c.orig    2010-03-07 15:24:26.000000000 +0100
+++ dvbplayer.c 2011-04-02 01:57:21.016535946 +0200
 <at>  <at>  -320,7 +320,7  <at>  <at> 
    if (nonBlockingFileReader)
       nonBlockingFileReader->Clear();
    if (!firstPacket) // don't set the readIndex twice if Empty() is 
called more than once
-     readIndex = ptsIndex.FindIndex(DeviceGetSTC()) - 1;  // Action() 
will first increment it!
+     readIndex = ptsIndex.FindIndex(DeviceGetSTC());  // prevents 
dropped frames in xine vdpau h264
    delete readFrame; // might not have been stored in the buffer in 
Action()
    readFrame = NULL;
    playFrame = NULL;
 <at>  <at>  -388,6 +388,8  <at>  <at> 
    int pc = 0;

    readIndex = Resume();
+  int resume = readIndex;
+  bool firsttime = true;
    if (readIndex >= 0)
       isyslog("resuming replay at index %d (%s)", readIndex, 
*IndexToHMSF(readIndex, true, framesPerSecond));

 <at>  <at>  -452,6 +454,12  <at>  <at> 
                     else if (index) {
                        uint16_t FileNumber;
                        off_t FileOffset;
(Continue reading)

Permalink | Reply | 2 comments |

Gmane