Re: [vdr] [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 steffenbpu...@googlemail.com: 2011/3/30 Oliver Schinagl oli...@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 pressing yellow and one minute in the future when pressing green. These are the middle color buttons. I also wanted to have this functionality in the middle buttons (on the buttons 1 and 2). So i pressed the Buttons Yellow, Red, Blue, Green while learning Red,Yellow, Green, Blue. Then i have the jumping +/-1 Minute functionality still on the middle color buttons. The only thing left is that the color on the osd has to be adjusted, but not the positions of the text on it. If have dont this by modifying your patch (the texts for -DrawText are taken directly from the parameters, not from the mapping). 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. @Klaus: If there is a change to integrate this into the vdr, i would provide a patch for it. So in the end, this patch works for you and does what you want? Or is your remote layed out as VDR expects it? I would say better patch your remote. A sharp knife and a screwdriver might be quite effective and will fix the problem also for the next vdr releases ^^ This would be a real good solution, but i dont want to void my warranty :-) SCNR Steffen ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [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 v...@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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 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 xxx because it's too old (diff : y) 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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [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 ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [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 v...@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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] 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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
On Fri, Apr 1, 2011 at 3:13 AM, fnu v...@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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [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@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] vdr - vdr-xine - xine-lib and vdpau and HD recordings
Problem solved with this patch:
--- dvbplayer.c.orig2010-03-07 15:24:26.0 +0100
+++ dvbplayer.c 2011-04-02 01:57:21.016535946 +0200
@@ -320,7 +320,7 @@
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;
@@ -388,6 +388,8 @@
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));
@@ -452,6 +454,12 @@
else if (index) {
uint16_t FileNumber;
off_t FileOffset;
+ if (firsttime) {
+if (readIndex == (resume + 32)) {
+Goto((readIndex - 32));// prevents dropped
frames in xine vdpau h264
+firsttime = false;
+}
+ }
if (index-Get(readIndex + 1, FileNumber,
FileOffset, readIndependent, Length) NextFile(FileNumber, FileOffset))
readIndex++;
else
@@ -760,7 +768,7 @@
if (Index 0)
Index = index-GetNextIFrame(Index, false, NULL, NULL,
NULL, true);
if (Index = 0)
- readIndex = Index - 1; // Action() will first increment it!
+ readIndex = Index; // prevents dropped frames in xine vdpau h264
}
Play();
}
___
vdr mailing list
vdr@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
Re: [vdr] [Patch] Make RGYB buttons customizeable
On Fri, Apr 1, 2011 at 2:54 PM, fnu v...@auktion.hostingkunde.de wrote: 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. I'm not sure why you're trying to argue this. There are users in this thread (including myself) that already own remote(s) that don't follow this order. Assuming they're all for some pinchy device is silly. ALL of my remotes either came with dvb cards or sold as a media remote -- all of which are 'oriented' for tv among other devices. Also, you pointing out remote makers that follow the RGYB _scheme_ doesn't void the fact that plenty of remotes exist that don't. It's funny you use Logitech as one of your examples considering they make a mixture of remotes that do and don't follow that button scheme. That goes against your claims, not suport them. Ignoring remotes that don't follow the RGYB scheme doesn't make them any less 'tv oriented' or go away. I can't imagine it's much of a leap to make the colored button position customizable and is probably something that's better to have then not. What good argument against allowing the user to customize the layout according to their actual remote button layout could there be? None that I can think of. I'd guess Klaus will consider any patches submitted to him which don't cause problems. Regardless, users always have the option to patch the feature in if it doesn't become a part of VDR's core. ___ vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
