[popcornmix]

Would it be possible (if you have the time) to post a brief description of what some of these diagnostic items mean? I've seen this wiki page but suspect it's a little out of date, and some fields don't apply to omxplayer. I'm most interested in understanding how the buffer values may relate to any cache values specified in advancedsettings.xml.

The most important settings are vf and af. They are video fifo fullness, and audio fifo fullness. This fifo is between the ARM and GPU. If this ever reaches zero then we underrun and stutter.
Ideally one of these will always be approximately 100%. This fifo contains a few seconds of buffered data, and that means the GPU can happily continue playing for that time, however busy the ARM is.
The audio data here is after audio decode.

Next most important are vq and aq. These are video queue and audio queue. This queue is between demuxer and video and audio threads (all on arm).
Ideally one of these will always be approximately 100%. This queue contains a few seconds of buffered data to handle stalls in file access.
The audio data here is before audio decode.

I believe the buffer % (e.g. 0 B 99%) is just the max of vq and aq.

Generally when CPU is the limiting resource (e.g. software decoding of multichannel audio) then the audio fifo will drain first.
When file (e.g. nfs) bandwidth is the limiting resource (e.g. wifi connection) then the audio/video queues will drain first.

There is also an additional buffer, which traditionally was only enabled for "internet" sources (basically urls that started with http://).
This buffer is three times the value of cachemembuffersize in advancedsettings.
I believe the new setting alwaysforcebuffer means the "internet" buffer is applied to all files which can help slow network (e.g. wifi) setups.
I believe the "0 B" number is the size of the "internet" buffer is in use.

By default the ffmpeg demuxer limits the rate at which a file is read to approximately the maximum bitrate.
I'm not sure why that would ever be desirable, but apparently gigibit ethernet + slow CPU can spend all its time filling buffers and none decoding.
But with the Pi's 100Mbit ethernet, I don't see that as a problem.
readbufferfactor allows that limit to be increased.