Kodi Community Forum
OpenELEC Testbuilds for RaspberryPi Part 2 - Printable Version

+- Kodi Community Forum (https://forum.kodi.tv)
+-- Forum: Support (https://forum.kodi.tv/forumdisplay.php?fid=33)
+--- Forum: General Support (https://forum.kodi.tv/forumdisplay.php?fid=111)
+---- Forum: Raspberry Pi (https://forum.kodi.tv/forumdisplay.php?fid=166)
+---- Thread: OpenELEC Testbuilds for RaspberryPi Part 2 (/showthread.php?tid=184866)



RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-11-27

(2013-11-27, 23:16)MilhouseVH Wrote: I've repeated the testing twice, and chirping kicked in both times with 431595.

Thanks. At least my assumptions were true.

I've made a top of tree build with what I beleive to be the bad thing from 431595 reverted:
https://dl.dropboxusercontent.com/u/3669512/temp/start_434273%2B.elf

Is this okay?


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-11-27

Unfortunately, still chirping with 20 Nov 02:51 build and start_434273+.elf.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-11-27

(2013-11-27, 23:37)MilhouseVH Wrote: Unfortunately, still chirping with 20 Nov 02:51 build and start_434273+.elf.

Can you also add "hdmi_dma_waits=7"?


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-11-27

(2013-11-27, 23:46)popcornmix Wrote:
(2013-11-27, 23:37)MilhouseVH Wrote: Unfortunately, still chirping with 20 Nov 02:51 build and start_434273+.elf.

Can you also add "hdmi_dma_waits=7"?

That was with hdmi_dma_waits=7 - realised after the above post that I'd left it in my config.txt while performing the tests (if you want me to repeat the testing let me know!)

With hdmi_dma_waits=7 removed from config.txt, start_434273+.elf is still chirping.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-11-28

(2013-11-27, 23:47)MilhouseVH Wrote: With hdmi_dma_waits=7 removed from config.txt, start_434273+.elf is still chirping.

Hmmm, not expected. How about this:
https://dl.dropboxusercontent.com/u/3669512/temp/start_434273%2B2.elf


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-11-28

(2013-11-28, 00:09)popcornmix Wrote: Hmmm, not expected. How about this:
https://dl.dropboxusercontent.com/u/3669512/temp/start_434273%2B2.elf

That seems to have fixed it - no chirping! Smile

Tested without "hdmi_dma_waits=7".


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-11-28

(2013-11-28, 00:18)MilhouseVH Wrote: That seems to have fixed it - no chirping! Smile

Tested without "hdmi_dma_waits=7".

Okay, I'd still like to confirm hopefully a last version:
https://dl.dropboxusercontent.com/u/3669512/temp/start_434273%2B3.elf

Try without the hdmi_dma_waits=7 first, but add it if there's chirping.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-11-28

(2013-11-28, 00:29)popcornmix Wrote: Okay, I'd still like to confirm hopefully a last version:
https://dl.dropboxusercontent.com/u/3669512/temp/start_434273%2B3.elf

Try without the hdmi_dma_waits=7 first, but add it if there's chirping.

This seems OK too, I'm not getting any chirping and that's without hdmi_dma_waits=7.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-11-28

(2013-11-28, 00:33)MilhouseVH Wrote: This seems OK too, I'm not getting any chirping and that's without hdmi_dma_waits=7.

Thanks for your help. I'll push out an official firmware with that fix in.


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-11-28

(2013-11-28, 00:34)popcornmix Wrote:
(2013-11-28, 00:33)MilhouseVH Wrote: This seems OK too, I'm not getting any chirping and that's without hdmi_dma_waits=7.

Thanks for your help. I'll push out an official firmware with that fix in.

Excellent, many thanks - I'll put up a new build once the firmware is available (plus the newclock3 commits).


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-11-28

(2013-11-28, 00:41)MilhouseVH Wrote: Excellent, many thanks - I'll put up a new build once the firmware is available (plus the newclock3 commits).

Great. Latest commit may be interesting. Makes a noticable difference to max framerate:
https://github.com/popcornmix/xbmc/commit/77e723384027c6fb88bc961da90c073cc4057866


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - popcornmix - 2013-11-28

Firmware is updated:
https://github.com/Hexxeh/rpi-firmware/commit/9a96d713a10a82a026a3837fdbd84a6144d44a3a


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-11-28

OpenELEC web servers are down, not expected back until tomorrow - will try and cobble something together if I'm just missing firmware and xbmc packages, but may have to wait until their servers are back if I'm missing more. Sad


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-11-28

New OpenELEC Gotham build on *obsolete*.

Code:
rpi512:~ # vcgencmd version
Nov 27 2013 22:47:13
Copyright (c) 2012 Broadcom
version 95b18c7513b1cdd8ab76f541338f749285898fb7 (tainted) (release)
rpi512:~ # uname -a
Linux rpi512 3.12.1 #1 PREEMPT Wed Nov 27 23:09:45 GMT 2013 armv6l GNU/Linux
rpi512:~ # lsb_release
OpenELEC_Gotham (unofficial) - Version: devel-20131127234643-r16442

Based on tip of XBMC master (81a9c0c) and OpenELEC master (d1125a0) with the following modifications:
  • Includes latest firmware (7400b45) from master - initial testing confirms it's chirp-free!
  • Includes these newclock3 commits (except for 09445f5 which I've replaced with a static spinner)
  • Includes fix for consistent webserver/GUI artwork caching (PR:3671)
  • Excludes the fernetmenta patch as this conflicts with the newclock3 ffmpeg (ad5987e) patch
This build includes even more newclock3 performance improvements, and also the EDL fix for anyone that is able to test that.

Many thanks to popcornmix for squashing these bugs with such dedication, and Ben for eking out even more performance! Smile


RE: OpenELEC Testbuilds for RaspberryPi Part 2 - Milhouse - 2013-11-28

(2013-11-26, 15:05)MilhouseVH Wrote: There seems to be a problem with "rewind" on music - it always seeks forward (rather than backwards). Fast forward works correctly though.

Seeking in either direction works correctly with video media.

(testing with the build I posted up the other day)

Still having this problem with the latest build.

It's not the remote, as the seek dialog has the 1x/2x/4x/8x/16x/32x "bubble" moving to the left (not the right) and the dialog says "REWIND" (not "FAST FORWARD") yet the seek time is advancing (ie. moving forwards, not reversing).

Actually, seeking within music seems to be a little flakey in general. After pressing "fast forward" (1x) at the beginning of a song - which may be 3 minutes long - seeking will automatically end after seeking for a few seconds, playback will move on to the next song in the playlist before rapidly seeking through it (no seek dialog), then freezing playback at the end of this second song (the "Play" button is visible at the bottom of the screen along with the track title and timecode, the current position being at the end of the song and no further progress).