Kodi Community Forum
OpenELEC Testbuilds for RaspberryPi - 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 (/showthread.php?tid=140518)



RE: OpenELEC Testbuilds for RaspberryPi - Wanderlei - 2012-10-23

@tha_lode

Try r12015, although I have not used it extensively for the same purpose as you. it is my favorite build so far.


RE: OpenELEC Testbuilds for RaspberryPi - tha_lode - 2012-10-23

Thanks man. I'll look into it tonight!


RE: OpenELEC Testbuilds for RaspberryPi - johnnyvd - 2012-10-23

(2012-10-23, 08:32)tha_lode Wrote: Thanks man. I'll look into it tonight!

Please post if this version still shows low-res jpg's. Also, are you updating or fresh installing?

I use the latest builds, but still have problems with low-res jpg's. I never seem to manage to show a single picture in its original resolution.
(i promised popcornmix to upload a jpg, will do that soon)

Must say i always "updated" openelec instead of doing a clean install. Maybe that is the problem..




RE: OpenELEC Testbuilds for RaspberryPi - johnnyvd - 2012-10-23

(2012-10-11, 14:10)popcornmix Wrote:
(2012-10-11, 10:22)johnnyvd Wrote: but what i meant was that my digital photographs in the pictures sections are shown blurry when i want to watch them. I do not mean the thumbnails (which i also do not auto-generate by the way).

The strange thing is that *sometimes* (once in a hundred) a picture gets shown right.. It seems that this depends on the size of the pictures (pixels).
The pictures is shot with my 450D (12MP) show blurry while the ones i took with my old IXUS 400 (4MP) are ok..

Okay, higher resolution photos shouldn't be more blurry, although possibly the high MP photos are hitting some memory limit and being downsized.
Post a link to a photo that is appearing blurry, and I'll look into it.

I will PM you one of the problematic jpg pictures.


RE: OpenELEC Testbuilds for RaspberryPi - tha_lode - 2012-10-23

I'll see if I can provoke the problem,and send you one as well.

I'm new to this scene, (got my RPi two weeks ago) and still haven't found a distro that does what I need it to do, so I'm still trying new images and fresh installs every time. (I must have tried over twenty versions now. Xbian, RaspBMC and openelec. Kinda tiresome.)

However: I cant seem to find the r12015 version mentioned. The site lists r12014 and r12016, but not the one I want.
http://openelec.thestateofme.com/

Where should I look? Google seems unable to locate it.


RE: OpenELEC Testbuilds for RaspberryPi - azraleus - 2012-10-23

(2012-10-23, 13:28)tha_lode Wrote: However: I cant seem to find the r12015 version mentioned. The site lists r12014 and r12016, but not the one I want.
http://openelec.thestateofme.com/

I'm using this site:
http://sources.openelec.tv/tmp/image/archive/ and there is r12015.

I did not know page ..thestateofme.com



RE: OpenELEC Testbuilds for RaspberryPi - Goofy2 - 2012-10-23

(2012-10-23, 13:28)tha_lode Wrote: I'll see if I can provoke the problem,and send you one as well.

I'm new to this scene, (got my RPi two weeks ago) and still haven't found a distro that does what I need it to do, so I'm still trying new images and fresh installs every time. (I must have tried over twenty versions now. Xbian, RaspBMC and openelec. Kinda tiresome.)

However: I cant seem to find the r12015 version mentioned. The site lists r12014 and r12016, but not the one I want.
http://openelec.thestateofme.com/

Where should I look? Google seems unable to locate it.

I would try even the older ones than r11392, which introduced ALSA. Alsa caused several issues for music playback, but the recent versions works quite fine. Anyway the xbmc freezing during the picture slideshow on top of music playback is there for long time. I haven't tested the pre-alsa releases too much. Random picture low-resolution issue was there even before the 720p display ratio bug. I sent one problematic picture to popcornmix, however I haven't raised a bug report yet.
An old post from sraue - excerpt taken from http://www.raspberrypi.org/phpBB3/viewtopic.php?f=35&t=7167&start=300:
Quote:by sraue ยป Sat Jun 23, 2012 10:33 pm
Hi,

