[miappa]

No, you can´t do any of the things you suggest.
The only thing you can do is manually browse, but I wouldn´t do to much this way either since you can by accident mess up the permissions.
It´s better to SSH and SFTP to not mess up the permissions.

No, this is just a way to run xbmc (and raspbian) from another source than the SD card, just like the USB install.

[wimble]

Will try that sometime. Not sure if I even want that. But what makes me curious with NFS is this:

What can I do with XBMC on NFS if the Pi is powered off?
Nothing? Or is there a way I could give it a sign to update the video db?

Other thing? Could a XBMC be shared in this way? Say one on the Pi and one one the local Linux server and use the same space on disk?
Maybe stupid questions, but just curious...

You can directly access the .xbmc files. So you can read .xbmc/temp/xbmc.log from another machine, while the Pi is writing it (which might be useful, depending on what tools you've got on the other machines). You can also write to the userdata files, although there's no obvious advantage in doing so, compared with scp-ing directly to the Pi: they're not re-read except on boot (AFAIK).

You could in theory share the system partition between multiple Pi, and you could share the storage Partition *but* only if you either:
a) only use one Pi at a time, or
b) use a MySQL database (on a different machine),
since having multiple things writing to the local, SQLite database simultaneously is not supported (to the point where the DB could easily get corrupted).

But, to be honest, as miappa says, it doesn't give you a huge bonus, except to save you from wear and tear on the SD card, or for a speed boost: I've only got class 4 SD cards, so this runs about twice as fast, and when my Pi powers down abruptly, doesn't risk corrupt the file system. And it powers down abruptly all the time, since I'm powering it from a USB port on the TV...

[JeeGee]

Thx had the same thoughts about it.

It was more an idea to trigger it to update the video's, for example when a tv show is downloaded during the night.
Well leave it for what it it.

I use class 10 4 Gb SD, would XBMC on NFS be faster? Really faster?

[Dilligaf]

If you run separate home folders you can run multiple PI from one install. the advantage being when one is updated they all are

[miappa]

If you run separate home folders you can run multiple PI from one install. the advantage being when one is updated they all are

Simultaniously?

[Dilligaf]

Should be able to, just need to specify the home folder in cmdline.txt. I don't think it's officially supported so you would be somewhat of a guinea pig

[miappa]

Interesting, I plan to get another Pi and if so I will gladly be a guinea pig.
I have to solve my NAS problem first though, only FTP and SMB supported... I am thinking of trying out OpenWrt or DD-Wrt to be able to run NFS on my router, but everything else is working perfectly so I don´t know.

I am one of those few who had pretty much no problem with smb, but only the speed improvement might be worth it.

But it feels like some things would be problematic such as logs, if two clients update the library at the same time, export at the same time etc?

[s7mx1]

If you run separate home folders you can run multiple PI from one install. the advantage being when one is updated they all are

Simultaniously?

It's only the main OS. XBMC database will not however you can clever design it by utilizing symbolic and permission on nfs share, in that case you need only one client that can update xbmc database (let's call it master copy), then all other clients (multiple pi) will have their user's database symboliced to the master copy.

Raspbmc does support uniqute nfs home mount and all you need to do is append nfshome= entry in the cmdline.txt. The main rootfs can stay the same.


If you plan to run nfs on openwrt/dd-wrt make sure your router has at least 32MB memory and it has usb 2.0 port. The nfs speed can match class 6 sd card.

[Dilligaf]

I'm booting off a Linksys E3000 with DD-WRT with Optware installed only change on the router side was installing nfs in Optware and running it as root rather than as www-data user I'm running a MySql server off my Media Server for my xbmc library. You may have misunderstood my earlier statement in regards to updating, I was referring to updating the OS and not the xbmc library, the xbmc library is in the home folder so each instance would have its own library unless you were running MySql. You could probably run MySql off the router as well, I didn't look into it as I've been running it off my Media Server for what seems like forever

EDIT: s7mx1 beat me to it again

[miappa]

Thanks both, that cleared it a little bit more.
I think my first step will be a new server/NAS solution.
I stayed on this one for to long, but only because it has been very stable.

