• 1
  • 57
  • 58
  • 59(current)
  • 60
  • 61
  • 277
OpenELEC Testbuilds for RaspberryPi Part 2
rbej: Is the last Gotham build Alpha 7 or Alpha 8?
All builds.



I didnot understand!
I've been working on some jpeg decode/encode optimisations.
https://github.com/popcornmix/xbmc/commits/newclock3

I have a test build of this:
https://dl.dropboxusercontent.com/u/3669...r15977.tar

Note, this is for testers only. It is probably not stable.
It is top of tree OpenELEC and gotham xbmc with the patches from newclock3 applied.
It does does not have any of rbej tweaks.

However I've found it notacably faster, for example when scrolling in e.g. poster wrap view. I can scroll from end of list to other at full speed with no missing posters (with overclock naturally).

I repeat: this is for testers only. It is probably not stable.
(2013-09-26, 15:33)popcornmix Wrote: I've been working on some jpeg decode/encode optimisations.
https://github.com/popcornmix/xbmc/commits/newclock3

It certainly feels a bit snappier (1GHz Pi)!

Although I am seeing a bunch of errors (pastebin) while scrolling through Movies in Thumbnail view, with several of the thumbnails failing to appear (black rectangles). This is with /storage mounted over NFS, and all artwork items pre-cached.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2013-09-26, 16:52)MilhouseVH Wrote: It certainly feels a bit snappier (1GHz Pi)!

Although I am seeing a bunch of errors (pastebin) while scrolling through Movies in Thumbnail view, with several of the thumbnails failing to appear (black rectangles). This is with /storage mounted over NFS, and all artwork items pre-cached.

The 0x80001000 error is OMX_ErrorInsufficientResources, which is GPU out of memory. Can you try with a 256M/256M split for now?
(note after the error, it will fall back to arm based jpeg decode which is very slow).
(2013-09-26, 17:03)popcornmix Wrote: The 0x80001000 error is OMX_ErrorInsufficientResources, which is GPU out of memory. Can you try with a 256M/256M split for now?
(note after the error, it will fall back to arm based jpeg decode which is very slow).

Switched to 256MB GPU and it all seemed OK as I traversed end-to-end through my Movies library in Thumbnails view - no more black rectangles. Smile

However there were still a few OMX errors in the log which I have grepped out here. The complete log is too large for pastebin, I've zipped it up here if you want it.

Let me know if you want me to test further, or when to test with 128MB again.
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
@popcornmix / @abej

Do you think it is possible to get omxplayer to support gapless play back of audio tracks,

Or could we include another player that we can specify for just playing the audio tracks
which supports gapless play back (like the regular xbmc player) leaving omxplayer for
optimized video play back?

