[godson]

Okay i'm very new to Raspberry Pi but i'm very interested in this latest build, however i'm very confused on what i need to do.
Can someone provide a step by step breakdown on what i have to do to get my raspberry Pi performing like the video.

[popcornmix]

I re-cached 638 movie fanart and 638 poster images and not a single error (other than the expected non-YUV complaint for Spider Man 3 fanart). Using just two threads, the average time to cache each fanart image is 1.33 seconds and 1.28 seconds for posters.

BTW, using 4 threads was significantly faster (with newclock3 code) than 2 threads.

[h.udo]

Okay i'm very new to Raspberry Pi but i'm very interested in this latest build, however i'm very confused on what i need to do.
Can someone provide a step by step breakdown on what i have to do to get my raspberry Pi performing like the video.

Read this. Download popcornmix's file and follow the instructions for your host OS. Beware these are development builds and prone to error and/or unexpected behaviour.

[Milhouse]

BTW, using 4 threads was significantly faster (with newclock3 code) than 2 threads.

Strange, for me 4 threads is slower than 2 threads, and 6 threads slightly better than x4 - on posters - but slower on fanart than x4.

One curious thing I have just noticed is that your latest build is re-encoding 1920x1080 fanart to 1280x720. even though fanartres is set to 1080:

Code:

<fanartres>1080</fanartres>
  <imageres>720</imageres>

I've extracted a sample of the log messages here, showing the results for both fanart and posters - the latter seem to be re-encoded OK (@720).

[mayoman]

Okay i'm very new to Raspberry Pi but i'm very interested in this latest build, however i'm very confused on what i need to do.
Can someone provide a step by step breakdown on what i have to do to get my raspberry Pi performing like the video.

Read this. Download popcornmix's file and follow the instructions for your host OS. Beware these are development builds and prone to error and/or unexpected behaviour.

Or wait a little.. Most of these changes will make their way into the official builds very quickly once they have been proven. I am not using the testbuilds, but am still seeing significant speed improvements with the latest official updates. To speed things up further in the meantime (if you are new to the Pi), I suggest playing with your overclock settings to find the fastest stable overclock for your particular Pi. Of course, if you have done this already apologes for stating the obvious.

[Milhouse]

@popcornmix: It seems that no matter what value I set for <fanartres>, fanart is always re-encoded at 720. <imageres> is working as expected though. This is with a 1080 GUI.

Edit: Rollox... the 720p GUI limit had somehow become re-enabled, probably while switching skins, so I was back to 720 and obviously that clamps the fanart encoding... though strange that it also ignored a value less than 720, ie. 512, and continued to encode 1280x720 images. After disabling the 720 GUI limit and restarting XBMC, fanart is now correctly re-encoding at 1080... means I need to re-do all the freaking testing... bah!

[popcornmix]

@popcornmix: It seems that no matter what value I set for <fanartres>, fanart is always re-encoded at 720. <imageres> is working as expected though. This is with a 1080 GUI.

Edit: Rollox... the 720p GUI limit had somehow become re-enabled, probably while switching skins, so I was back to 720 and obviously that clamps the fanart encoding... disabling the 720 GUI limit and restarting XBMC and now fanart is correctly re-encoding at 1080... means I need to re-do all the freaking testing... bah!

Are you 100% sure your GUI is 1080p?
I don't see any hard coded 1280x720, but it does limit the max cached image size to the gui resolution (which perhaps it shouldn't).

[Milhouse]

Are you 100% sure your GUI is 1080p?
I don't see any hard coded 1280x720, but it does limit the max cached image size to the gui resolution (which perhaps it shouldn't).

No it was my mistake, somehow the setting had reverted back to 720.

However, even when setting fanartres to 512, it still encoded fanart at 1280x720 - I'd expect the GUI limit to cap the fanart resolution, so not sure why it's unwilling to create a 512 version with the 720 limit in place. It looks like the only options for fanart encoding are 720, or if you're removed the 720 limit, 1080...

I've just finished another run re-caching 1080 fanart (1.86/s with 2 threads on USB) and again no problems. Scrolling quickly through the Movie library is all good too.

[frumpsnake]

Great work as always with the latest newclock3 builds popcornmix.

No issues with 256MB GPU mem, 1080 gui, 1080 fanart and 720 imageres, scrolling through quickly works fine. Don't own Spiderman 3 though

Off USB, texturecache.py is significantly faster with 4 threads for me as well.

[Milhouse]

but it does limit the max cached image size to the gui resolution (which perhaps it shouldn't).

My reason for whacking up the fanart and poster resolution is that I might be accessing the media library with a 1080p-capable tablet, and don't want to be faced with a tablet display full of horribly pixelated artwork (which certainly used to be the case with the default settings back in the day, but I notice 720 is now the default fanartres, although imageres is only 540).

When using a tablet to browse the library (and thus artwork), it doesn't seem appropriate to impose restrictions that are designed to optimise the performance of the Pi GUI display, which isn't being used...

So I would say "shouldn't", and let the user decide what works best for them and how they will be consuming the artwork.

[h.udo]

+1 for this.

No point in having excellent fanart and poster media if you can't view it in the best possible resolution in every machine you own.

[Swifty]

Anyone using PVR with the Raspi ?

After the seeing the video from popcornmix I'm quite pleasantly suprised by the Pi's performance.. but I wonder how it handles PVR / EPG timeline view - as the timeline view seems to require some fairly heavy lifting...

[godson]

Or wait a little.. Most of these changes will make their way into the official builds very quickly once they have been proven. I am not using the testbuilds, but am still seeing significant speed improvements with the latest official updates. To speed things up further in the meantime (if you are new to the Pi), I suggest playing with your overclock settings to find the fastest stable overclock for your particular Pi. Of course, if you have done this already apologes for stating the obvious.

What's the link to the latest official update/build?

[mayoman]

What's the link to the latest official update/build?

http://openelec.tv/get-openelec/viewcate...-pi-builds

If you enable auto update in the openelec settings & reboot (after waiting a few hours for it to check and download), it should then update automatically.

[godson]

People often complain xbmc on the Pi is too laggy to be usable.

Here is a demo of latest build running quite smoothly.

This is top of tree (Gotham) OpenELEC with some performance patches I'm currently working on.

The Movie played was 4 gigs and 720p.

The Pi is overclocked to 1GHz arm, 500MHz core and 600MHz sdram.
The install is on a USB stick.

http://www.youtube.com/watch?v=ErWF2sYgJec

Sorry popcornmix but where can i get those performance patches? i may give this a go tonight

---

What's the link to the latest official update/build?

http://openelec.tv/get-openelec/viewcate...-pi-builds

If you enable auto update in the openelec settings & reboot (after waiting a few hours for it to check and download), it should then update automatically.

ive got raspbmc install. but i will try this out tonight...