Another short update (r11392):

http://sources.openelec.tv/tmp/image/op ... 92.tar.bz2
to update a older build without reinstalling see: http://wiki.openelec.tv/index.php?title ... g_OpenELEC

- updated XBMC (including Thumbnail rotation and Overscan fixes) many thanks to 'gimli'
- added experimental ALSA support, Menusounds and Music is now done via ALSA, this *maybe* provides USB speaker/soundcard support thanks to Gimli
- Kernel linux 3.2.21 many thanks to 'bootc'
- various other improvenments and fixes



RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2012-10-23

(2012-10-22, 21:28)popcornmix Wrote: Can you run
Code:
sudo vcdbg reloc
when the errors first start to appear and post the output.

I grabbed 3 extracts, all taken while "insufficient resources" errors were being displayed in the xbmc log (example error at top of pastebin #1). Hopefully they prove useful to you!

pastebin #1
pastebin #2
pastebin #3

This was on a 512MB Pi, gpu_mem=128, metadata library on MySQL, media files accessed via NFS.

Code:
root ~ # vcgencmd version
Oct 19 2012 23:40:40
Copyright (c) 2012 Broadcom
version 345130 (release)



RE: OpenELEC Testbuilds for RaspberryPi - popcornmix - 2012-10-23

(2012-10-23, 16:31)MilhouseVH Wrote: I grabbed 3 extracts, all taken while "insufficient resources" errors were being displayed in the xbmc log (example error at top of pastebin #1). Hopefully they prove useful to you!

Okay, so it is confirmed we are out of memory.

I can see triple buffered framebuffer (1280x720x32bpp =3.5M each)
There is one 8M buffer which looks like a 1920x1080x32bpp texture, which I'm surprised about (as textures should be limited to 1280x720).
Possibly that was a progressive jpeg which goes through a different code path.

But that still leaves perhaps 13 fanart textures? That seems like an awfully high number.
Do you have:
<bginfoloadermaxthreads>2</bginfoloadermaxthreads>
in advancedsettings.xml ?

Also if you run with:
gpu_mem=384
Does it run forever, or just for longer before hanging? (Trying to work out if it is leaking textures, or just using a fixed number that is too high).

Code:
[  12] 0x193863a0: used 1.0M (refcount 1 lock count 0, size 1048576, d3ruA) '0x1812b684'
[  15] 0x19668b80: used 3.5M (refcount 1 lock count 0, size 3686400, d1Rua) '0x181278a0'
[  16] 0x199edb80: used 3.5M (refcount 1 lock count 0, size 3686400, d1Rua) '0x181278a0'
[  17] 0x19d72b80: used 3.5M (refcount 2 lock count 8, size 3686400, d1Rua) '0x181278a0'
[  76] 0x1a0f7b80: used 3.6M (refcount 1 lock count 0, size 3768320, d1rua) '0x1808c5f4'
[ 142] 0x1a490b80: used 3.4M (refcount 1 lock count 0, size 3579904, d1rua) '0x1808c5f4'
[ 140] 0x1a7fbb80: used 2.9M (refcount 1 lock count 0, size 3014656, d1rua) '0x1808c5f4'
[ 147] 0x1aadcb80: used 2.9M (refcount 1 lock count 0, size 3014656, d1rua) '0x1808c5f4'
[ 149] 0x1adbdb80: used 2.9M (refcount 1 lock count 0, size 3014656, d1rua) '0x1808c5f4'
[ 151] 0x1b09eb80: used 2.9M (refcount 1 lock count 0, size 3014656, d1rua) '0x1808c5f4'
[  28] 0x1b37fb80: used 2.0M (refcount 1 lock count 0, size 2097152, D1Rua) '0x180e5a68'
[ 106] 0x1b57fba0: used 2.9M (refcount 1 lock count 0, size 3014656, d1rua) '0x1808c5f4'
[ 163] 0x1c6ddba0: used 2.9M (refcount 1 lock count 0, size 3014656, d1rua) '0x1808c5f4'
[ 158] 0x1c9beba0: used 5.9M (refcount 1 lock count 0, size 6160384, d1rua) '0x1808c5f4'
[ 183] 0x1cf9fba0: used 2.9M (refcount 1 lock count 0, size 3014656, d1rua) '0x1808c5f4'
[ 195] 0x1d280ba0: used 5.9M (refcount 1 lock count 0, size 6160384, d1rua) '0x1808c5f4'
[ 201] 0x1db85600: used 5.9M (refcount 1 lock count 0, size 6160384, d1rua) '0x1808c5f4'
[ 129] 0x1e166840: used 2.9M (refcount 1 lock count 0, size 3014656, d1rua) '0x1808c5f4'
[  98] 0x1e447840: used 2.9M (refcount 1 lock count 0, size 3014656, d1rua) '0x1808c5f4'
[ 162] 0x1e728f00: used 8.0M (refcount 1 lock count 0, size 8355840, d1rua) '0x1808c5f4'
[ 189] 0x1ef21f00: used 2.9M (refcount 1 lock count 0, size 3014656, d1rua) '0x1808c5f4'
[ 175] 0x1f202f00: used 2.9M (refcount 1 lock count 0, size 3014656, d1rua) '0x1808c5f4'
[ 185] 0x1f5a9240: used 2.9M (refcount 1 lock count 0, size 3014656, d1rua) '0x1808c5f4'



RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2012-10-23

(2012-10-23, 17:55)popcornmix Wrote: But that still leaves perhaps 13 fanart textures? That seems like an awfully high number.

This is what I do, which may explain the 13 fanart textures:

1) Scan media library to MySQL (although local database would probably be fine too)
2) For various reasons - corrupt ext4, new build, torture test OMX... - I delete Database/Textures*db and the Thumbnails folder, and reboot/restart XBMC
3) I click on the Movies menu item, and browse my movies in "Thumbnail" view

