Messages

Attached a patch to have the green on board led working as an on/off indicator for vompclient.

The other leds (except for the red power led) can be cleared by this patch (but the kernel needs to be recompiled for that):
http://www.raspberrypi.org/phpBB3/viewtopic.php?f=31&t=12530&sid=f152b5af6d3915a18ed8b2d005daa801&start=25

The libcec-dev package in the post above is not working (only 519 bytes). Get it from here:http://forum.loggytronic.com/index.php?topic=620.0

Hi all (but especially Marten and Christophe),

As I was remapping the keys of my MCE remote I noticed that most of the keys worked right out of the box, but a few just didn't work because of conflicting naming schemes between linux-kernel and vompclient.
Now I suspect vompclient was earlier with these names than the kernel, and I also suspect the kernel-developers are/cannot be aware of a nice application like VOMP.

Perhaps it would be a good idea to change

Code Select Expand

KEY_FORWARD to KEY_FASTFORWARD
KEY_BACK to KEY_REWIND
KEY_BACKSPACE to KEY_EXIT
in remotelinux.cc .

It would make sure that these keys work right out of the box on all MCE compliant remotes on these keycodes, and (AFAIK) would not break any other remotes (Marten, Christophe, can you confirm this?)

Arguable would be these keys:

Code Select Expand

KEY_POWER to KEY_SLEEP
KEY_M to KEY_MEDIA
..since I have nu clue on how other remotes name these keys. It makes more sense to my to name the power key KEY_POWER then KEY_SLEEP, but I am not sure how dominant Microsofts market position to other suppliers is on this small issue.
Also, the menu key on the hauppauge remote is also labeled I(nfo), and it is used as a KEY_INFO button in live TV in vomp, but kind of as a KEY_MEDIA when playing recordings.

What do you guys think?

Best regards ALL !!!

Finally got my Raspberry Pi, installed vompclient and then discovered some keys of my Microsoft MCE remote control were not recognized. Especially the BACK key (marked BACK/EXIT on hauppauge's remote) is a pain when missed.
Also this remote lacks the red/green/yellow/blue keys, but it has four unused keys in a row (Recorded TV, Guide,Live TV and DVD Menu) which can be remapped to those colours easily.

Also Power, Menu, Fast forward and Rewind keys were not working.

Now first thing I did was

Code Select Expand

apt-get purge inputlirc
apt-get purge lirc
apt-get autoremove

to get rid of all LIRC stuff. LIRC has had its use in the far past when people bought an IR-sensitive transistor and hooked it up to their serial RS232 port. In this day and age of USB and event- and input driven code in the kernel you don't need it, it will only mess up stuff.

Then test if your remote is recognized by the kernel:

Code Select Expand

ir-keytable -t

Now press keys on your remote, and if your remote is recognized by the kernel it reports every keypress. Now press all the keys you want to remap, and write down their key-codes. E.g. I want to remap my DVD-Menu key to act like the blue button on my old hauppauge remote, pressing that key reports: KEY_DVD.

Now look at by which driver, and at which table it is recognized:

Code Select Expand


root@raspvideo:/tmp# ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event0) with:
        Driver mceusb, table rc-rc6-mce
        Supported protocols: NEC RC-5 RC-6 JVC SONY SANYO LIRC other
        Enabled protocols: NEC RC-5 RC-6 JVC SONY SANYO LIRC other
        Repeat delay = 500 ms, repeat period = 125 ms



Now generate new keymap file:

Code Select Expand

ir-keytable --read --device=/dev/input/event0 >/etc/rc_keymaps/rc6_mce

Now change the lines of the keys you want to remap (note how we remap the KEY_DVD to KEY_BLUE):

Code Select Expand


scancode 0x800f040c = KEY_POWER #was KEY_SLEEP (0x8e)
scancode 0x800f040d = KEY_M #was KEY_MEDIA (0xe2)
scancode 0x800f0414 = KEY_FORWARD # was KEY_FASTFORWARD (0xd0)
scancode 0x800f0415 = KEY_BACK #was KEY_REWIND (0xa8)
scancode 0x800f0423 = KEY_BACKSPACE #was KEY_EXIT (0xae)
scancode 0x800f0424 = KEY_BLUE #was KEY_DVD (0x185)
scancode 0x800f0425 = KEY_YELLOW #was KEY_TUNER (0x182)
scancode 0x800f0426 = KEY_GREEN #was KEY_EPG (0x16d)
scancode 0x800f0448 = KEY_RED #was KEY_PVR (0x16e)

The left-hand keynames are the ones that VOMP expects, you can find them in the source code of vompclient in remotelinux.cc .

Now test the keymap by writing it:

Code Select Expand

ir-keytable --write=/etc/rc_keymaps/rc6_mce --device=/dev/input/event0

Your vompclient should now use new mappings, but will lose these mappings after reboot.

Code Select Expand

vi /etc/rc_maps.cfg
change line:

Code Select Expand

*  rc-rc6-mce               /lib/udev/rc_keymaps/rc6_mce
to:

Code Select Expand

#*  rc-rc6-mce               /lib/udev/rc_keymaps/rc6_mce
#remap microsoft MCE remote color buttons for VOMP
* rc-rc6-mce               rc6_mce

Now you would expect that linux would load this settings at reboot, but it doesn't at my machine. I suspect it is because the kernel at Raspbian is compiled without CONFIG_RC_MAP set, but I am not sure about that.

What I am sure about is that it will load when specified explicitly, add these lines at the end of /etc/rc.local, just before the exit statement:

Code Select Expand

ir-keytable -a /etc/rc_maps.cfg
/usr/local/bin/vompclient

Have fun!

Hi Chris,

You are right, I broke the drop-through with my patch and fixed it by some extra lines of code; those lines are not necessary in the original code.

Best regards, Hans.

Hi Marten,

Sorry about that, didn't realise there were remotes out there nowadays without separate play/pause/stop and up/down/left/right buttons.

Since we already have an OLD REMOTE/ NEW REMOTE setup item, would it be an idea to add a "REMOTE WITHOUT PLAY/PAUSE/STOP keys?

Best regards, Hans.

Hello all,

First of all big thanks to Chris and Marten for the new vomp 4.0; working great here!

I made some patches which I think are improvements:

• resume_as_default.diff  makes the "Resume" button as default, instead of the "Play" button. For recordings that are viewed for the first time, the behaviour remains the same, for recordings that are viewed before this is usually the wanted behaviour. It also reduces the number of button presses because moving to "Move" or "Delete" takes less keypresses.
  I also did some code optimizations which reduce the number of lines and (IMHO) code readability significantly; it also reduces object code by 4K.
  
• jump-10s-5min.diff makes use of the fact that up, down, left and right keys are having functions that are already available through other buttons on the remote (like play, pause, rewind and fastforward). This patch remaps the keys to:
  
  
  • UP: Forward 10s
  • DOWN: Back 10s
  • RIGHT: Forward 5 min
  • LEFT: Back 5 min/li]
    
  It also solves a small bug which happens when pressing BACK during a recording and no summary is being shown.
  

