sirwio

Hooked up my raspberry pi to the same tv to be able to analyse a bit in more details what was send on the line from the vu+ ultimo. A bit surprising was that a request sent from the pi <Give Physical Address> 0x83 to the ultimo did get the ultimo to send a proper <Report Physical Address> 0x84. I had patched the driver to send the type recording device (1) and not the type tuner reported by the cec device on the ultimo when queried using ioctl calls.

Something is fishy. I will monitor the startup sequence of the pi when it announces itself as a recording device to see if I can spot any differences.

I also hope to get some progress in my effort of porting the libcec library to the ultimo.

No difference but its a nice plugin to monitor the messages sent/recevied between the cec devices. Sort of an expected since one would assume that the hdmitest plugin is using the same hdmi userspace driver as implemented in enigma2.

Samsung appears to be implementing the hdme-cec very much by the book. If a device announce itself to be of type tuner it will simply only make available buttons on the remote that make sense for a tuner device.

I suspect that one need to change the type and logical address of the cec controller before reporting the physical address to the tv since it appears the type and logical address are ignored/overridden when sending a "report physical" address message. The chip does when queried always report the type to be a tuner.

To set/change the type one may need to use ioctl calls. Problem is that I can't find any documentation on these. Or it may be that its not possible to set. In that case one would need to contact vu+ to have them change the type from tuner to recording device in the kernel module.

which stb do you have?

Vu+ Ultimo.
OpenPLI updated 2013-02-11 but with the kernel demux buffer bumped to 4MB and the streaming buffer count set to 20 the resolve some issues streaming 720p channels.
The TV is a Samsung UE46ES5505

check http://ftp.sunet.se/...gick/delegates/ you can see libpng-1.5.13.tar.bz2

also you can update to 1.5.14

Sure - and using the ftp.sunet.se version is what I did as shown in the post made earlier. The point is that the current build system is broken. Its not possible to make a clean build!

So I have made some tests increasing the buffer count while streaming from the default value using 4 buffers.

With 20 buffers there are still occasional hickups but much less frequently.

Bumped it to 40 buffers and it streamed fine without any stutter from two 720p channels concurrently. One to an xbmc client and the other dumping the stream to /dev/null using wget. I noticed though that the buffers where close to filling up since between 34 and 39 buffers where reported having hits when the streams where closed.

[eDVBRecordFileThread] buffer usage histogram (40 buffers of 188 kB)
	  0:	  1
	  1:	544
	  2:	453
	  3:	  7
	  4:	  7
	  5:	  6
	  6:	  8
	  7:	  6
	  8:	  6
	  9:	  6
	 10:	  5
	 11:	  6
	 12:	  7
	 13:	  7
	 14:	  7
	 15:	  7
	 16:	 10
	 17:	  7
	 18:	  7
	 19:	  5
	 20:	  6
	 21:	  6
	 22:	  4
	 23:	  4
	 24:	  4
	 25:	  5
	 26:	  5
	 27:	  1
	 28:	  1
	 29:	  2
	 30:	  2
	 31:	  2
	 32:	  2
	 33:	  1
	 34:	  2
	 35:	  2
	 36:	  1

Is increasing the buffer count a viable solution or do you pro's still think its a network related issue?

Anyone else having success streaming 720p channels without stutter from vu+ ultimo?