2013-12-31, 22:09
Loading 2686 movies might explain why it takes 18 seconds - when you said it was slow I kind of assumed you were talking about a small-ish number of movies. 2686 is actually quite a lot and given the nature of how XBMC is designed it means an awful lot of processing for the Pi, so the time taken is actually fairly reasonable.
It used to take a lot longer than this just to load the fileitem cache before Ben and popcornmix optimised the processing. It's possible that once the cache is loaded there is still a lot of number crunching (parsing) that has to take place, the question is whether all of it is absolutely necessary (possibly not, but identifying and eliminating the unnecessary cruft is a slow and tedious process).
As a reference, on my Pi (1GHz ARM) it takes about 4 seconds to cache 650 movies. So 9-10 seconds to cache 2686 movies is about what you might expect, or actually slightly better.
I should also point out that the build you are testing does not have all of the library performance optimisations (these are the "newclock3" patches you may see me and others referring to). This may explain the 8 second delay you are experiencing having loaded the fileitem cache, but before images are displayed:
On my Pi with 650 movies, there's a one-off extra delay of about 2 seconds when I first enter the movie library between the fileitem cache being populated and the first image displayed. Re-entering the movie library is usually much quicker at under 4 seconds before the first image is displayed. When you re-enter the Movie library, do you experience the same kind of delay? Try a Gotham build that has all the newclock3 performance patches.
Other than the extra 8 second delay which may be resolved by existing patches, overclocking your Pi will help to display the movie library more quickly. If you want really fast library access times with a large-ish library then x86 is likely your only option until XBMC improves the way it handles library access so that it can scale better as the library size increases.
Code:
11:51:42 T:3043635200 DEBUG: ------ Window Init (MyVideoNav.xml) ------
11:51:42 T:3043635200 INFO: Loading skin file: MyVideoNav.xml, load type: KEEP_IN_MEMORY
11:51:43 T:3043635200 DEBUG: CGUIMediaWindow::GetDirectory (videodb://movies/titles/)
11:51:43 T:3043635200 DEBUG: ParentPath = [videodb://movies/titles/]
11:51:44 T:3043635200 DEBUG: RunQuery took 865 ms for 2686 items query: select * from movieview
11:51:48 T:2816930896 DEBUG: Thread JobWorker 2816930896 terminating (autodelete)
11:51:48 T:2892260432 DEBUG: Thread JobWorker 2892260432 terminating (autodelete)
11:51:48 T:2867094608 DEBUG: Thread JobWorker 2867094608 terminating (autodelete)
11:51:49 T:2909037648 DEBUG: Thread JobWorker 2909037648 terminating (autodelete)
11:51:51 T:3043635200 DEBUG: Saving fileitems [videodb://movies/titles/]
11:51:51 T:3033527376 DEBUG: CAESinkPi:Deinitialize
11:51:51 T:3033527376 DEBUG: COMXCoreComponent::Deinitialize : OMX.broadcom.audio_render handle 0xb43c0a30
11:51:51 T:3043635200 DEBUG: -- items: 2686, sort method: 0, ascending: true
11:51:52 T:2909037648 NOTICE: Thread BackgroundLoader start, auto delete: falseIt used to take a lot longer than this just to load the fileitem cache before Ben and popcornmix optimised the processing. It's possible that once the cache is loaded there is still a lot of number crunching (parsing) that has to take place, the question is whether all of it is absolutely necessary (possibly not, but identifying and eliminating the unnecessary cruft is a slow and tedious process).
As a reference, on my Pi (1GHz ARM) it takes about 4 seconds to cache 650 movies. So 9-10 seconds to cache 2686 movies is about what you might expect, or actually slightly better.
I should also point out that the build you are testing does not have all of the library performance optimisations (these are the "newclock3" patches you may see me and others referring to). This may explain the 8 second delay you are experiencing having loaded the fileitem cache, but before images are displayed:
Code:
11:51:51 T:3043635200 DEBUG: -- items: 2686, sort method: 0, ascending: true
11:51:52 T:2909037648 NOTICE: Thread BackgroundLoader start, auto delete: false
11:52:00 T:2867094608 NOTICE: Thread JobWorker start, auto delete: true
11:52:00 T:2867094608 DEBUG: COMXCoreComponent::Initialize OMX.broadcom.image_decode input port 320 output port 321 m_handle 0xa6cf5be0
11:52:00 T:2867094608 DEBUG: COMXCoreComponent::AllocInputBuffers component(OMX.broadcom.image_decode) - port(320), nBufferCountMin(2), nBufferCountActual(2), nBufferSize(81920), nBufferAlignmen(16)
11:52:00 T:2867094608 DEBUG: COMXCoreComponent::Initialize OMX.broadcom.resize input port 60 output port 61 m_handle 0xa6cfa8e8
11:52:00 T:2867094608 DEBUG: COMXCoreComponent::Initialize OMX.broadcom.egl_render input port 220 output port 221 m_handle 0xa6cfaed8
...On my Pi with 650 movies, there's a one-off extra delay of about 2 seconds when I first enter the movie library between the fileitem cache being populated and the first image displayed. Re-entering the movie library is usually much quicker at under 4 seconds before the first image is displayed. When you re-enter the Movie library, do you experience the same kind of delay? Try a Gotham build that has all the newclock3 performance patches.
Other than the extra 8 second delay which may be resolved by existing patches, overclocking your Pi will help to display the movie library more quickly. If you want really fast library access times with a large-ish library then x86 is likely your only option until XBMC improves the way it handles library access so that it can scale better as the library size increases.
