[Tander]

Thanks.

I will try it now.

So something like this:

1. Format the USB drive with a ext4 partition. (Or ext2, which ever)
2. Change the cmdline.txt to point at the USB drive
3. Move everything to USB drive
4. Keep the files mentioned by you on the SD card

?

[Milhouse]

Sounds about right. Not sure what you're going to do in step #3, but copying over the old .xbmc folder should be sufficient to get you back to where you were.

[Tander]

Okay maybe I am not clear what should go to the USB drive?

Just userdata?

[Milhouse]

As an absolute minimum, just the .xbmc folder (within which is your userdata folder, amongst other things). You might also want to copy over your .config folder.

[Tander]

Okay great. Let me see how this goes.

Thank you for your help - much appreciated!

[Tander]

Okay so I am almost there - so far in speeding up the Pi I have done the following:

1. Moved the DB to a MYSQL DB on a main server
2. Installed openELEC /Storage to a USB drive
3. Overclocked the PI
4. Updated to latest Gotham release

Now I need to kill the busy indicator - I can find this for skins downloaded - where is confluence's folder?

Busy downloading the modified version of the skin to try out.

[Milhouse]

Now I need to kill the busy indicator - I can find this for skins downloaded - where is confluence's folder?

It's in /usr/share/xbmc/addons/skin.confluence but of course that's in the read-only (squashfs) partition hence Neds suggestion to copy the entire skin.confluence folder to /storage/.xbmc/addons where you can modify it.

However if you're downloading the Confluence Modified skin you're unlikely to want to stay with stock Confluence for long!

[Tander]

Yeah, I figured that would be the case!

Going to edited the modified version then see if I can clock the Pi a little higher.

Will update once I am done.

By the way - your script for pre-caching the thumbnails - is this a performance improvement or just for errors in thumbnail art?

[Milhouse]

By the way - your script for pre-caching the thumbnails - is this a performance improvement or just for errors in thumbnail art?

Both. Pre-caching/loading all of the artwork will improve the user experience as you will then avoid any delays browsing the GUI while artwork is cached. There are also options to identify and fix artwork errors.

[Tander]

Okay cool. Will look into installing it.

---

Can I download the script then just copy it to the .xbmc/addons folder?

[JoeSchmuck]

So placing the data on the USB drive is faster, I can see that after reading this thread. But it also prevent SD corruption? I'll be looking for a thread on that, shouldn't bee too hard to find. I'm curious if you can write protect the SD card when using the USB flash drive. I also like the disabling of the Working spinner.

[privado]

I write protect mine, no problems so far.

[Milhouse]

The write protect tab on the SD card has no effect on the Pi as the read-write sensor in the slot is not wired up to anything.

Although the FAT partition can be mounted read-only, it's still possible to corrupt it when performing an update. I've even got one SD card here (Transcend 4GB) that no longer boots a Pi after a power cycle, but I've no idea why - it formats fine and there are no bad sectors etc, but it just won't boot.

Point is, although switching to USB (or NFS) will significantly reduce the chance of SD card corruption, I don't there's a way to eliminate it entirely (I think you can force SD cards to be read-only, which would make updating a problem, but that's a rather extreme solution).

[doveman2]

I run with

Code:

over_voltage=6
arm_freq=1000
core_freq=500
sdram_freq=600
force_turbo=1

force_turbo sets warranty bit, but improves performance.
Most Pi's handle this fine (I've got about 10 Pi's, and all handle this except an early one with Hynix memory which needs sdram_freq=500). You need a decent power supply.
The main issue is possible sdcard corruption, which the USB install avoids.

I haven't has a crash running xbmc in months, so yes it is stable.

With this overclock and a USB install my Pi is faster than my Apple TV2 and iPad 3 for most operations.

I'm currently just using

arm_freq=900
core_freq=333
sdram_freq=450

Is there likely to be a major difference bumping it up to your settings? I'd probably leave the force_turbo=1 out, just because this is for my brother and whilst I want it to be smooth, I also want it to be stable and last as long as possible Is it necessary to use over_voltage=6 with your settings or will it work, just not as fast, without that (and without force_turbo=1)?

I've been having a bit of remote lag (i.e. not always responding to commands), ghost remote presses, where it goes into a loop as if a key is being held down until I press a button a couple of times and odd freezes/reboots. I had a several minute freeze, I actually went and did something else as I got bored waiting, when I did Remove Source on a folder in Pictures and then later had a reboot going into Pictures. I was getting messages about the server not being available, which it wasn't as I was testing the Pi elsewhere, when deleting the folders so maybe that had something to do with it (when it restarted it said something like "Remote Server connection failed" as well). Had several reboots yesterday every time I tried to watch a channel with MediaPortal PVR and then had some more reboots just when selecting a folder in Movies or Music (but that may have been connected to having the MP PVR plugin enabled). The PVR was working much better this morning, with only one reboot when starting a channel and browsing Moives or Music seems to be OK now.

So I'm wondering if a better overclock might help reduce some of these problems?

I'm using a class 10 SD and a decent USB stick and have a hub powered separately from the Pi (using a 12v PSU into a 5v BEC like this https://dx.com/p/hobbywing-5v-6v-3a-swit...ubec-15149 ) that only has the remote receiver connected (although I plan to plug in a wired keyboard and sometimes a media USB stick).

[JoeSchmuck]

The write protect tab on the SD card has no effect on the Pi as the read-write sensor in the slot is not wired up to anything.

Point is, although switching to USB (or NFS) will significantly reduce the chance of SD card corruption, I don't there's a way to eliminate it entirely (I think you can force SD cards to be read-only, which would make updating a problem, but that's a rather extreme solution).

That is too bad that this device is so susceptible to file corruption. Guess I'll just work on minimizing the risk.

Thanks!