[popcornmix]

Last I heard, the issue was in the R-Pi firmware, and there's nothing XBMC can do on our level. I don't really know how all that works or why that is, but I do trust the people who said it.

I investigated this. Manages to reproduce problem and got this log file:
https://dl.dropbox.com/u/3669512/temp/xbmc_headend.log

Lars said:

"This doesn't seem right to me.

23:49:32 T:2805740608 DEBUG: COMXPlayer::SetCaching - caching state 2
23:49:32 T:2805740608 DEBUG: OMXClock::OMXSetSpeed 0 buffering 0
23:49:32 T:2805740608 DEBUG: OMXClock::OMXSetSpeed 1 buffering 0
23:49:32 T:2778264640 DEBUG: COMXPlayerAudio - CDVDMsg:LAYER_SETSPEED
23:49:32 T:2805740608 DEBUG: Previous line repeats 1 times.
23:49:32 T:2805740608 DEBUG: COMXPlayer - CDVDMsg:LAYER_SETSPEED speed : 1000

caching state 2 = CACHESTATE_PVR
This means that player must be paused until the video and audio buffers
are filled up enough before starting to play the stream.
Last line from this paste indicates that playback is starting, before
caching state is set to CACHESTATE_DONE, and even before stream
descriptions are requested from demux.
So my best guess is that this is causing the problem."

which looks like an omxplayer problem.