I hope you like this patches and Chris, would you please consider applying these patches to the repository?

Thanks!

Ok thanks!

Hi all,

I noticed that fast forwarding with 16x and 32x speed did not work anymore. Also I noticed that default button in the recordings menu is "Play"; although this might seem logical, IMHO "Resume" is a better default button, since
a) when a recording is unwatched it does the same as Play
b) when a recording is watched, it resumes at the last point, which with normal usage will be the desired behaviour.

I attach the two patches (Chris, can you put these in CVS?) and a compiled binary with the patches included.

EDIT: that's ashame, maximum attachement size is 2000K and the dongle is 2039K ... can someone lift this limit since dongle size is this big for years now....

Trying to solve some problems in the dongle software, I stumbled upon the problem that makedevenv-6 does not work on debian squeeze. When compiling the kernel this error occurs:

Code Select Expand

scripts/Configure: line 549: .: .config: file not found
scripts/Configure: line 551: .: .config-is-not.14056: file not found

Googling revealed other people have same problem, but no solution found. The problem seems to be that the bash dot/source command fails to look in the current directory in bash4, which it did correctly in bash3.

I solved this by creating a patch; to have this patch activated at the right time, I had to adapt the "patch" script; it is now adapted in such a way that future patches can be added without changing the script.

Perhaps Chris or Marten could add the patch and the changed patch script to kernel-1.tar.gz, in that case the makedevenv-7 script can be replaced by the makedevenv-6 script, since no other changes were made.

I tried to install the "hdtest2" version of vomp for windows on my old laptop. The vompwin 0.3.0 starts ok at this laptop (not sure about sound and picture because I have no compatible vompserver running at the moment).

At first I got the message "This application is not configured correctly; reinstall" (not the literal version since my local language is installed), this could be solved by installing the C++ 2008 redistributable .

Now, when I start the exe, you can see a window is drawn, but then immediately it is deleted and vomp exits. Redirecting output gives an empty file. Disabling audio and video acceleration does not help. Changing video/audio codec does not help (of course, it doesnt even get to draw the main menu).

Perhaps my directX is not entirely up to par, I did my standard "D3DXDLLFebruary29\D3DX9_29_dll_update"  routine, but perhaps new HD version has higher requirements to directX? Or is something else going wrong? Dxdiag gives good results on directdraw and direct3d ...

Thanks!

Marten, at testing some strange behaviour of the "normal" client (MVP, not windows):

Selecting Main menu option TV gives channels list, some HD channels do not appear in the list (wouldnt expect that that had already been taken care of), and some do ?!?

