[negge]

As soon as I stumbled upon this project I had to try it on my raspberry pi media center (raspbmc), and share the experience.

I installed apache on the same 512MB v2 pi that hosts the master XBMC instance. Most videos are in usb drives local to the pi and some in samba network shares. Mysql proved to be too memory hungry for my pi, so I use the standard library for my fairly large collection of 4000+ videos. The paths, for both local and network files, are in samba form, because this library is shared with an XBMC instance on a Windows machine. This proved to be a security hole which I'll explain later.

Following the excellent instructions, the installation was smooth, and apache did not seem to burden my raspbmc too much. After changing the apache port and increasing the raspberry swapiness to 60, I was ready to try it. The web interface looks really good, but the pi is not strong enough to handle the internal streaming from XBMC to apache then to the client and it appears very sluggish, with images loading very slowly.

The images that XBMC returns from its API are in original form, meaning some are quite large. The application resizes each image the first time it is displayed and caches one copy per resolution. The resizing step is a bit demanding, especially on a computer like the Raspberry Pi. The alternative is to load the images directly which is very slow over the internet (individual images can be hundred of kilobytes in size).

Edit: I forgot to mention that once an image has been displayed and resized it will be cached in your browser, so the next time you visit the page the images will just show up instantly without the server having to do anything.

The security hole I mentioned before is that the initial source of the images contains the samba path of the image in this form:

/xbmc-video-server/src/thumbnail/get?path=image%3A%2F%2Fsmb%253a%252f%252fuser%253apass%2540host%252fc%252fpath%252fvideo-thumb.jpg%2F&size=116&type=movie

which reveals the user name and password used to connect to the share.

Edit: there's nothing can be done at the moment to prevent this. There is the "proxy location" setting that can hide the XBMC API credentials, but it won't do anything about smb:// paths. This is a problem with XBMC and not this application in particular. The "proxy location" setting only applies on vfs:// URLs at the moment, which is certainly something that could be improved.

The images are then cached, and the above redirects to the cached image, which improves the speed a bit, but is probably not the best mechanism, imho.

Like I said, the alternative to resizing then caching the images isn't much better.

Also, some video details pages returned a division by zero error, probably due to some missing metadata.

I'll look into that, thanks for mentioning!

I used my Windows laptop and Windows Media Player + KPLC as a client. I tried various types, avi, mp4, mkv, they all played, but some videos which stream fine, say in Android's Yatse, do not stream in this setup, i.e. they have to download entirely before they start playing. Others do stream ok although initial buffering is a lot slower (> 10x) than the one experienced with Yatse + MX Player using the same XBMC server/video. After this initial buffering, the videos played smoothly as long as their bitrate fitted the speed of the network.

Did you try VLC? I have not had much luck with any other player, including MPC-HC (especially not WMP, although I think it was a codec issue). I think I'll change the URL for the "Watch" button so it points directly to the video in question (not a playlist) if there's only one file, that could hopefully increase compatibility a bit.

Could you try to pin-point what kind of media require you to download the whole file before watching? I haven't experienced that issue at all myself.

Overall, the experience is that although usable for special cases, it's too slow for general use and you have to wait a lot before you can start the video. Although it is an interesting experiment, I think that a web interface for XBMC that exposes (safe) links to stream and/or download the videos/music would be a much better solution for most users.

I'm sorry to hear that the Raspberry Pi is too slow generally. I haven't done that much in the way of optimization on the whole application yet ("premature optimization is evil" etc.) but there are certainly a few areas I know could be improved.