Kodi Community Forum

Full Version: OpenELEC Testbuilds for RaspberryPi Part 2
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
(2014-03-21, 12:38)doveman2 Wrote: [ -> ]It seems the Pi is still clipping my black levels, despite setting
hdmi_pixel_encoding=2
in config.txt, which is meant to be RGB Full (0-255). I'm testing with a black clipping pattern showing levels 0-25 and when I play it from a USB stick on my TV, if I increase the brightness the lower bars will show up as grey rather than black but via the RPi, it doesn't change which bars are visible at all. Is there another setting in XBMC which would cause this?

I've also found that with my TV (Panasonic X60B plasma) that playing the pattern via the RPi and setting the brightness to +2 - +4 shows noise/snow (dithering?) all over the picture but playing it via the TV's USB port this doesn't happen. I also see this noise on the XBMC menu background.

EDIT: Another thing I've noticed is that the thumbnails in Videos - Files look like they've had the brightness boosted, so that they look very different to how they do when played. I took these screenshots in the list and with the videos playing to show the difference.

Image

Image

Image

Image

Someone from the AV Forums was kind enough to take a look at my screenshots and has observed:

'The Black Clipping thumbnail screenshot has black at 16, whereas the XBMC UI all around it has black at zero. So it would seem that the XBMC thumbnail generator captured the image using Video Levels, and something about it eliminated BTB, converting all values below 16 to 16. That is not a useful thing for it to do, as it makes it more difficult to set Brightness. Viewed on my PC monitor, the pattern appears gray, which is expected, for my PC desktop is at PC Levels, where black is 0. The desktop would have to be using Video Levels for this pattern to appear correct.

OTOH, the screenshot taken while the video was playing is at PC Levels, because examining the pixel values, Bar 16 and below have been mapped to zero, 17 has been mapped to 1, etc. This is the bottom end of what is meant by expanding Video Levels (16-235) to PC Levels (0-255). It looks like it should on my PC monitor, which again is at PC Levels. If the desktop were at Video Levels, blacks would appear crushed.'

I hope that's helpful.
(2014-03-24, 22:24)popcornmix Wrote: [ -> ]Nope it's not enabled.
Make sure "DTS capable receiver" is enabled in audio settings.
You may need to set settings level to advanced.

Thanks didn't concider the Advanced level.
Its now working.
Finally, it is working the way I want it to!

Here's the story and the results of my testings:

First to mention is, that I am using openelec with a Raspberry Pi. My goal is to connect my Raspberry Pi with my HiFi-System (to hear my .mp3 via WLAN). Problem is, that it is really old and has no HDMI-port. So I have to connect my HiFi-System with the the RPi via a Cinch - Headphone-cable. The result was disappointing (many strange sounds within the music), but the "installation" worked (NAS via WLAN -> HiFi-System plays .mp3).

Because of the bad sound quality I bought a cheap USB-Sound-Card (I am not audiophil). I used openelec Frodo 12.2, which recognised the USB-Soundcard immediatly... Result: Wunderful! I could hear my music cristal clear. (And in addition video-playback (even streaming via WLAN) and all the rest (pictures, airplay, ...) worked great for me.)

