Messages

Very strange, the change doesnt seem to change anything in the behaviour ?!?

/EDIT: restartAtFramePi only gets called when state is switched to S_JUMP_PI , which is not switched when resuming a record to play....

Although just one day experience, I really like the scraper_support version; it seems more stable than the current vomp-client version (I think that's because of the segfault conditions Marten debugged); haven't had to reboot once yet...(knock on wood).

I just have two small bugs to report:
1) When displaying a 16:9 screen on 4:3 TV in letterbox mode, the lower black bar is not black but dark blue; the upper black bar is black, as expected.
2) When exiting a recording, and resuming it, the recording starts about 30 seconds later than where it was exited. This is not new behaviour, it also happened on the current (git master) vomp-client.
I guess this has something to do with either the vomp-server or the vomp-client starting at the first i-frame it encounters, but it means all p- and b-frames in between the exiting and the resuming are lost.

IMHO, the correct thing to do would be to jump back to the first I frame and start playing from there; this is the behaviour VDR itself does. It usally means the resume point is a little before the exiting point, but a little "replay" of a recording is less annoying than missing half a minute of the story 
I have no idea how complex that might be, a quick (but less elegant) fix would be just to rewind 30 seconds after resuming.

Marten, any ideas on this?

Yep, downgrading did the trick!

Hi Marten,

In my experience stuff is patched to RasPi before it is added to the Raspbian image/repository.
I also found this link http://stackoverflow.com/questions/15315372/sending-cec-commands-via-command-line-over-hdmi, stating:
Recent versions of libcec will recognize the Raspberry Pi hardware as a CEC adapter.

Stackoverflow is usually a reliable source, but I guess testing after compiling would be the ultimate proof. I have no HDMI CEC device, but I recall to have read somewhere you have :-)

Answering your question, I am still on wheezy:

Code Select Expand

root@raspvideo:/etc# cat /etc/apt/sources.list
deb http://mirrordirector.raspbian.org/raspbian/ wheezy main contrib non-free rpi
root@raspvideo:/etc# apt-cache search libcec
libcec-dev - USB CEC Adaptor communication Library (development files)
libcec1 - USB CEC Adaptor communication Library (shared library)
libcec2 - USB CEC Adaptor communication Library (shared library)
root@raspvideo:/etc# cat /etc/debian_version
7.8


The libcec-dev changelog reports libcec (2.1.3-1) unstable; urgency=low

Should I downgrade to 1.8 or is the fixing of the compile errors a minor operation?

After apt-update, apt-upgrade I downloaded current vompclient (not vompclient-marten), did a git checkout scraper_support, but I keep getting a compile error in remotelinux.cc:

Code Select Expand

remotelinux.cc: In member function 'int RemoteLinux::initCec()':
remotelinux.cc:134:34: error: invalid conversion from 'int (*)(void*, const cec_log_message&) {aka int (*)(void*, const CEC::cec_log_message&)}' to 'CEC::CBCecLogMessageType {aka int (*)(void*, CEC::cec_log_message)}' [-fpermissive]
remotelinux.cc:135:32: error: invalid conversion from 'int (*)(void*, const cec_keypress&) {aka int (*)(void*, const CEC::cec_keypress&)}' to 'CEC::CBCecKeyPressType {aka int (*)(void*, CEC::cec_keypress)}' [-fpermissive]
remotelinux.cc:136:31: error: invalid conversion from 'int (*)(void*, const cec_command&) {aka int (*)(void*, const CEC::cec_command&)}' to 'CEC::CBCecCommandType {aka int (*)(void*, CEC::cec_command)}' [-fpermissive]
remotelinux.cc:137:44: error: invalid conversion from 'int (*)(void*, const libcec_configuration&) {aka int (*)(void*, const CEC::libcec_configuration&)}' to 'CEC::CBCecConfigurationChangedType {aka int (*)(void*, CEC::libcec_configuration)}' [-fpermissive]
remotelinux.cc: In member function 'virtual UCHAR RemoteLinux::getButtonPress(int)':
remotelinux.cc:251:36: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
remotelinux.cc:279:37: warning: comparison between signed and unsigned integer expressions [-Wsign-compare]
<builtin>: recipe for target 'remotelinux.o' failed
make: *** [remotelinux.o] Error 1


