Kodi Community Forum
OpenELEC Testbuilds for RaspberryPi Part 2 - Printable Version

Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166)
---- Thread: OpenELEC Testbuilds for RaspberryPi Part 2 (/showthread.php?tid=184866)



RE: OpenELEC Testbuilds for RaspberryPi Part 2 - FattyMcDirty - 2014-03-21

(2014-03-21, 13:31)spjonez Wrote:
(2014-03-20, 23:19)FattyMcDirty Wrote: Is anyone of you using the hyperion ambilight plugin withnthese builds? everythin was fine with an early march build 02.03. or so...in the latest builds, hyperion IS working after start, but stops working after few minutes of watching video. any1 here maybe got a clue what might be causing the issue?
I am, haven't noticed any issues so far. Have you tried updating Hyperion?


mh. no. but there doesnt seem to be a newer version, does it?


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - spjonez - 2014-03-21

(2014-03-21, 21:11)FattyMcDirty Wrote: mh. no. but there doesnt seem to be a newer version, does it?
Based on the commit history on Github it's updated quite regularly. I'd update first to see if the issue has already been sorted out, if not check the list of known issues and if you don't see one that matches your problem submit a bug report.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - ijsbeer79 - 2014-03-21

Hyperion is working fine here as well with the latests (and previous) builds.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - freaktm - 2014-03-21

Hi,

I'm pretty sure this isn't the correct place to report this, but I've been googling for days now, with no luck.

I'm having issues with CEC - specifically, accessing the settings in System > Input > Peripherals. The list is just empty.
My TV-remote works just fine, so the connection is allright.
I've tried deleting ~/.xbmc/userdata/peripheral_data/rpi_2708_1001.xmlm thinking it would reset to some default, but the file was just created again.
I've looked through advancedsettings.xml and guisettings.xml with no success.

I'm thinking it's an issue with my setup, maybe?

The pi is connected directly to my TV, on HDMI port 1.
It used to work in a build from a long time ago (last year, I think), and I haven't needed to look at it since. Now, though, I'd like my Pi to turn off with my TV.

Got any hints as to where I can look for answers?

Thanks in advance Smile


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-03-22

(2014-03-21, 23:40)freaktm Wrote: I'm pretty sure this isn't the correct place to report this, but I've been googling for days now, with no luck.

Try and reproduce the problem with the official OpenELEC 4.0 Beta2 build, and if the problem is still there then open a separate thread either in this sub-forum or on the OpenELEC forum, maybe also open an issue on the OpenELEC github.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2014-03-22

(2014-03-21, 19:41)popcornmix Wrote:
(2014-03-21, 18:28)doveman2 Wrote: It doesn't seem like the full range is being used for video playback though, as if it was I'd be able to see the bars below 16 when I increase the TV brightness, as I can when playing the files via my TV's USB port. What seems to be happening is that the output is being limited, so perhaps that full range setting that is available on the PC is hidden and defaulted to off on the Pi.

By default video files are limited range and shouldn't encode levels below 16.
You need a flag in the file (like video_full_range_flag for h264) to be able to encode these levels. Does your file have this set?

If you force a DMT mode (with hdmi_group=2) you will get full range by default. CEA modes will get limited range by default.
The full/limited range flag is correctly output by the Pi (in the AV infoframe), and the display should act on that (without requiring setting in menus on display or using hdmi_pixel_encoding on pi)
In our testing, many TV's only support limited range in CEA modes (which you are probably using at 1080p) and only full range in DMT modes (they are manditory, supporting full range with CEA and limited range with DMT is optional).

But I think all this talk is based on a misunderstanding. Full range does not give you more or better colours.
Assuming all parts are the system (the video file flags, the video player, the HDMI settings and the display) agree on whether they are using full or limited then the picture displayed on the display will be identical.

We have done a lot of testing of feeding encoded bars test files through the system, and using a hdmi capture card to confirm that the levels are correct in the full and limited range modes.
That is the only way to confirm that the Pi is outputting the correct signals. We did find in this testing that some TV's do clamp levels below 16, even when we are signalling full range.

I don't know about any encoding flags but as I said, playing the file from my TV's USB socket shows the bars below 16 if I increase the brightness, so clearly it isn't limited range (clipped below/above 16/235). I'm inclined to think that if the TV plays it full range, then the Pi should too. Certainly my TV doesn't clip levels below 16 anyway, at least not in Full mode.

I'm pretty sure the Pi is outputting full range when I use hdmi_pixel_encoding=2 even though I'm not forcing a DMT mode, as there's a noticeable difference in the brightness of the GUI. I'll try setting the mode though.

