Messages

Got myself a new TV of the brand Samsung.  As if other parameters like picture quality wasn't enough when buying a TV now one must also check the hdmi cec compatibility. The sales guy was very helpful when I insisted on plugin in my raspberry pi to check hdmi cec compatibility. Running cec-client one could verify that the remote signals where passed to the pi.

Samsungs tradmarked hdmi-cec implementation is called Anynet+. It appears as if their implementation is a bit more to the spec than Philips' that I have explored on another TV in my household.

While firing up vomp I discovered that that while playing back recordings the play,pause,stop,forward,rewind buttons did not work as intended - In fact the TV informed me that they were unsupported!

Did a quick test changing the cec device type broadcasted by vomp from CEC_DEVICE_TYPE_TUNER to CEC_DEVICE_TYPE_RECORDING_DEVICE and got all buttons working as expected.

In fact this makes sense since its would be useless to send e.g. play command to a tuner! Whereas it makes sense on a recording device.

Did also make a quick check changing the type to CEC_DEVICE_TYPE_PLAYBACK_DEVICE and the result of pressing the record button had the TV inform me that it was an unsupported command. Play,pause etc worked fine in this mode.

I suggest changing the type vomp is broadcasting itself as, to be of type CEC_DEVICE_TYPE_RECORDING_DEVICE or make this a configurable setting in the advanced section.

There is always the option to remap one of the keys on the remote to act as the "Record" button. Done in the advanced menu.

My tv, a philips, also had an interesting option. One button on the remote is used to display status e.g. the current video mode etc. In addition to that it had the ability to show a virtual remote on screen with all possible remote commands drawn where one could choose the one of interest using the left/right navigation buttons. When OK is pressed the selected code is sent by the TV to connected hdmi-cec devices. (A bit hard to explain but I hope you get the idea).

Once I disabled the overscan in /boot/config.txt (disable_overscan=1) I got picture but it flickered.

But the hint by clausmuus really did help. Read about his suggestion to change the hdmi_mode in another thread but it didn't occur to me that this was an raspi setting (I thought it was a setting on his television set).

I checked the supported modes on my tv with:

pi@raspberrypi ~ $ /opt/vc/bin/tvservice -m CEA
Group CEA has 1 modes:
  (native) mode 31: 1920x1080 @ 50Hz, progressive

and set the corresponding entries in /boot/config.txt:
hdmi_group=1
hdmi_mode=31

With these changes the picture is now nice and stutter free.

Thanks everybody for your help.

Its a black picture - not blue or white. Did a reboot but it did not help. After a while the tv informs that the video mode is not supported (or a similiar message but in swedish).

Isn't it strange though that the build before the openvg osd commit shows video? Could it perhaps be video memory related.

Before fiddling with the memory settings I will make a clean build to see if that sorts things out.

There is only a black screen during playback or live tv. Playback and live tv worked before the following commit:

commit 419964cd6d85419684918774f4ddc420714f616a
Author: Marten Richter <marten.richter@freenet.de>
Date:   Wed Oct 3 22:05:15 2012 +0200

    Switch to OpenVG based OSD, note Teletext and Subtitle rendering not working and little bugs in implementation

I have uploaded a short snippet (57mb) of a recording (Dallas) that can be downloaded from here:
http://ubuntuone.com/1jMt7qGGmdhIQMRNK6R3xJ

The log file from the playback is attached.

Probably unrelated but perhaps an issue as well is that I do see messages like the one below on stderr. These messages does also appear prior to the commit 419964cd6d85419684918774f4ddc420714f616a so I don't think its the problem for me.

[mp3 @ 0x7e3ba0] incorrect frame size

- Magnus

Walter: I'm pretty sure you didn't apply my attached patch correctly. When you tried compiling it you show output compiling vmedialist.cc - That is one of the files excluded from the compile in the attached patch.

Also when Marten applied some of the changes to the head of the branch a small mistake slipped through in the osdmvp.cc file. The createNewSurface method shall read:

Surface * OsdMVP::createNewSurface()
{
  return (Surface*)new SurfaceMVP();
}

Did a quick test changing the device type between CEC_DEVICE_TYPE_TUNER, CEC_DEVICE_TYPE_PLAYBACK_DEVICE and CEC_DEVICE_TYPE_RECORDING_DEVICE. It did not have any impact on the message sent when pressing the Channel Up button.

Thanks for the pointers. Have for the last hour read the libcec api headers and might write a small test application to see whether its possible to switch between device types on the fly. It appears so.

But first I will follows your suggestion to actually check if the device type does change the command sent to the device.

On my Philips TV remote the buttons Channel Up/Down and Skip Left/Right are on the same place on the remote.

While watching recordings we usually skip forward using the Skip Right button to skip the commercials :-). This does however not work on the raspi vompclient with my philips remote.

Could it be that the vompclient need to announce itself as being in different modes depending on where in the UI one are navigating. E.g while watching live tv its obvious that a press on the buttons mentioned above shall result in a Channel Up/Down message whilst in recordings and perhaps elsewhere in the menus one shall receive Skip Left/Right messages.

Sorry if this is totally of bound on how CEC and libcec is supposed to work but I'm a total noob in this area.

Another problem with the remote is that there is no "Record" button making it impossible to set a show from the program guide to be recorded. Any suggested workaround for this?

That was likely the reason why I did exclude vmedialist.o vcolourtuner.o vmediaview.o vvideomedia.o mediafile.o from the makefile then...

I just removed them since I noticed they were not present in the vompclient.git project. Did not even try compiling with them so its possible there was no need to remove them.

Apply the attached patch. This patch is in no way intended nor reviewed to be going into master of the raspi branch but you will be able to build a dongle.

As described in another post on the mvp forum, http://forum.loggytronic.com/index.php?topic=630.0, I have had some problems with mvp client stability using the git version of vompserver.

This turns out to be related to the vdr version. My problems got solved when downgrading from 1.7.30 to 1.7.25. Worthwhile  to mention is that the downgrade of vdr also solved the freeze on the raspi when fast forward/rewind was done on recordings.

SOLVED - Turns out its the vdr version that is causing the freeze.

Remember I mentioned that we got occasional freezes on our stable rig as well. Turns out that when the stable rig got updated to run vdr 1.7.30 it got the same kind of issues. Reverting back to ver 1.7.25 resolves the problem.

With vdr 1.7.25 on the raspi rig in now performs as expected with both mvp clients and raspi clients. Will monitor stability over the next following days.

A guess is that the streaming format got changed in versions post 1.7.25 that the vompclient software does not account for.

I did actually try that already and it didn't resolve the issue. There were only minor changes required to get it to compile. Don't recall me doing any change in the threadp implementation though so it may be that I didn't patch it correctly. Will take another look at threadp.cc

One change that I'm not too sure about if it was correct was to change the CLOCK_MONOTONIC -> CLOCK_REALTIME as argument to clock_gettime.

Will continue to test over the day to see if I spot anything.