Topics

The update to libc6 on the Raspbian distribution which has recently been released can cause the vompclient (and any other program linked to the videocore libraries) to fail with 'library not found' errors. This forum post gives the workaround:

http://www.raspberrypi.org/phpBB3/viewtopic.php?f=66&t=34661

otherwise don't update your system until the problem is fixed.

The option in GNUMakefile which gives the choice of shutting down or rebooting the Pi from the remote doesn't work. The #define VOMP_HAS_EXIT is never passed to the compiler. I don't really understand Makefiles so this is a quick fix:

Code Select Expand

diff --git a/GNUmakefile b/GNUmakefile
index f759c16..a7684b1 100644
--- a/GNUmakefile
+++ b/GNUmakefile
@@ -68,6 +68,7 @@ CXXFLAGS_DEV += -D__STDC_CONSTANT_MACROS
CXXFLAGS_REL += -D__STDC_CONSTANT_MACROS

endif
+INCLUDES += $(vomp_options)

.PHONY: clean fresh all install strip



It seems that the GPU on the Raspberry Pi buffers about six seconds of playback. The calculations for skipping backwards and forwards are based on the frames being fed into the GPU, while the TV is showing video from six seconds earlier. Hence a 10 second forwards skip actually jumps about 16 seconds, while a 10 second backward skip goes back only 4.

This quick-and-dirty patch adjusts the skip timings to allow for GPU buffering.

Code Select Expand


diff --git a/player.cc b/player.cc
index 1650ed4..494d199 100644
--- a/player.cc
+++ b/player.cc
@@ -33,6 +33,7 @@
#include "osdreceiver.h"

#define USER_RESPONSE_TIME 500 // Milliseconds
+#define OMX_BUFFER_SECONDS 6.0 // Float seconds

// ----------------------------------- Called from outside, one offs or info funcs

@@ -418,6 +419,9 @@ void Player::skipForward(int seconds)
   ULONG newFrame = getCurrentFrameNum();
   if (newFrame == 0) { unLock(); return; } // Current pos from demuxer is not valid
   newFrame +=(ULONG) (((double)seconds) * fps);
+#ifdef VOMP_PLATTFORM_RASPBERRY
+  newFrame -=(ULONG) (((double)OMX_BUFFER_SECONDS) * fps);
+#endif
   if (newFrame > lengthFrames) { switchState(S_PLAY); unLock(); }
   else switchState(S_JUMP, newFrame);
//  unLock(); - let thread unlock this
@@ -430,6 +434,9 @@ void Player::skipBackward(int seconds)
   long newFrame = getCurrentFrameNum();
   if (newFrame == 0) { unLock(); return; } // Current pos from demuxer is not valid
   newFrame -= (ULONG) (((double)seconds) * fps);
+#ifdef VOMP_PLATTFORM_RASPBERRY
+  newFrame -=(ULONG) (((double)OMX_BUFFER_SECONDS) * fps);
+#endif
   if (newFrame < 0) newFrame = 0;
   switchState(S_JUMP, newFrame);
//  unLock(); - let thread unlock this


If I try to exit the vompclient by pressing the '7' key from the main menu (rather than by using the up/down and OK keys), the client shows a 'connection lost' box and the keyboard locks. This is the fix:

Code Select Expand