The Thumbnails view is two rows of 5 thumbnails each, with fanart behind for the currently selected movie. Most of my fanart is 1920x1080, and thumbnails 1000x1500.

While I'm browsing through the Movies, the Pi is having to re-size and cache the thumbnails/fanart images from NFS to local storage. The "Thumbnails" view may explain why there is such a high number of fanart images, as XBMC is (I believe) reading ahead of where I am in the movie list. This is perhaps the ultimate torture test for OMX, but it's my preferred view so is my most basic test. As I mentioned previously, an earlier build (I think r11904?) was actually pretty good on this view, I hesitate to say flawless, but it really was that good.

(2012-10-23, 17:55)popcornmix Wrote: Do you have:
<bginfoloadermaxthreads>2</bginfoloadermaxthreads>
in advancedsettings.xml ?

I do, as it's the OpenELEC system default:

Code:
root ~ # cat /usr/share/xbmc/system/advancedsettings.xml
<?xml version="1.0" encoding="UTF-8"?>
<advancedsettings>
  <!--<loglevel>1</loglevel>-->
  <splash>false</splash>
  <cputempcommand>cputemp</cputempcommand>
  <gputempcommand>cputemp</gputempcommand>
  <showexitbutton>false</showexitbutton>

  <destroywindowcontrols>false</destroywindowcontrols>
  <fanartheight>540</fanartheight>
  <thumbsize>256</thumbsize>
  <bginfoloadermaxthreads>2</bginfoloadermaxthreads>
  <useddsfanart>true</useddsfanart>

  <video>
    <defaultplayer>omxplayer</defaultplayer>
    <defaultdvdplayer>omxplayer</defaultdvdplayer>
  </video>

  <audio>
    <defaultplayer>omxplayer</defaultplayer>
    <streamsilence>false</streamsilence>
  </audio>

  <network>
    <cachemembuffersize>5282880</cachemembuffersize>
  </network>

  <samba>
    <clienttimeout>30</clienttimeout>
  </samba>