(I found hdmi_force_open=1 courses my rpi to crash if I try to skip forward or jump to next track :-()

Regards
JB
(2013-09-26, 17:22)MilhouseVH Wrote: Let me know if you want me to test further, or when to test with 128MB again.

The timeouts may be minor - I now allow multiple encodes/decodes to be submitted to GPU, which handles the locking.
It may just be the timeouts are insufficient when there is a queue of 4 jpegs in front. At least the fallback to software decode is working okay.

I'd be interested if you can see a difference between normal gotham and this buid - e.g. when scrolling through poster wrap view at full speed
(you'll need keyboard or remote app for this as CEC doesn't generate repeats quickly enough) - do you get all covers displayed in either case?

Also try a:
Code:
time ./texturecache.py C movies
it should be a little faster now (check it works though).
(2013-09-26, 17:51)javaboyuk Wrote: @popcornmix / @abej
(I found hdmi_force_open=1 courses my rpi to crash if I try to skip forward or jump to next track :-()

Certainly getting the equivalent of hdmi_force_open working is on my list (ideally from "keep receiver alive" option in GUI).
That's not the same as gapless (which actually does fading between tracks), but should improve music playback.
(2013-09-26, 19:45)popcornmix Wrote: The timeouts may be minor - I now allow multiple encodes/decodes to be submitted to GPU, which handles the locking.
It may just be the timeouts are insufficient when there is a queue of 4 jpegs in front. At least the fallback to software decode is working okay.

I'm seeing timeouts with:
Code:
./texturecache.py C movies

this is with just 2 download threads being used by texturecache.py, and the default 2 bginfoloadermaxthreads for XBMC (full log).

I can generate an increased number of timeouts by using more download threads, so your theory is most likely correct.

Question: Once the Pi has failed over to software decode, does it remain using software decode until the Pi is rebooted (or maybe just xbmc.bin restarted)? Is there a message written to the log once it fails over to software decode?

(2013-09-26, 19:45)popcornmix Wrote: I'd be interested if you can see a difference between normal gotham and this buid - e.g. when scrolling through poster wrap view at full speed
(you'll need keyboard or remote app for this as CEC doesn't generate repeats quickly enough) - do you get all covers displayed in either case?

With both Gotham and this build, using an IR remote control, I can get ahead of the Pis ability to decode and display thumbnails (by about "C" in the A-Z) - maybe this is because my Thumbnails cache is mounted over NFS?

With this new build, while browsing through the Movie thumbnails I am seeing occasional 0x80001000 errors in the log, also an 0x80001012 error (full log).
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2013-09-26, 21:38)MilhouseVH Wrote: Question: Once the Pi has failed over to software decode, does it remain using software decode until the Pi is rebooted (or maybe just xbmc.bin restarted)? Is there a message written to the log once it fails over to software decode?

After a decode failure:
20:00:31 T:2878022736 NOTICE: DecodeJpeg: unable to decode special://masterprofile/Thumbnails/3/383f6e26.jpg 480x720

It will try again using software decode. You will see a *slow* DoWork (it's normally below 100ms for me, although the DoWork message is supressed when below 100ms)
20:00:32 T:2878022736 DEBUG: DoWork - took 4206 ms to load special://masterprofile/Thumbnails/3/383f6e26.jpg

Software decode is taking 4 seconds per image!

The time will depend on fanartres/imageres and also file loading speed (so nfs will be slower).


(2013-09-26, 21:38)MilhouseVH Wrote: With both Gotham and this build, using an IR remote control, I can get ahead of the Pis ability to decode and display thumbnails (by about "C" in the A-Z) - maybe this is because my Thumbnails cache is mounted over NFS?
Perhaps I'll record a video of my setup. May tempt you away from nfs...


(2013-09-26, 21:38)MilhouseVH Wrote: With this new build, while browsing through the Movie thumbnails I am seeing occasional 0x80001000 errors in the log, also an 0x80001012 error (full log).

The 0x80001000 is a memory issue.
The 0x80001012 is purely a symptom of the previous timeout (we are shutting down not from the normal state - that is OMX_ErrorSameState).
(2013-09-26, 23:15)popcornmix Wrote: Perhaps I'll record a video of my setup. May tempt you away from nfs...

Heh, but only if you can also guarantee me no SD corruption! Smile

Or maybe I'll treat myself to a nice USB3 memory stick...
Texture Cache Maintenance Utility: Preload your texture cache for optimal UI performance. Remotely manage media libraries. Purge unused artwork to free up space. Find missing media. Configurable QA check to highlight metadata issues. Aid in diagnosis of library and cache related problems.
(2013-09-27, 00:35)MilhouseVH Wrote: Heh, but only if you can also guarantee me no SD corruption! Smile

Or maybe I'll treat myself to a nice USB3 memory stick...

Yes, USB is the best options. Max overclock and it has never corrupted.
(2013-09-25, 14:20)rterblanche Wrote: Why are there so few Gotham builds ? Have they gone into a freeze period for the GSOC 2013 changes ?

I was wondering this myself. I switched from the Gotham to Frodo build to benefit from the recent patches, so of course I then had to rescan all my video/music files to create the Frodo databases. The RPi I sent to my brother recently has the Gotham build on and it will take a long time to scan all his files again if I switch him to Frodo, so I was hoping to avoid having to do that.

I guess I could install a Frodo build on his PC and scan there but I'm not really sure which files I then need to copy across. I actually did this with the Gotham build as it would've taken too long to do the initial scan on the RPi, particularly the music files but it was trial and error working out which files needed to be copied. Is it just the MyVideosxx.db and MyMusicxx.db and Texturesxx.db or are there other files/folders (such as Thumbnails\) that need to be copied as well? I think it was the Thumbnails I had problems with before but that might have been because I hadn't copied the Texturesxx.db across.

Not that his PC is working at the moment as after tweaking it to perfection for him before sending it to him for his birthday, within half an hour he's managed to get it in a state where it BSOD every time he tries to boot, other than in Safe Mode without Networking, which obviously isn't much use! Not sure if it was one of the seven Windows Updates, the Avast update or the fact he managed to knock the power cable and kill the power whilst unplugging/replugging his printer's USB lead that did it Rolleyes
  • 1
  • 57
  • 58
  • 59(current)
  • 60
  • 61
  • 277

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi Part 223