However, I have the first version of WNDR3700 and it has only 8MB memory, but I have read on forums that many have successfully updated to OpenWRT or DD-Wrt (and some mods such as Gargoyle) so I just might give it a go. Probably 8MB (and the poor processor) is not enough to get a good setup, but it might be worth trying before I go to the store. And it should be able to run SQL.

It would be a nice feature in XBMC though, have one "master" with write permission and set the others to clients with read only.
A "fake" database where the master keeps the clients updated (with addons as well) without having to set up a SQL server.
On exit it exports a .nfo file with all info for each client with info such as last played etc.

Then again, upnp... no big fan.

Ok, enough highjacking, thanks though.

Edit: correction, I probably have at least 32 MB ram, it's the flash memory that is 8.

[wimble]

It would be a nice feature in XBMC though, have one "master" with write permission and set the others to clients with read only.
A "fake" database where the master keeps the clients updated (with addons as well) without having to set up a SQL server.
On exit it exports a .nfo file with all info for each client with info such as last played etc.

If you really want to go that way:
1. Set up a single PI with an NFS boot, as per OpenELEC NFS Booting How-To. You'll have *two* NFS shares, one for the OS, and one for the UserData.
2. Set up a second PI, by copying the the two shares. Get them working independently first. Just to show you can.
3. move the OS share for the second to one side (rename it to .bak, or something), and replace it with a symlink to the first OS.
4. Check that they work again!
5. "Write something" to copy the userdata directory from the first setup onto the second periodically. But only when *neither* is in use. And, off the top of my head, I'm not sure how to tell whether they're in use!


A possibility would be to symlink the master directory into the subordinates. So they've got both .xbmc directories and .xbmc-master. And then put

Code:

[ `hostname` != 'master' ] && rm -fr .xbmc; cp -r .xbmc-master .xbmc

into the boot sequence (substitute the hostname of your master for the word "master"). When they're booting is the latest you want the data copied, and has the advantage that, at point, they're not yet running xbmc. But that doesn't protect you from the possibility that the databases are being written (at that precise moment) by the master, so you might get some odd results, if nobody can think of any better guard.

But, to be honest, if you're going to these lengths, it's going to be simpler to have one master, and one subordinate (which could possibly be loaded onto multiple Pies), and leave the master on, hosting the MySQL database!

[Milhouse]

And, off the top of my head, I'm not sure how to tell whether they're in use!

It's tricky, particularly finding a solution that works for all distributions.

"netstat -an | grep <ip address>" will determine if the client/slave has an active NFS connection to the NFS server. However, idle NFS mounts will be closed periodically so they won't always appear in netstat which could lead to false positives (or negatives, depending on how you want to interpret the results). Maybe there is a way to maintain a persistent NFS connection?

Alternatively, with OpenELEC, you have the autostart.sh script which could create a flag file to /storage to indicate the client is now "up", but unfortunately there is no corresponding "autostop.sh" to remove any such flag file when the client is shutdown... There's probably a way to create/delete the flag file in Raspbmc.

As a last resort, and perhaps actually the most reliable "server-side" method, you could just "ping" the various clients from the NFS server on a frequent basis, however this assumes your clients have static IP addresses (or their hostnames are unique and resolvable on your network). When they don't respond to a ping, you can assume they are down and sync their folder with that of "master".

A possibility would be to symlink the master directory into the subordinates. So they've got both .xbmc directories and .xbmc-master. And then put

Code:

[ `hostname` != 'master' ] && rm -fr .xbmc; cp -r .xbmc-master .xbmc

into the boot sequence (substitute the hostname of your master for the word "master").

Rather than use cp, you'd be better off with rsync, as this will be a much quicker.

Since not all XBMC distributions support rsync, the best solution would be to have the client/slave ssh into the NFS server during boot (authenticating with keys, so no password is required) and have the slave instruct the server to kick off the rsync process so that it runs entirely on the server.

Adding the following commands to autostart.sh for OpenELEC would do the job quite nicely, identifying each slave by its unique MAC address and then requesting the NFS server to sync master to the slave folder.