</advancedsettings>

And this is my advancedsettings.xml - nothing unusual here:

Code:
root ~ # cat .xbmc/userdata/advancedsettings.xml
<advancedsettings>
  <loglevel>0</loglevel>

  <splash>false</splash>
  <showexitbutton>false</showexitbutton>

  <gui>
    <algorithmdirtyregions>3</algorithmdirtyregions>
    <nofliptimeout>0</nofliptimeout>
    <visualizedirtyregions>off</visualizedirtyregions>
  </gui>

  <samba>
    <clienttimeout>30</clienttimeout>
  </samba>

  <videodatabase>
    <type>mysql</type>
    <host>freenas2-jail</host>
    <port>3306</port>
    <user>xbmc</user>
    <pass>xbmc</pass>
  </videodatabase>

  <musicdatabase>
    <type>mysql</type>
    <host>freenas2-jail</host>
    <port>3306</port>
    <user>xbmc</user>
    <pass>xbmc</pass>
  </musicdatabase>

  <pathsubstitution>
    <substitute>
      <from>special://masterprofile/sources.xml</from>
      <to>smb://user:[email protected]/.xbmc/sources.xml</to>
      </substitute>

    <substitute>
      <from>special://masterprofile/addon_data/</from>
      <to>smb://user:[email protected]/.xbmc/addon_data/</to>
    </substitute>
  </pathsubstitution>
</advancedsettings>

(2012-10-23, 17:55)popcornmix Wrote: Also if you run with:
gpu_mem=384
Does it run forever, or just for longer before hanging? (Trying to work out if it is leaking textures, or just using a fixed number that is too high).

gpu_mem=384 is a huge improvement! I made it through the entire library with only two or three errors. And it was fast! Smile

Here's the vcdbg while taken while I was moving through the movie thumbnails (no errors at this point), with the Pi resizing and caching new thumbs and fanart: pastebin.

With gpu_mem=384 I was able to browse through to the end of the movie list - 376 items - and the only errors in xbmc.log were as follows:

Code:
17:49:05 T:1235235936  NOTICE: Thread Background Loader start, auto delete: false
17:49:07 T:1235235936  NOTICE: Thread Jobworker start, auto delete: true
17:49:25 T:1235235936   ERROR: COMXCoreComponent::SetParameter - OMX.broadcom.resize failed with omx_err(0x80001018)
17:49:25 T:1166980192   ERROR: COMXCoreComponent::DecoderEventHandler OMX.broadcom.image_decode - OMX_ErrorPortUnpopulated port 0, cannot parse input stream
17:49:26 T:1235235936   ERROR: COMXCoreComponent::GetInputBuffer OMX.broadcom.image_decode wait event timeout
17:50:34 T:1100161552  NOTICE: Samba is idle. Closing the remaining connections
17:51:00 T:1221842016  NOTICE: Thread Jobworker start, auto delete: true
17:51:42 T:1100161552  NOTICE: Previous line repeats 1 times.
17:51:42 T:1100161552  NOTICE: NFS is idle. Closing the remaining connections.
17:52:05 T:1178059872  NOTICE: Thread Jobworker start, auto delete: true
17:52:05 T:1166980192  NOTICE: Previous line repeats 1 times.
17:52:05 T:1166980192   ERROR: COMXCoreComponent::DecoderEventHandler OMX.broadcom.image_decode - OMX_EventError detected, nData1(0x80001005), port 0
17:52:05 T:1178059872   ERROR: COMXImage::Decode m_omx_decoder.WaitForEvent result(0x80001005)
17:52:05 T:1166980192   ERROR: COMXCoreComponent::DecoderEventHandler OMX.broadcom.image_decode - OMX_EventError detected, nData1(0x80001005), port 0
17:52:08 T:1235235936   ERROR: COMXCoreComponent::GetInputBuffer OMX.broadcom.image_decode wait event timeout
17:56:08 T:1221842016  NOTICE: Thread Jobworker start, auto delete: true
17:56:50 T:1100161552  NOTICE: NFS is idle. Closing the remaining connections.
17:57:09 T:1212400736  NOTICE: Thread Jobworker start, auto delete: true

