[Milhouse]

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.

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:password@freenas2/.xbmc/sources.xml</to>
      </substitute>

    <substitute>
      <from>special://masterprofile/addon_data/</from>
      <to>smb://user:password@freenas2/.xbmc/addon_data/</to>
    </substitute>
  </pathsubstitution>
</advancedsettings>

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!

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.