But then came Frodo 12.3 via auto-update (my fault, I didn't disable it). My USB-Sound-Card was no longer recognised... grrr (Who on earth decided that? I will never ever understand, when someone disables good features ...). I found some post which said that with Gotham it should work again. And Gotham should be released in the end of 2013... so I waited for Gotham.

In March 2014 (grr - until then I could hear music only with strange noises - yes, I used the RPi - headphone-jack again) the first beta of Gotham was released. Immediatly I installed it, but -another disappointment- my USB-Sound-Card was still not recognised. (The same in Beta 2).

Then -finally- I found this post. I installed the "prealpha" and my USB-Sound-Card is recognised and working perfectly. Everything is now working the way like in Frodo 12.2.

I would like to say THANK YOU!

Now, some comments:
+ It is possible that music only uses the USB-Sound-Card (and no HDMI), while movies only uses HDMI-audio (an no USB-Sound-Card). Great feature!

- I am using an android remote-app and an ipad remote-app to control openelec. Both are working, but if music is played and I change something in the playlist, there are breaks in the playback of music (which I never encountered before). (My guess is, that it has something to do with the cover-thumbnails which are uploaded to the remote-app. After the remote-app loaded the images everthing is working well again.)

Again, THANK YOU. Great work. (And please never ever disable USB-sound-card support again!)
(2014-03-25, 11:48)chaosensues Wrote: [ -> ]It is possible that music only uses the USB-Sound-Card (and no HDMI), while movies only uses HDMI-audio (an no USB-Sound-Card). Great feature!

+1
(2014-03-25, 12:12)BoBeRzE Wrote: [ -> ]
(2014-03-25, 11:48)chaosensues Wrote: [ -> ]It is possible that music only uses the USB-Sound-Card (and no HDMI), while movies only uses HDMI-audio (an no USB-Sound-Card). Great feature!

+1

+1 !!
Quick question for any of the Devs.
I have settled with the quartz reloaded skin as it hardly uses any resources.
I have been modifying the animations as they are pretty bad and have almost got to where I would like.
There is one problem which seems to be specific to the raspberry Pi and I was wondering if anyone could shed some light on what I can do.

Problem:
Running my test skin or default quartz reloaded skin;
Play a video
Pause video
Raspberry pi does not indicate PAUSED or show any SEEKING information
compared with my PC running the exact same skin, shows everything fine.

I will attach the pictures below to show my issue

Raspberry Pi
Image

PC
Image

and here is a log of the Pi playing the video then pausing
http://pastebin.com/pb3D9Zys

My guess is its something to do with the GL textures but I would like some advice if possible
@bagofcrap24: most likely an issue on case-sensitive filesystem's/OS's. make sure the textures have the right spelling.
(2014-03-25, 13:26)[email protected] Wrote: [ -> ]@bagofcrap24: most likely an issue on case-sensitive filesystem's/OS's. make sure the textures have the right spelling.

thanks for the quick reply but that shouldnt be an issue as I'm using texturepacker

Note: When using an XBT file in your skin, your file paths will not be case sensitive, even if your skin resides on a case sensitive file system!
(2014-03-25, 13:30)bagofcrap24 Wrote: [ -> ]Note: When using an XBT file in your skin, your file paths will not be case sensitive, even if your skin resides on a case sensitive file system!

thanks. I didn't know this.
(2014-03-25, 13:30)bagofcrap24 Wrote: [ -> ]thanks for the quick reply but that shouldnt be an issue as I'm using texturepacker

Note: When using an XBT file in your skin, your file paths will not be case sensitive, even if your skin resides on a case sensitive file system!

Do you have this problem with the standard/official OpenELEC builds? If so, it's OT for this thread.
(2014-03-25, 12:51)bagofcrap24 Wrote: [ -> ]and here is a log of the Pi playing the video then pausing
http://pastebin.com/pb3D9Zys

Code:
10:46:18  19.022640 T:3057111040   ERROR: unable to load:/storage/.xbmc/addons/skin.quartz.test/1080i/DialogSeekBar.xml, Line 0
                                            Failed to open file

I think you need to look very closely at that file and compare it to other files.
Either a permissions issue, the filename/path is wrong or there is something bad in the file (like a syntax error, incorrectly matched brackets or incorrect newlines).

Can you revert that file to the stock Quartz one and see if it loads?
(2014-03-24, 22:18)allan87 Wrote: [ -> ]I think guisettings.xml gets overwritten from some settings cache as part of a shutdown or reboot from the menu.

There may be another (better) way to preserve an edited guisettings.xml through a reboot, but the reboot command in a terminal session does the job.

If you want to edit guisettings.xml without xbmc overwriting your changes simply shut down xbmc first with "systemctl stop xbmc.service", then edit guisettings.xml, then finally start xbmc with "systemctl stop xbmc.service".
(2014-03-25, 13:39)MilhouseVH Wrote: [ -> ]Do you have this problem with the standard/official OpenELEC builds? If so, it's OT for this thread.
Just tested now and the issue was still there on standard build.
My appologies. I had assumed it was build specific as it was working on my PC but looks like popcornmix was correct.
thanks for your time looking at this.


(2014-03-25, 13:42)popcornmix Wrote: [ -> ]
Code:
10:46:18  19.022640 T:3057111040   ERROR: unable to load:/storage/.xbmc/addons/skin.quartz.test/1080i/DialogSeekBar.xml, Line 0
                                            Failed to open file

I think you need to look very closely at that file and compare it to other files.
Either a permissions issue, the filename/path is wrong or there is something bad in the file (like a syntax error, incorrectly matched brackets or incorrect newlines).

Can you revert that file to the stock Quartz one and see if it loads?

After replicating the problem on stock OpenELEC I had a closer look at the file you suggested.
Looks like the guy who did "Quartz Reloaded" had named it DialogSeekbar.xml instead of DialogSeekBar.xml
It's annoying because I had already tracked it down to the DialogSeekBar.xml that wasn't playing game and spent quite a while looking through the XML for problems but couldn't find any.
so again, apologies for wasting your time and I have learn't to pay more attention to the debug logs.

And looks like you was correct [email protected] images inside the Textures.xbt do not need to be case sensitive but everything else sure does haha.

Right. Enough OT

Thanks for your time
Just curious about something.

A clean install then update to the latest Millhouse build results in the rainbow splash, OpenElec screen, followed by a nice Gotham Freeze XBMC logo on boot.

An already existing install, followed by an update to the same Millhouse build, results in the rainbow splash, OpenElec, and then a generic XBMC logo?

Why is that? And out of interest where is the XBMC boot logo stored?
(2014-03-25, 18:12)evangelion Wrote: [ -> ]Just curious about something.

A clean install then update to the latest Millhouse build results in the rainbow splash, OpenElec screen, followed by a nice Gotham Freeze XBMC logo on boot.

An already existing install, followed by an update to the same Millhouse build, results in the rainbow splash, OpenElec, and then a generic XBMC logo?

Why is that? And out of interest where is the XBMC boot logo stored?

You had likely had a custom splash on at some point.

if you place a splash.png in /storage/.xbmc/media/ it will override the default xbmc boot splash.
as its in /storage it survives upgrades