I seem to have found a way to do this, albeit by using an external program to do the pre-buffering. It only works for streaming from HTTP servers (actually may work for FTP too?). And this solution is only tested for Linux (Ubuntu specifically) and on an Acer Revo.
The situation I have is: a powerline ethernet connection between the XBMC box and the media server; claims to be gigabit, actually just means >100MBit, and usually easily fast enough, but it can be variable, probably relating to what else is running on my mains.
Which means that often (and more often recently, trying to think what I got that's new and could be interfering) when starting to play 1080p videos on XBMC, it takes a minute or two of stuttering and struggling before settling down and playing OK. At which point I can skip back to the start and play from there and it's usually fine, but this is annoying. And I thought some kind of pre-buffering would help. Not even very much. Just enough to get it started.
XBMC doesn't do that internally, as established earlier in this thread.
But my media server actually serves out using a webserver over HTTP. (NB: I tried SMB but as well as encountering some filename mangling, I also still had this problem). So I thought, I'm using HTTP, what about using a web proxy running on the XBMC box itself?
And as I'm on Linux, the traditional option is a HTTP proxy daemon called squid. Probably doable on a mac too, but the following is for Ubuntu Lucid or Debian Squeeze onwards:
Install squid3
edit the squid.conf file, add the line:
Save and exit. Restart it.
Or to be specific for Ubuntu/Debian:
Code:
sudo su -
apt-get install squid3
echo 'read_ahead_gap 1 MB' >> /etc/squid3/squid.conf
service squid3 restart
Configure XBMC, in the network settings, set proxy to localhost port 3128.
That's almost it. As the machine actually isn't horribly short of memory I tried various options to let squid use more of it, but all it seemed to do was make it take *ages* to start playing, then takes 100% cpu after a few minutes of playback, at which point XBMC started running out of video and eventually gave up. In the end, the read_ahead_gap setting (and it being that low) was the only change from the default configuration I made.
Seems to work perfectly.
The one wrinkle I had was that squid doesn't resolve mDNS hostnames (ie: zeroconf/bonjour, when your machines are findable on your localnet using <hostname>.local). As that's what I was using in the video source URL to find the media server, that broke; and I didn't want to change the URL to something non-.local because it would lose my individual file playback settings.
I was able to fix it by putting an entry for that machine in the XBMC box's /etc/hosts. But it does mean the server has to be on a fixed IP address. In my case adding the line:
Code:
192.168.0.100 twilight.local
The IP address would differ for you. In fact it may differ for me in the future too as it just comes from DHCP, I probably now have to do something to make sure it's fixed.