Not resource errors, which is surely a good sign - might just be weird images it had trouble decoding (not sure which ones, though).

For reference, here is the vcdbg reloc having just booted the Pi and before caching any images: pastebin

And here is the vcdbg reloc, having finished caching 376 items and returned to the main menu (5 "Recently added movies" thumbnails visible, plus the "bubbles" background image): pastebin.


RE: OpenELEC Testbuilds for RaspberryPi - fernandovg - 2012-10-23

Offtopic:

MilhouseVH,
whats the impact of dirty regions on 1080p/30 videos? Any quality loss ?
I saw the wiki but I didn't understand the real impact on quality

Thanks



RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2012-10-23

I don't think it has any impact on videos, it's meant to improve the GUI performance - without it the entire GUI would be redrawn at 60fps, with dirty regions only the "dirty" (changed/active?) part of the GUI is redrawn, significantly reducing the workload.

Good point though, as I'd forgotten I still have that in my advancedsettings.xml, and I'm really surprised to see that it's not been added to the system default (on R-Pi).


RE: OpenELEC Testbuilds for RaspberryPi - fernandovg - 2012-10-23

thanks!

Is this option the reason of grey frames while seeking the video (after I seek +60sec for example, when It starts play again, I get grey frames for a seconds - until the entire frame changes)


RE: OpenELEC Testbuilds for RaspberryPi - Milhouse - 2012-10-23

No, this option has nothing to do with video playback.

I don't know if a fix is planned (or even possible) for the grey frames. The problem when seeking is the lack of key frames - when one finally comes along, the whole image is corrected. Maybe omxplayer should only seek from key frame to key frame, assuming that is even possible.


RE: OpenELEC Testbuilds for RaspberryPi - popcornmix - 2012-10-23

(2012-10-23, 19:14)MilhouseVH Wrote: The Thumbnails view is two rows of 5 thumbnails each, with fanart behind for the currently selected movie. Most of my fanart is 1920x1080, and thumbnails 1000x1500.
Okay. So xbmc will have 10 thumbails in memory for current display, and possible the next row of 5 (and possible prev row of 5) ready for scrolling.
Obviously if you have 5 thumbnails across a 1280x720 GUI buffer, there's no point them being wider than 256 pixels, so that's one possible fix.

So, the 5.9M texture is probably a 1000x1500 progressive jpeg that didn't get clamped.
the 8.0M texture is probably a 1920x1080 progressive jpeg that didn't get clamped.
1000x1500 thumbnails should get clamped to 480x720 or about 1.5M, but we're not seeing that, so something else is happening.

(2012-10-23, 19:14)MilhouseVH Wrote: <fanartheight>540</fanartheight>
<thumbsize>256</thumbsize>
I have a feeling these aren't being respected. That's worth looking into. Possibly they are only acted on when storoing images to Textures*db. Perhaps we need to apply those limits on initial decode.

(2012-10-23, 19:14)MilhouseVH Wrote: gpu_mem=384 is a huge improvement! I made it through the entire library with only two or three errors. And it was fast! Smile

Not resource errors, which is surely a good sign - might just be weird images it had trouble decoding (not sure which ones, though).

And here is the vcdbg reloc, having finished caching 376 items and returned to the main menu (5 "Recently added movies" thumbnails visible, plus the "bubbles" background image): [url=http://pastebin.com

We've actually got more than 256M free so at this point we'd be okay on a 256M board, but I'm sure the memory use was higher earlier on.
Okay, there's evidence that there isn't a texture leak - just xbmc (with your settings) is trying to hold onto too many textures at once.

After you've produced a successful Texture*db cache with the 384M GPU split, is browsing reliable after rebooting with 128M?


This forum uses Lukasz Tkacz MyBB addons.