You seem to be saying that even if I don't set anything in config.txt then the Pi will output a full or limited flag depending on the material being played and that will switch the TV into the right mode. However, as I said I found that without the pixel_encoding=2 setting, my TV in Auto was incorrectly using Full and I had to set it to Normal, otherwise the GUI looks wrong, which means that the TV will stay in Normal mode regardless of any flag the Pi might send when playing video.

I know Full/Limited RGB range is nothing to do with colours. It's probably better described as PC levels (0-255) and Video levels (16-235) and I understand, from threads in AV forums, that outputting at PC levels (to a display that also uses PC levels) allows it to show the WTW (White than White, i.e. above 235) detail, which commercial DVDs often contain. This is just the first thread (discussing Super White mode on the PS3) I came across when googling but there are others on that forum if you want to search more
http://www.avsforum.com/t/967106/calibration-experts-please-help-rgb-full-vs-limited-on-ps3-and-display#post_14261877

If it has to compress 0-255 levels into 16-235, then you should see more or less the same detail at each end but due to the resulting fewer steps or gradients, then there may be a loss of "smoothness" in the middle. This might not be that noticeable to most people but some people might be more sensitive to it.

(2014-03-21, 20:08)host505 Wrote: That sounds right, also the test paterns above that doveman2 is running are just to adjust brightness/contrast (assuming all the parts agree on the color range as you said popcornmix) and do not indicate whether limited/full color range is used.

That's not really true as they show if the full 0-255 is being outputted (assuming the TV can also display the full range) or if the output is being clipped to limited 16-235.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - b1m1 - 2014-03-22

@popcornmix

Observation - Since version 315, size of xmbc has increase 7Mb - that's a big increase in 2 weeks.

Thanks for your hard work.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-03-22

(2014-03-22, 06:26)b1m1 Wrote: Observation - Since version 315, size of xmbc has increase 7Mb - that's a big increase in 2 weeks.

Presumably you are referring to the size of the tar?

The wlan-firmware package was updated on March 11 with a substantial number of new firmware blobs to support new hardware: https://github.com/OpenELEC/wlan-firmware/commit/e042dd1f9d30a210724006e8fd49f4cce760330f