My channels.conf:

Code Select Expand

:HDTV
NederlandHD;Canaldigitaal:11856:vC56M2O35S1:S23.5E:27500:517=27:90=dut:36:100:7035:3:3208:0
Nederland 3 HD;Canaldigitaal:12129:vC56M2O35S1:S23.5E:27500:520=27:96:40:100:20950:3:3222:0
RTL4 HD;CANALDIGITAAL:11856:vC56M2O35S1:S23.5E:27500:514=27:84=dut:34:D03,D70,100:7020:3:3208:0
een HD;CANALDIGITAAL:11856:vC56M2O35S1:S23.5E:27500:516=27:88=dut:37:100:7030:3:3208:0
Discovery HD;CANALDIGITAAL:11856:vC56M2O35S1:S23.5E:27500:512=27:0;80=dut:43:D03,D70,100:7010:3:3208:0
NGC HD;CANALDIGITAAL:11856:vC56M2O35S1:S23.5E:27500:513=27:0;82=dut:0:100:7015:3:3208:0
BBC HD;BSkyB:10847:vC56M2O0S1:S28.2E:22000:5500=2:5502=NAR;5501=eng:5503:0:6940:2:2050:0
History Channel HD;skylink:12110:hC910M2O20S1:S23.5E:27500:4002=2:4322=hun;4162=cze,4242=eng:0:D70,D03,100:5042:3:3221:0
Eurosport HD;skylink:12110:hC910M2O20S1:S23.5E:27500:4001=2:4161=cze,4321=hun,4641=dut;4241=eng:0:D70,D03,100:5041:3:3221:0
Einsfestival HD;ARD:12421:hC34M2O0S0:S19.2E:27500:1601=27:1602=deu;1606=deu:0:0:28396:1:1201:0
ANIXE HD;BetaDigital:11303:hC23M5O35S1:S19.2E:22000:255=2:0;259=deu:0:0:4900:1:1007:0
arte HD;ZDFvision:11361:hC23M5O35S1:S19.2E:22000:6210=27:6221=deu,6222=fra;6220=deu:6230:0:11120:1:1011:0
ORF1 HD;ORF:11303:hC23M5O35S1:S19.2E:22000:1920=27:1921=deu,1922=eng;1923=deu:1925:D05,1702,1833,648,D95,9C4:4911:1:1007:0
BravaHDTV;CANALDIGITAAL:11856:vC56M2O35S1:S23.5E:27500:515=27:0;86=dut:0:D03,D70,100:7025:3:3208:0
MTVNHD;MTV Networks Europe:11778:vC34M2O0S0:S19.2E:27500:2000=27:2001=eng;2002=eng:0:D00,100,500,1811:28601:1:1068:0
MTVNHD;MTV Networks Europe:11778:vC34M2O0S0:S19.2E:27500:2000=27:2001;2002=eng:0:D00,100,500,1810,1811:28600:1:1068:0
ASTRA HD Demo;DVL.TV:10862:hC56M2O0S0:S23.5E:22000:1011=2:1013=eng:0:0:5000:3:3111:0
ASTRA HD+;BetaDigital:11303:hC23M5O35S1:S19.2E:22000:511=2:0;515=deu:0:0:4901:1:1007:0
Film 1 HD;CANALDIGITAAL:12129:vC56M2O35S1:S23.5E:27500:521=27:98;111=dut:0:100:20955:3:3222:0
Sport 1 HD;Canaldigitaal:12129:vC56M2O35S1:S23.5E:27500:522=27:100:42:100:20960:3:3222:0
HD-Test ARD ZDF;IRT:11361:hC23M5O35S1:S19.2E:22000:6410=2:6420=deu;6421=deu,6422=Ori:6430:0:11140:1:1011:0


Displayed in the list are:
BBC HD, History Channel HD, Eurosport HD, ANIXE HD, ASTRA HD Demo, ASTRA HD+, HD_Test ARD ZDF . The other ones are blanked (expected behaviour, since HD on SD device will go wrong).

The client code I posted has not processed hdtv2.patch from Marten correctly. I applied it and mode two modifications:
-changed abs function call to floating point to fabs, as code wont compile when trying to apply abs to floating point
-added countPictureHeaders definition in Pespacket class definition.

New client source code attached, dongle binary uploaded:
http://rapidshare.com/files/355624021/vomp-dongle-0.3.1-2-Yaris-HD2.bz2

Please dont complain to me about rapidshare, downloading in off-peek hours just works fine for free users. Better ask the admin of this board to increase the upload limit from 2000K to 2500K, since compressed dongle is slightly over 2000k ....:-(
Also dont ask me to function als your personal upload center...

Hondans, perhaps you could upload these versions to your ftp server for all's convenience?

Exe file is from Marten ... updates on Yaris version in other thread.

The rapidshare link points to the dongle binary. Object code = binary.