Messages

Only quick smoke test done of the build. The mvp boot and will not show hd channels in the channel list.

http://ubuntuone.com/2v5NGFb6ogypJYhS0aI5TR

I'm using 1.8.1-1

Packages are available here:
http://forum.loggytronic.com/index.php?topic=620.msg3437#msg3437

> I can post the link if needed.

Yes please!

Without patching the vompclient sources the compile should not have succeeded if the libcec version is greater than 2.0.
Perhaps a stray version is picked up while compiling.

I makings some test using the vompserver 0-4-0rc branch. My raspi client compiled from 0-4-0rc branch will connect to the vompserver but my old mvp client running 0.3.1 will not.

Do I have anything miss configured or is is a fact that the new protocol and/or new discovery protocol is not compatible with old vomp clients?

Current sources does not compile with libcec version >= 2.0 since it introduces some incompatibilities with previous versions of the api.

The api breaking commit for vompclient can be viewed here:

https://github.com/Pulse-Eight/libcec/commit/3ad0aa0ace71f00f5a972850367e8ae18eae19f5#include/cectypes.h

The change is trivial to implement in remotelinux.cc and remotelinux.h

I suppose that most raspi users are using the prebuild deb packages provided on this forum e.g. version 1.8.1-1

If decided to switch to a later api version we should provide, or give links, to where prebuilt deb package can be downloaded.

I tested the bandwidth between the raspberry pi and the vdr server using iperf, that measures maximum tcp/udp performance,  and the download speed was around 70MB/s which is more than sufficient. Did find a 720p recording that plays back just fine. Still think its the 1080 recording that is boorked.

My request for a working 1080 recording is still open. Can someone PLEASE, PLEASE provide one?

I have now tested with all available TcpWindowSIze values without success.

A file transfer of the file from the vdr server shows a transfer rate of about 3.5 MB/s which should be sufficient?

Playback of the file from an nfs mounted volume of the ver server using omxplayer is working ok.

Could it be that the vdr version I'm using is to old. Its vdr 1.7.25 ?

I would still love if someone could share a working recording with me.

I do as well suspect network issues. Perhaps time to upgrade switches and cables to GB :-)

Did before testing check with the TcpWindowSIze  set to auto as well with some higher values. Did not try all of them though.

Just to rule out that the existing file i have used might be causing high bit rates when streamed I would like to get hold of a file that is known to work for others.

Still using a vdr server without ability to record any HD channels I would still like to check the performance of HD playback on the raspberry.

Found a bbc hd recording but it gives bad stutter in audio and playback during playback while it plays back almost flawless using omxplayer (occasional stutter and some pixelation). Since people on this list does not seam to complain on their hd playback I want to rule out its not a fault with the hd recording I have downloaded.

Could someone offer a download link to a hd vdr recording that plays flawless on your raspberry using vompclient.

Adding #include <bcm_host.h> in files audioomx.cc, osdopenvg.cc and videoomx.cc and changing the declaration of the two last variables passed to  vgSetGlyphToImage from being const make vompclient compile again.

I won't bother creating a patch for this unless Marten suggests so.

Did an apt-get update, apt-get upgrade yesterday.

When I now compile head of vompclient-raspi I get the following error:

Code Select Expand