Using rsync the update would be pretty quick with next to no network traffic - running cp on the Pi would cause the entire "master" folder to be read by the Pi, and then written out again to the slave folder (so twice the network overhead, which will be considerable, potentially taking several minutes over the Pi's 100Mbit network!).

The same script should work for Raspbmc, however I'm not sure what the standard practice is for running jobs at boot (probably initd?)

*** NOTE: Use the following script with caution, as it can delete files... ***

Code:

#!/bin/sh

NFS_SERVER=root@freenas2
NFS_SHARE=/mnt/share/OpenELEC
HOME_PATH=Storage
XBMC_MASTER=rpi_master
THIS_SLAVE=rpi_slave

case $(ifconfig eth0 | grep -i 'hwaddr' | awk '{ print $5 }' | tr '[A-Z]' '[a-z]') in
    b8:27:eb:1e:df:b4) THIS_SLAVE=${THIS_SLAVE}1;;
    b8:27:eb:1e:ee:cc) THIS_SLAVE=${THIS_SLAVE}2;;
    b8:27:eb:3d:21:94) THIS_SLAVE=${THIS_SLAVE}3;;
    *) echo "Unknown XBMC slave - halting!";
       sleep 99999999;;
esac

ssh ${NFS_SERVER} "cd ${NFS_SHARE}; rsync -tprogl --delete ${XBMC_MASTER}/${XBMC_PATH}/.xbmc ${THIS_SLAVE}/${XBMC_PATH}; sync"

(Modify lines 3 through 7 to suit your own requirements). For Raspbmc, HOME_PATH should be set to "home/pi".

The script will sync just the .xbmc sub-folder of rpi_master to each slave (eg. rpi_slave1, rpi_slave2, rpi_slave3 etc.). The NFS server is called freenas2, and it is exporting /mnt/share/OpenELEC (within which are the folders rpi_master, rpi_slave1, rpi_slave2 etc.). Potentially this NFS information could be extracted from the kernel command line.

If it were possible for the server to reliably detect when the client is down, the server could simply kick off the rsync process itself for each "downed" client, though this still leaves a window (between runs of the update script) when a client is started and may not be in perfect sync with the master, in which case initiating the sync during boot is probably best (and actually the simplest) solution.

[Milhouse]

Here's a version of the sync script that configures itself almost entirely from the kernel command - just set the name of the XBMC_MASTER folder:

Code:

#!/bin/sh

XBMC_MASTER=rpi_master

for arg in $(cat /proc/cmdline); do
  case $arg in
    disk=*)
        NFS_OPTIONS="$(echo "${arg#*=}" | sed -r "s/.*=(.*)/\1/")"
        NFS_SERVER="root@$(echo "$NFS_OPTIONS" | awk -F: '{print $1}')"
        NFS_SHARE="$(echo "$NFS_OPTIONS" | awk -F: '{print $2}' | awk -F, '{ print $1 }')"
        XBMC_PATH=$(basename $NFS_SHARE)
        NFS_SHARE=$(dirname $NFS_SHARE)
        THIS_SLAVE=$(basename $NFS_SHARE)
        NFS_SHARE=$(dirname $NFS_SHARE)
        ;;
    nfsroot=*)
        NFS_OPTIONS="$(echo "${arg#*=}" | sed -r "s/.*=(.*)/\1/")"
        NFS_SERVER="root@$(echo "$NFS_OPTIONS" | awk -F: '{print $1}')"
        NFS_SHARE="$(echo "$NFS_OPTIONS" | awk -F: '{print $2}' | awk -F, '{ print $1 }')"
        XBMC_PATH=home/pi
        THIS_SLAVE=$(basename $NFS_SHARE)
        NFS_SHARE=$(dirname $NFS_SHARE)
        ;;
  esac
done

ssh ${NFS_SERVER} "cd ${NFS_SHARE}; rsync -tprogl --delete ${XBMC_MASTER}/${XBMC_PATH}/.xbmc ${THIS_SLAVE}/${XBMC_PATH}; sync"

NFS server name/ip address, NFS share, XBMC storage path and current slave name will be extracted from the kernel command line (nfsroot= for Raspbmc, disk= for OpenELEC).

Note for OpenELEC systems, this script assumes each slave contains a System and Storage sub-folder within each slave folder (ie. "disk=NFS=freenas2:/mnt/share/OpenELEC/rpi_slave1/Storage" in cmdline.txt). For Rasbpmc, it assumes a command line of the form "nfsroot=freenas2:/mnt/share/OpenELEC/rpi_slave1".