These are my libcec versions:

Code Select Expand

root@raspvideo:/usr/local/src/vompclient# dpkg -l | grep libcec
ii  libcec-dev                         2.1.3-1                            armhf        USB CEC Adaptor communication Library (development files)
ii  libcec1:armhf                      1.8.1-1                            armhf        USB CEC Adaptor communication Library (shared library)
ii  libcec2:armhf                      2.1.3-1                            armhf        USB CEC Adaptor communication Library (shared library)

Is the libcec1 1.8.1-1 version the problem? apt-get install libcec1 states it is already on the newest version....

What to do?

Hi all,

Always when I am going to play with vompclient I keep forgetting which command line parameters I need to get the logging on screen. The "usage" message when doing vompclient -h does not help me, so here is a patch to improve the help message:

diff -Naur vompclient.old/main.cc vompclient.new/main.cc
--- vompclient.old/main.cc  2014-11-17 10:26:07.352924435 +0100
+++ vompclient.new/main.cc  2014-10-15 12:57:19.607563854 +0200
@@ -129,7 +129,7 @@
   char* setServer = NULL;
   int c;

-  while ((c = getopt(argc, argv, "cdns:")) != -1)
+  while ((c = getopt(argc, argv, "cdhns:")) != -1)
   {
     switch (c)
     {
@@ -144,11 +144,15 @@
       case 's':
         setServer = optarg;
         break;
-      case '?':
-        printf("Unknown option\n");
-        return 1;
+      case 'h':
       default:
-        printf("Option error\n");
+        printf("Usage: vompclient [options]\n");
+       printf("Options:\n");
+       printf("  -c        set 'crashed' variable\n");
+       printf("  -d        show debug messages on standard output; implies -n\n");
+       printf("  -n        do NOT daemonize into background\n");
+       printf("  -s server set 'setServer' variable to server\n");
+       printf("  -h        show this help message\n");
         return 1;
     }
   }


Perhaps someone (Marten?) can improve on the -c and -s message, I really can't figure out what this is doing!

Marten, could you put this into git? Thanks!

Hi all,

When compiling GIT version of vompclient on Raspi (which is current on Raspbian) first I have to install a new package to fullfill a new dependency:
apt-get install libavresample-dev   (documenting this for others).

But then I come in to this error:
audioomx.cc: In member function 'unsigned int AudioOMX::AdvanceMpAudioSync(const UCHAR*, unsigned int, unsigned int*)':
audioomx.cc:1579:15: warning: declaration of 'test' shadows a member of 'this' [-Wshadow]
audioomx.cc: In member function 'unsigned int AudioOMX::AdvanceAc3AudioSync(const UCHAR*, unsigned int, unsigned int*)':
audioomx.cc:1659:15: warning: declaration of 'test' shadows a member of 'this' [-Wshadow]
audioomx.cc: In member function 'unsigned int AudioOMX::AdvanceAacLatmAudioSync(const UCHAR*, unsigned int, unsigned int*)':
audioomx.cc:1679:15: warning: declaration of 'test' shadows a member of 'this' [-Wshadow]
audioomx.cc: In member function 'void AudioOMX::getDownMixMatrix(long long unsigned int, int*, int*)':
audioomx.cc:1710:18: error: 'AV_CH_BACK_LEFT' was not declared in this scope
audioomx.cc:1710:36: error: 'AV_CH_SIDE_LEFT' was not declared in this scope
audioomx.cc: In member function 'UINT AudioOMX::DeliverMediaPacket(MediaPacket, const UCHAR*, UINT*)':


I tried fiddling around:

-adding a "#include <libavutil/channel_layout.h>" to audioomx.h
then new errors occur, solving them:
-adding -fpermissive flag to CXXFLAGS_DEV in GNUMakefile
-adding -ldl and -lfontconfig to LIBS in GNUMakefile

..then it compiles but audio is some kind of "Donald Duck" like sound.

What am I doing wrong?

I'm using the original Microsoft one; I understand there are many versions out there, the one I have looks like this:
http://www.ebay.com/itm/Original-Microsoft-Media-Center-MCE-Remote-Control-with-Receiver-and-IR-Blasters-/111260244845?pt=US_Remote_Controls_Pointers&hash=item19e7a09b6d

Looks like your remote receiver uses another chipset, which uses another kernel module than mceusb ...

From the net:
=================================
Remote controls of internal TV adapters

Receivers that are integral to the TV adapters are usually attached via rc-core and will be configured via ir-keytable. There are a few exceptions from this rule. Thus, you may check whether or not an corresponding rc-core device has been created:

rc-core recognized.

user@yavdr:~$ sudo ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event3) with:
        Driver ir-kbd-i2c, table rc-rc5-tv
        Supported protocols: RC-5
        Enabled protocols:
Repeat delay = 500 ms, repeat period = 33 ms

The subsequent setup instructions are described in the section ir-keytable in this manual.

When there is no rc-core device recognized, the following output is given:

user@yavdr:~$ sudo ir-keytable
Couldn't find any node at /sys/class/rc/rc*.

To identify whether the remote control is recognized and how it is hooked into the sytem, please check the input devices: cat /proc/bus/input/devices

================================
So this last command would give you some insight; your only chance would be if the kernel module has some parameters to have rc_core used (doubtful), you could try modinfo <modulename> . If not, last chance would be some kernel-compiletime paramater for this module (just guessing here), but it would require recompiling your kernel.

If all else fails, I'm afraid you will have to use lirc....

Things you could try:
-login as root and retry; perhaps it is a permissions problem?
-check the /sys directory structure (again as root)
-what does ir-keytable (without arguments) report?
-unplug and replug your remote, and look with dmesg and/or /var/log/syslog what the kernel is reporting

I have no access to my raspi right now, so I am not sure which kernel module would create the /sys/class../rc directory, but my first guess would be the mceusb module (lsmod | grep mceusb), so perhaps that one doesn't get loaded properly. You could 
-load the mceusb module by hand with modprobe).
-what does lsusb report?

Good luck!

Hi Marten,

Sorry for that; my TV is connected through composite/PAL , so I guess resolution is standard PAL (768 x 572, some say 762 x 572)??

Best regards, Hans.

The subject says it all : 4:3 content shown in letterbox on 4:3 TV.

Settings are 4:3 TV  and letterbox.

Thanks Marten, works like a charm now!

Hi all,

Great work on the vompclient on Raspberry, have started to use it and enjoying it a lot! The default vompclient branch from git has some annoying bugs in it (e.g. hanging when fastforwarding/jumping through recordings too quickly), but luckily these seem to be solved in the vompclient-marten branch.

One small bug I spotted: when my vompclient has its audio Muted, and I start playing a recording, sound is audible. Pressing the mute button twice (unmute first time, mute again second time) works fine. Same thing on live tv. I should mention I tap my audio through the 3.5 mm plug, not using HDMI.

Seems like just a small initialization error, any idea on where to solve this?

Thanks!

Hi Marten,

You are right, the default Raspbian permissions for the interface my patch is using is:

Code Select Expand

root@raspvideo:/sys/class/leds/led0# ls -l brightness
-rw-r--r-- 1 root root 4096 Oct 30 09:04 brightness


If you change these permissions to writeable for the user that is running vompclient, it should work.

Or one could add to /etc/rc.local:

Code Select Expand

chmod o+w /sys/class/leds/led0/brightness

AFAIK there is no significant security issue with this, as long as you don't mind that anyone that has access to your raspi can turn your LED on or off :-)