pi@raspberrypi ~/vomp/vompclient-raspi $ make
raspberry normal compiler
Setting up objects
Raspberry pi flags
g++ -g -O0 -Wall -Wshadow -DDEV -D_GNU_SOURCE -DVOMP_PLATTFORM_RASPBERRY   -I/opt/vc/include -I/opt/vc/include/interface/vcos/pthreads  -I/usr/include/freetype2 -I/usr/include/ImageMagick -D__STDC_CONSTANT_MACROS   -c -o osdopenvg.o osdopenvg.cc
osdopenvg.cc: In member function 'virtual int OsdOpenVG::init(void*)':
osdopenvg.cc:169:68: error: 'graphics_get_display_size' was not declared in this scope
osdopenvg.cc:103:10: warning: unused variable 'video' [-Wunused-variable]
osdopenvg.cc: In member function 'virtual void OsdOpenVG::threadMethod()':
osdopenvg.cc:469:16: warning: unused variable 'waittime' [-Wunused-variable]
osdopenvg.cc: In member function 'unsigned int OsdOpenVG::loadTTchar(cTeletextChar)':
osdopenvg.cc:569:35: error: invalid conversion from 'const VGfloat* {aka const float*}' to 'VGfloat* {aka float*}' [-fpermissive]
/opt/vc/include/VG/openvg.h:680:31: error:   initializing argument 4 of 'void vgSetGlyphToImage(VGFont, VGuint, VGImage, VGfloat*, VGfloat*)' [-fpermissive]
osdopenvg.cc:569:35: error: invalid conversion from 'const VGfloat* {aka const float*}' to 'VGfloat* {aka float*}' [-fpermissive]
/opt/vc/include/VG/openvg.h:680:31: error:   initializing argument 5 of 'void vgSetGlyphToImage(VGFont, VGuint, VGImage, VGfloat*, VGfloat*)' [-fpermissive]
osdopenvg.cc: In member function 'int OsdOpenVG::loadFont(bool)':
osdopenvg.cc:692:10: warning: unused variable 'n_point' [-Wunused-variable]
osdopenvg.cc:693:10: warning: unused variable 'last_cont' [-Wunused-variable]
osdopenvg.cc:749:8: warning: unused variable 'n' [-Wunused-variable]
osdopenvg.cc: In member function 'virtual ImageIndex OsdOpenVG::createJpeg(const char*, int*, int*)':
osdopenvg.cc:1147:7: warning: unused variable 'mem' [-Wunused-variable]
osdopenvg.cc: In member function 'unsigned int OsdOpenVG::handleTask(OpenVGCommand&)':
osdopenvg.cc:1037:1: warning: control reaches end of non-void function [-Wreturn-type]
make: *** [osdopenvg.o] Error 1


The version of gcc reports:

Code Select Expand


pi@raspberrypi ~/vomp/vompclient-raspi $ gcc --version
gcc (Debian 4.6.3-12+rpi1) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

pi@raspberrypi ~/vomp/vompclient-raspi $ g++ --version
g++ (Debian 4.6.3-12+rpi1) 4.6.3
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.


Any suggestions?

I have played around with adding all three types as shown below:

Code Select Expand


cec_config.deviceTypes.Add(CEC_DEVICE_TYPE_PLAYBACK_DEVICE);
cec_config.deviceTypes.Add(CEC_DEVICE_TYPE_RECORDING_DEVICE);
cec_config.deviceTypes.Add(CEC_DEVICE_TYPE_TUNER);


It sort of works. Once the correct input is selected on the tv all remote commands are sent. But there is a side effect: There are multiple AnyNet+ devices shown in the input menu of the tv. The input menu has to be rescanned in order to show the correct one and in the process removing the invalid one from the menu.

Directly after startup of vomp one will see the following two inputs - "vomp and Recorder". Or if the order of adding the devices are changed - "vomp and Tuner". For some reason the type "Player" is not shown no matter what the order is!

I still think the correct way is to announce vomp as a Recorder. As I understand it, a Recorder is acting as both a Player and a Tuner.

- Magnus

I can confirm that the implemented changes works with a vompclient connected to a Samsung UE46ES5505.

No need to force a specific hdmi mode any more.

I have similar experience with a Samsung TV. Testing supported modes using the 'tvservice -m CEA' command yield that both HDMI_CEA_1080p60 and HDMI_CEA_1080p50 were supported, among others, and that 1080p60 was the native mode that is also chosen automatically.

Playing video when in automatic mode did however result in a black screen. Tried forcing the mode to 1080p60 but that did not work either but setting it to 1080p50 give picture. This differs a bit from the results of clausmuus where the native mode appears to work in his case whereas in my case I had to force 1080p50.