diff --git a/vwelcome.cc b/vwelcome.cc
index cb88da6..dad013a 100644
--- a/vwelcome.cc
+++ b/vwelcome.cc
@@ -189,6 +189,7 @@ int VWelcome::handleCommand(int command)
     case Remote::SEVEN:
     {
       Command::getInstance()->doReboot();
+      return 2;
     }
     case Remote::OK:
     {


Presumably the MVP never returned from doReboot(), but the RPi version does, and it then falls into the next part of the case statement.

Is the Raspberry Pi client on git.vomp.tv working, ie able to show recordings?

I've compiled the code on my up-to-date Raspbian installation (with hardware MPEG2 enabled). The client connects to the vdr server and I can see the OSD. However when I try to play a recording all I see is the console screen with the OSD time-bar at the bottom. The logs seem to show the client downloading data from the server and handing it on to the display, but eventually error messages "Deliver MediaPacket no free sample" appear.

Incidentally, while working through the logs I noticed another error - "TCP - Too many reads" at the point where playback is started. This seems to be caused by the TCP window size, which on the MVP was set to 2048 bytes because of its very limited buffer space. On the RPi I suggest it is not necessary to limit TCP in this way, and commenting out the code cleared the error with no obvious ill effects.

Dave

The fonts used to display the OSD in vomp are pre-processed into C code by a utility called bdftobogl. Does anyone know where I can find the version of this utility used in vomp? There are lots of places on the net where source code can be found, but the latest version seems to be 0.1.18 and the data structures are completely different to the vomp ones.

The reason I'm looking for bdftobogl is that the default fonts (Helvetica Bold) look very blocky on my large screen and I'd like to try some lighter ones.

When playing MP3 files using the new media player (CVS plus the GUI patch) I can crash the client with 10% probability by either switching tracks using the up/down buttons or moving within a track with the << and >> buttons. The entire MVP crashes; the LED goes out and networking fails, so only a power-cycle will restore it.

The last couple of seconds of debug output is:

13:42:17.264076 [debug]  164 VDR - RR sleep - opcode 32
13:42:17.285571 [debug]  160 VDR - Rxd a response packet, requestID=85, len=51200
13:42:17.286622 [debug]  164 VDR - RR unsleep
13:42:17.287431 [debug]  164 doRequestResponse - got response 0x10244c28
13:42:18.034616 [debug]  164 VDR - RR sleep - opcode 32
13:42:18.056762 [debug]  160 VDR - Rxd a response packet, requestID=86, len=51200
13:42:18.057819 [debug]  164 VDR - RR unsleep
13:42:18.058874 [debug]  164 doRequestResponse - got response 0x10244c28
13:42:19.042058 [debug]  155 Remote - Button 30
13:42:19.042365 [debug]  155 VMediaView::handleCommand - cmd=30,p=0x10240580
13:42:19.042658 [debug]  155 AudioPlayer - new pos 1670776  skip 10s
13:42:19.051297 [debug]  164 AudioPlayer - Switch state from 1 to 3
13:42:19.052155 [debug]  164 Audio - MUTE MUTE MUTE
13:42:19.053052 [debug]  164 AudioPlayer - control feeder old=1, new=2

I've just upgraded my server from Mandriva 2007.1 to 2008.0, which has updated the compiler to GCC 4.2.2 (pre-release). Compiling the VOMP plugin now fails with messages such as these:

tftpclient.c: In member function 'int TftpClient::openFile(char*)':
tftpclient.c:275: warning: deprecated conversion from string constant to 'char*'
tftpclient.c:275: warning: deprecated conversion from string constant to 'char*'
tftpclient.c:283: warning: deprecated conversion from string constant to 'char*'
tftpclient.c:283: warning: deprecated conversion from string constant to 'char*'

As a workaround I modified the Makefile

#CXXFLAGS ?= -O2 -fPIC -Wall -Woverloaded-virtual -Werror
CXXFLAGS ?= -O2 -fPIC -Wall -Woverloaded-virtual

which lets VOMP compile, though there are hundreds of error messages.

Dave

I've just updated VDR to version 1.4.2. Although everything seems to be working, this message appears in syslog as VOMP boots:

vdr: [20841] ERROR: plugin '<no name given>' called cPlugin::ConfigDirectory(), which is not thread safe!

There is mention in the VDR release notes that this message was added in 1.4.1-4 but not what the reason is or how to fix. VOMP does indeed call this function in both mvpserver.c and mvpclient.c.

Dave

I just updated my vomp server and client source from CVS. Compiling the client produces this error:

/opt/crosstool/powerpc-405-linux-gnu/gcc-2.95.3-glibc-2.2.5/bin/powerpc-405-linux-gnu-g++ -O3 -Wall -Woverloaded-virtual -Wshadow -Werror -D_GNU_SOURCE -I../jpeg-6b   -c -o demuxervdr.o demuxervdr.cc
cc1plus: warnings being treated as errors
demuxervdr.cc: In method `ULONG DemuxerVDR::getFrameNumFromPTS(long long unsigned int)':
demuxervdr.cc:252: warning: `ULONG ret' might be used uninitialized in this function
make: *** [demuxervdr.o] Error 1

There's nothing at all wrong with the code; there is no way that the variable could be used uninitialised but the compiler hasn't spotted that. This little patch shuts it up:

Index: client/demuxervdr.cc
===================================================================
RCS file: /cvsroot/vomp/client/demuxervdr.cc,v
retrieving revision 1.7
diff -u -r1.7 demuxervdr.cc
--- client/demuxervdr.cc        11 Jun 2006 21:46:52 -0000      1.7
+++ client/demuxervdr.cc        13 Jun 2006 20:35:47 -0000
@@ -282,7 +282,6 @@
     ++iter;
   }
   --iter;
-  if (onTarget) ret = iter->frame;
   pthread_mutex_unlock(&pts_map_mutex);
   if (!onTarget)
   {
@@ -291,6 +290,7 @@
   }
   else
   {
+    ret = iter->frame;
     Log::getInstance()->log("Demuxer", Log::DEBUG, "FOUND FRAME NUMBER %d for %llu", ret, pts);
     return ret;
   }

Trying today to compile the vompserver plugin for the first time since upgrading this box to Mandriva 2006 (which uses GCC4) I get this:

make[1]: Entering directory `/dave/DVB/DVB/vdr-1.3.34/PLUGINS/src/vompserver'
g++ -O2 -Wall -Woverloaded-virtual -Werror -c -DPLUGIN_NAME_I18N='"vompserver"' -I../../../include -I../../../../DVB/include -Iremux -Ilibdvbmpeg -o vompserver.o vompserver.c
cc1plus: warnings being treated as errors
thread.h:28: warning: 'class Thread' has virtual functions but non-virtual destructor
make[1]: *** [vompserver.o] Error 1
make[1]: Leaving directory `/dave/DVB/DVB/vdr-1.3.34/PLUGINS/src/vompserver'
make: *** [plugins] Error 2

Is this a GCC4-ism or have I messed up somewhere?

Using Dongle 007 and today's CVS, when I tune to a non-transmitting channel I get the new 'No Data' popup. However *every* channel selected thereafter also produces the popup. It doesn't stop viewing since the message disappears after a few seconds.

This is with vdr-1.3.27. BTW VOMP does work with the latest development version 1.3.28.

Dave

After battling unsuccessfully for a couple of weeks with MVPServer I was delighted to get your software up and running in about 30 minutes. Very well done!

One item for the TODO list. Switching the MVP into standby should remove power from the SCART connector, as some TVs sense the voltage on one of the pins to switch back to normal mode. The most recent dongle.bin from Hauppauge does this.

Oh and the plugin doesn't compile under vdr 1.3.27 but you probably knew that.

Dave