sirwio

Commit 9a6411a2424f5ff0bfffd08a608417015d4ade99 miss to set the device type to "Recording device" if the logical address is 0x09.

Commit log below:
> hdmi_cec: determine device type based on logical address
> dreambox only, with other hardware we can read the device type

I'm investigating some hdmi-cec issues I'm facing on my vu+ ultimo.

Anyone out there has doc's or samples of the ioctl calls one can make to communicate with the hdmi-cec device.

Of interest would be:
* Get/Set ack bit part of the header block of the CEC frame.
* How to get the firmware version
* How to get vendor id
* How to set information i.e. the reverse command of ::ioctl(hdmiFd, 1, &addressinfo) used to get information.
* and others

I realize that what I'm requesting may not even be available or not known.

Btw. The issue I'm facing is that I cannot get the ultimo to be registered by my samsung tv as a recording device even though one send the "Report Physical Address" 0x84 with the correct recording device type set.


- Magnus

What is the current status on this. I have searched the forums and there appeared to have been discussion and tries to get this working on Samsung TV's in August 2011 when the hdmi-cec support was implemented.

Basically what was tried at that time was to override the type of the hdmi-cec device reported by the STB to be of type "recording device" and not as a "tuner".

I had similar problems with the play/stop/pause buttons in the vompclient project for the raspberry pi on my Samsung tv. The fix in that project was simply to change the type announced from tuner to recording device. That change made the buttons functional again. Forum thread where the problem was discussed can be found below.

http://forum.loggytr...msg3709#msg3709

I tried the same approach by modifying the enigma/lib/driver/hdmi_cec.cpp to no avail as was perhaps no surprise since the same approach had been tested when the module was initially written.

But the Samsung TV does definitely support the playback buttons when the hdmi-cec device announce itself as a playback or recording device - at least when the pulse-eight libcec library is used on the raspberry pi.

Any hints on how I can proceed troubleshooting this and if there has been any other findings in this area!

I have setup a build environment for OpenPLI 3.0. After some initial problems it builds.

Now I would like to make a small change to openpli/enigma2/lib/dvb/demux.cpp

How and where do I make that local change in my build environment?

I'm a total newbie building using bitbake so please forgive me if the question is stupid. I can take that :-) as long as you give me a pointer in the right direction.

- Magnus

I do observe problem with stutter while streaming 720p channels. Eg. SVT1 HD from Canal Digital Sweden DVB-S2. Other SD and 1080i channels stream fine.

While the stutter occurs I have observed the following in the enigma2 log:

[eFilePushThreadRecorder] Warning: All write buffers busy
[eDVBRecordFileThread] cancelling
[eDVBRecordStreamThread] failed to cancel, killing all waiting IO
[eDVBRecordFileThread] poll: aio_return returned failure: Interrupted system call
[eDVBRecordFileThread] poll: aio_return returned failure: Interrupted system call
[eDVBRecordFileThread] poll: aio_return returned failure: Interrupted system call
[eDVBRecordFileThread] Waiting for I/O to complete

And when the streaming is aborted:

[eDVBRecordFileThread] buffer usage histogram (4 buffers of 188 kB)
	  1:	165
	  2:	137
	  3:	  2
	  4:	  2

The above can be observed while e.g. streaming from a client on the network using the following command:
wget http://vuultimo:8001...:E080000:0:0:0: -O - > /dev/null

The warnings do not appear if the stream is collected locally on the ultimo host.

I suspect that network issues as well as client performance make the send buffers overflow while streaming. Note that recording the same channels work fine without stutter on playback even if recorded to a nas attached to the network.

Notice that it appears as if only 4 buffers are used. What is the reason for this?

Looking at the sources of demux.cpp I notices that the calculation/use of number of buffers differ if the stream is saved to file (while recording) and when streamed.

While recording the amount is determined by the amount of available memory. For the ultimo this appears to be 20 buffers. But when streamed the amount is hardcoded to be 4.

Would it make sense to modify the code in demux.cpp to use the same number of buffers as while recording or at least have it default to a higher number?