[popcornmix]

5) Increased iBufferSize and min_chunk_size in File.cpp to 256KB
6) Increased READ_CACHE_CHUNK_SIZE in FileCache.cpp to 256KB
7) Increased FFMPEG_FILE_BUFFER_SIZE in DVDDemuxFFmpeg.h to 256kB
8) Added READ_CACHED and READ_CHUNKED to if(fp->Open(filename)) in DVDInputStreamBluray.cpp (see DVDInputStreamFile.cpp)
9) buffermode 1 and 3MB cachemembuffersize and 99 readbufferfactor
10) reduced m_messageQueue.SetMaxDataSize to 15MB in DVDPlayerVideo.cpp (see OMXPlayerVideo.cpp)
11) increased m_messageQueue.SetMaxDataSize to 15MB in OMXPlayerVideo.cpp
11) sysctl net.ipv4.udp_rmem_min = 262144
12 sysctl vm.swappiness = 100
14) Removed most of the Sleep occurances in the OMXPlayer.cpp process while-loop.
15) Decreased thread priority for OMXPlayer.cpp to lowest possible.

Interesting. I'm guessing that not every change here is essential. Can you try reverting each of these changes one at a time and report if behaviour is okay or not?
It's possible one of these changes is producing the majority of the benefit and identifying that (with an aim to getting it submitted to xbmc) would be useful.

When filecache is enabled, the player seems to repeatedly loop and try to fetch data from the filecache, even if it is empty. This waste cpu cycles that are better spent by the filecache to fill itself, so therefor I changed the OMXPlayer thread to lowest possible priority and also removed most of the sleeps.

Again interesting. There is another report on the file cache producing high cpu usage in some situations (a radio stream, so presumably low bandwidth and therefore likely to be mostly running with an empty cache). How did you determine the repeated looping? Have you seen anything suspicious in the code?

<fanartres>1080</fanartres>
<imageres>720</imageres>

Increasing fanart resolution from the default on a 256M Pi wouldn't be recommended by me. This does significantly increase gpu memory usage. You might find reducing this (and rescanning the thumbnail cache) allows gpu_mem to be reduced, and so reduce the swap needed by the arm.

[Tompen]

There is another report on the file cache producing high cpu usage in some situations (a radio stream, so presumably low bandwidth and therefore likely to be mostly running with an empty cache). How did you determine the repeated looping? Have you seen anything suspicious in the code?

My thinking is like this: With filecache enabled, the memcpy done by filecache make Raspberry cpu limited. When filecache is empty, it is more important to read new data into the pi from our external media, compared to move the data from filecache to messagequeue. So therefor I reduce priority of the main omxplayer thread. When filecache is empty, everything the omxplayer thread does is a waste of cpu resources. But when filecache is waiting for io, those threads are blocked by WaitMSec until io arrive into some buffer. So at that moment in time we only have the vide+audio output to perform, and all the spare cpu cycles are spent by the low priority omxplayer thread to move data from filecache to messagequeue. I don´t know if my thinking is correct, but it seems to work fine at least for me.

It was 4 years ago when Filecache was implemented, see my comment here:
http://trac.xbmc.org/ticket/10779

The explanation below is from my memory when I attempted to investigate this 4 years ago (so it might be incorrect):

It is expensive to check if cache is empty, so in my personal build I only checked if cache is empty every x iternation of the loop (with a longer sleep).
But I am not c++ skilled enough to check if cache is empty when using CDVDInputStreamDVD or CDVDInputStreamBluray, so I gave up and made OMXPlayer.cpp loop to function as efficiently as possible (remove all Sleep), but only allowed to run on lowest priority. That seems to work best for me.

If investigating this, I suggest to change the codecinfo "cache:xxx bytes" information to only include data that is in the filecache. Today the "cache: " field display both data in messagequeue and the data in filecache, so it is hard to see when only filecache is empty. Then increase the Messagequeuesize to 150MB and connect a really old 10Mbit ethernet hub to limit your bandwith. Play movie, and keep an eye on both VQ and cache bytes. When I investigated this a few years ago: When filecache is empty, there was high cpu usage combined with stutter/dropped frames/jerky playback also during times when VQ and AQ does have data.

[popcornmix]

Didn't check memory use - don't even know chow to check it. It's Radio Eska Rock (http://s5.deb1.scdn.smcloud.net/t041-1.mp3) played from direct link (not from any add-on). Changed buffermode to 3 and for now everything seems to be OK, but I'll need some time to check it thoroughly.

Can you test latest milhouse build with buffermode enabled. I think I have a fix for this issue.