This package was then included in the March 12 [#0312] build and the new firmware blobs almost certainly accounts for the 5MB increase at that time (110438400 [#0311] -> 115281920 [#0312]). Since then the tar size has increased another 2MB-ish.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - b1m1 - 2014-03-22

(2014-03-22, 07:02)MilhouseVH Wrote:
(2014-03-22, 06:26)b1m1 Wrote: Observation - Since version 315, size of xmbc has increase 7Mb - that's a big increase in 2 weeks.

Presumably you are referring to the size of the tar?

The wlan-firmware package was updated on March 11 with a substantial number of new firmware blobs to support new hardware: https://github.com/OpenELEC/wlan-firmware/commit/e042dd1f9d30a210724006e8fd49f4cce760330f

This package was then included in the March 12 [#0312] build and the new firmware blobs almost certainly accounts for the 5MB increase at that time (110438400 [#0311] -> 115281920 [#0312]). Since then the tar size has increased another 2MB-ish.

Hi, thankyou, that is good to know. I was wondering if the size increase would soon make openelec impossible to run on a 256Mb Pi.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2014-03-22

(2014-03-22, 08:46)b1m1 Wrote: I was wondering if the size increase would soon make openelec impossible to run on a 256Mb Pi.

Don't see why it should, the 256MB Pi has never been able to load SYSTEM into RAM so the OpenELEC distribution can continue increasing in size through the addition of optional extra modules and code without any significant risk to 256MB Pi users, it will just require more SD/Flash storage...

There's a free memory check when the system boots, and if there is less than 364544KB physical RAM free (or noram is present in cmdline.txt) then SYSTEM will not be loaded into RAM. I guess it's possible that eventually 512MB Pis may no longer be able to load SYSTEM into RAM but there's still a pretty long way to go before that happens on systems with 128MB allocated to GPU (which will have 384MB free). If the SYSTEM image grows to 150MB or so, then it may be time to stop OpenELEC from loading into RAM on 512MB hardware.

I added noram to cmdline.txt on my 512MB Pi a very long time ago and apart from the extra 100MB+ of physical RAM available I haven't noticed any other change, and my boot device is an old unidentified 2GB SD card that pre-dates the Class XX system!

Switching to a 256MB/256MB GPU split will also automatically stop SYSTEM from loading into RAM on 512MB devices.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - FattyMcDirty - 2014-03-22

(2014-03-21, 22:11)spjonez Wrote:
(2014-03-21, 21:11)FattyMcDirty Wrote: mh. no. but there doesnt seem to be a newer version, does it?
Based on the commit history on Github it's updated quite regularly. I'd update first to see if the issue has already been sorted out, if not check the list of known issues and if you don't see one that matches your problem submit a bug report.


but how do i update hyperion under openelec?
the installer i'm using downloads this package:
https://github.com/tvdzwan/hyperion/tree/master/deploy

its been updated 13 days ago.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - spjonez - 2014-03-22

(2014-03-22, 10:14)FattyMcDirty Wrote: but how do i update hyperion under openelec?
the installer i'm using downloads this package:
https://github.com/tvdzwan/hyperion/tree/master/deploy

its been updated 13 days ago.
Re-run the install script: https://github.com/tvdzwan/hyperion/wiki/Installation-on-RPi-with-OpenELEC


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2014-03-22

(2014-03-21, 19:41)popcornmix Wrote: If you force a DMT mode (with hdmi_group=2) you will get full range by default. CEA modes will get limited range by default.

Setting

hdmi_group=2
hdmi_mode=82

which should be 1080P makes it run at 640x480. I recalled it was possible to get the EDID information from the TV and I think this worked before when I used it but now I just get

> OpenELEC:/usr # tvservice -m DMT
> Group DMT has 0 modes:
>
> OpenELEC:/usr # tvservice -m CEA
> Group CEA has 0 modes:


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2014-03-22

(2014-03-22, 15:47)doveman2 Wrote:
(2014-03-21, 19:41)popcornmix Wrote: If you force a DMT mode (with hdmi_group=2) you will get full range by default. CEA modes will get limited range by default.

Setting

hdmi_group=2
hdmi_mode=82

which should be 1080P makes it run at 640x480. I recalled it was possible to get the EDID information from the TV and I think this worked before when I used it but now I just get

> OpenELEC:/usr # tvservice -m DMT
> Group DMT has 0 modes:
>
> OpenELEC:/usr # tvservice -m CEA
> Group CEA has 0 modes:

Remove the hdmi_mode/hdmi_group settings to see the full list.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - doveman2 - 2014-03-22

(2014-03-22, 15:52)popcornmix Wrote: Remove the hdmi_mode/hdmi_group settings to see the full list.

OK, thanks. Now I get

OpenELEC:~ # tvservice -m CEA
Group CEA has 16 modes:
mode 1: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 2: 720x480 @ 60Hz 4:3, clock:27MHz progressive
mode 3: 720x480 @ 60Hz 16:9, clock:27MHz progressive
(native) mode 4: 1280x720 @ 60Hz 16:9, clock:74MHz progressive
mode 5: 1920x1080 @ 60Hz 16:9, clock:74MHz interlaced
mode 7: 720x480 @ 60Hz 16:9, clock:27MHz x2 interlaced
mode 16: 1920x1080 @ 60Hz 16:9, clock:148MHz progressive
mode 17: 720x576 @ 50Hz 4:3, clock:27MHz progressive
mode 18: 720x576 @ 50Hz 16:9, clock:27MHz progressive
(prefer) mode 19: 1280x720 @ 50Hz 16:9, clock:74MHz progressive
mode 20: 1920x1080 @ 50Hz 16:9, clock:74MHz interlaced
mode 22: 720x576 @ 50Hz 16:9, clock:27MHz x2 interlaced
mode 31: 1920x1080 @ 50Hz 16:9, clock:148MHz progressive
mode 32: 1920x1080 @ 24Hz 16:9, clock:74MHz progressive
mode 33: 1920x1080 @ 25Hz 16:9, clock:74MHz progressive
mode 34: 1920x1080 @ 30Hz 16:9, clock:74MHz progressive

OpenELEC:~ # tvservice -m DMT
Group DMT has 5 modes:
mode 4: 640x480 @ 60Hz 4:3, clock:25MHz progressive
mode 9: 800x600 @ 60Hz 4:3, clock:40MHz progressive
mode 16: 1024x768 @ 60Hz 4:3, clock:65MHz progressive
mode 35: 1280x1024 @ 60Hz 5:4, clock:108MHz progressive
mode 81: 1366x768 @ 60Hz 16:9, clock:85MHz progressive

so it doesn't support 1080P in DMT mode and I believe that if I use anything other than 1080P, XBMC can't autoswitch the resolution/refresh rate to match the source material can it?


This forum uses Lukasz Tkacz MyBB addons.