Kodi Community Forum
OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 1 - 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 (Kodi 15.0) Part 1 (/showthread.php?tid=211501)



RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Claudio.Sjo - 2015-03-25

Hi,
I wish to highlight a problem that happens in the version #0321 but not on previous version.
It's about CD Rip feature, it has stopped working with that version, I reverted to #0312 and it works perfect.

I am going to test #0324 now.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Claudio.Sjo - 2015-03-25

Very good!
The CD Ripping is back working with the version #0324

I wonder what was the issue with #0321.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - popcornmix - 2015-03-25

(2015-03-25, 16:32)slack3r Wrote:
(2015-03-25, 13:48)popcornmix Wrote: Can you confirm if #322 is good/bad?
Is bad:
http://sprunge.us/jePQ

Could you test #322 with start.elf and fixup.dat from #321 copied over?
I'd like to confirm if this is a firmware or kodi issue.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Calcifer-73 - 2015-03-25

Hi everybody,
I've a strange stacking problem with some files and maybe smarter people than me can help.
Moreover it's very easy to reproduce.
Just take 3 files , rename them as folowing
[HorribleSubs] Sora no Method - 01 [720p].mkv
[HorribleSubs] Sora no Method - 02 [720p].mkv
[HorribleSubs] Sora no Method - 03 [720p].mkv
Turn stacking on.
Accesse those files in file mode (don't scrape them) and you will see just 1 file (weird isn't it ?).
Now remove the letter "d" of method ( like this: [HorribleSubs] Sora no Metho - 01 [720p] ) for each files and it doesn't stack anymore (weirder isn't it ?).
The problem is those files doesn't match the naming pattern for stacking.

I've tested it on intel nuc with openelec 5.0.6 and on a pc with windows 7 and kodi 14.2 (My apologies I don't have a raspberry but I think this behavior will likely be the same).

PS: I've just tested to replace the letter "d" by another letter and it didn't stack , it really has to be the word "method".
It's as if the word is interpreted as a command of some sort.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Milhouse - 2015-03-25

@Calcifer-73 - please start a separate thread, probably in OS Independent, as this has nothing to do with these test builds.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Calcifer-73 - 2015-03-25

@Milhouse - I've done that a month ago but nobody seems very interested Sad

Sorry for having polluted your thread.


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - zaphod24 - 2015-03-25

You might open a trac ticket at trac.kodi.tv and see if you get any interest since it sounds like a kodi bug


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - doldi - 2015-03-25

Hello,
i've a little problem with this new build:
I cannot connect with my 2 Rasdpberries (typ 2) over SMB to my windows7 comp.
First run over WLAN, second over networkLANcable ...

No probs to connect over putty 0.63 / network install manuell with ip-adress from Rasperies.

But the connections was in the paste allways shown under network on my PC - now is there nothing :-)

The 2 Raspies see also nothing from my Videos, Pictures and Musik from the PC.

(sorry abaut my terrible english)

All that things run in the past without problems - is that a BillGates feature? :-) :-)

Thanks for your hard working.

Harald


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Milhouse - 2015-03-25

@doldi: please upload a debug log (wiki). Also, try restarting your Windows PC just in case that's gone haywire. If that has no effect, you'll need to go back through the builds to find the last working build (although I'm not having any SMB/Windows 7 problem here with #0324).


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Calcifer-73 - 2015-03-25

(2015-03-25, 22:13)zaphod24 Wrote: You might open a trac ticket at trac.kodi.tv and see if you get any interest since it sounds like a kodi bug

Thanks for the tip , I will do it !


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - doldi - 2015-03-25

ok - the bad windows world - all works perfect now. thx Mihouse for Feedback (Windows update make me some trouble)


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Milhouse - 2015-03-26

New OpenELEC Isengard build #0325: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 3.19.2 #1 Wed Mar 25 21:17:18 GMT 2015 armv6l GNU/Linux

# vcgencmd version
Mar 25 2015 19:09:30
Copyright (c) 2012 Broadcom
version f014c026d788d7aca1eba59371a4f7fb31136d79 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150325211627-#0325-ge60b369 [Build #0325]

# vcdbg log msg 2>&1 | grep DTOK
001667.338: Kernel trailer DTOK property says yes

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (e60b3691, changelog) and tip of XBMC master (7bb2fd48, changelog) with the following modifications: Build Highlights:
  1. New firmware
    popcornmix Wrote:I did watch the whole of Edge of Tomorrow last night in 3D/MVC with DTS-HD, and it was flawless.
    I did need to up h264_freq a fraction - h264_freq=275 was enough. Without that I got a handful of frame skips.
    Might be able to avoid that with more frames of buffering.

    Unfortunately h264_freq on it's own isn't enough, as you need force_turbo=1 (even with MVC+dtshd we don't tend to trigger turbo on pi2).
    I might allow h264_freq_min to be set above 250 which would allow some overclock without force_turbo.
Build Details:
  1. Firmware (Mar 25):
    • firmware: arm_loader: Refactor freq/freq_min logic and allow h264 freq_min to be increased
    • firmware: arm_loader: Allow non-turbo voltage to be increased by up to two config steps
    • firmware: video codec: refactor userdata release mechanics in categoriser
    • firmware: hvs: experimental: reduce hvs non-panic priority on 2836
    • firmware: arm_loader: Add force_eeprom_read setting
    • firmware: bootcode: Add bootcode_delay for an early delay. See: link
    • firmware: dispmanx: Fix stereoscopic flags to invert left/right eyes with multichannel. See: link
    • firmware: [deinterlace] Avoid asserts on half rate deinterlace
    • firmware: [audioplus] Limit samplerate/channels to something we expect to be able to support through hdmi
    • firmware: [deinterlace] Fall back to fast algorithm in a cleaner way
    • firmware: MMAL opaque - reduce back below 128 btyes. See: link
    • firmware: arm_loader: Avoid double-free when disabling HAT overlay, and always relocate overlay phandles
    • firmware: vc_pool_image: add locking around linked image release
  2. OpenELEC:
    • linux-imx6: update to latest stable/linux-3.14.y - Linux 3.14.36 (PR:4036, 1 commit, 12 files changed)
    • ffmpeg: move pkg-config to configure (PR:4039, 1 commit, 1 file changed)
  3. XBMC:
    • [Keyboard Layouts] Add missing characters in German and Greek keyboards (PR:6318, 2 commits, 2 files changed)
    • [readme.md] Updated link to coding guidelines (PR:6806, 1 commit, 1 file changed)
    • [video] removed old unused library <-> files toggle code (PR:6808, 1 commit, 4 files changed)
    • [Tests] - fix compilation (PR:6814, 1 commit, 1 file changed)
    • [tests] - fix segfaults (PR:6816, 1 commit, 1 file changed)
    • [jenkins] - prevent cleanout of native tools when pathChanged returns 1 ... (PR:6819, 1 commit, 18 files changed)
    • musicdb: remove unused GetVariousArtistsAlbums*() methods without implementation (abc968a4)
  4. dcadec:
    • Shift XLL samples after channel reordering. (fe3348f9)
    • Validate XLL more, add fallback to core decoding. (c1a7d7a7)
    • Fix LFE channel 96 kHz interpolation filter. (715b0ff1)
    • Clear LFE filter history when SYNTH_X96 flag changes. (e03e3822)
  5. pvr.dvblink:
    • fetch tinyxml2 from our mirrors instead of github.com (PR:7, 1 commit, 1 file changed)
  6. pvr.pctv:
    • depends: add jsoncpp (PR:6, 1 commit, 2 files changed)
  7. Additional commits/pull requests/changes not yet merged upstream:



RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Milhouse - 2015-03-26

(2015-03-25, 09:42)slack3r Wrote: Some Omxplayer trouble with build #0323 and #0324 (Rpi1):
player hangs after skipping backward, then I get a black screen trying to stop it.

See the log:
http://pastebin.com/zjzsGqcA

Thanks

P.s.

Build #0321 is fine.

Yes, same on RPi2 with #0325. Last good build for reverse seek is #0321.

With OMXPlayer video stops updating shortly (1-2 seconds) after initiating reverse seek (2x, 4x etc.). The timestamp continues to update but not very frequently. Resuming or stopping playback hangs the GUI.

OMXPlayer 4x reverse debug log

With DVDPlayer there are no obvious log errors, but again playback hangs when reverse seeking, with the GUI timestamp sometimes continuing to update. Resuming or stopping playback hangs the GUI.

DVDPlayer reverse debug log


RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Milhouse - 2015-03-26

For anyone looking to bump their h264 frequency, the settings required depend on the plls and how close you can get with integer divisors (see here for formula).

A few options:

With default core_freq:
Code:
gpu_freq=275
force_turbo=1
should get a h264_freq=275 (along with all other gpu freqs)

When overclocking core_freq (in this example, to 500Mhz):
Code:
core_freq=500
gpu_freq=275
avoid_pwm_pll=1
force_turbo=1
should get a h264_freq=275.

h264 should be fine at 400, the following should work:
Code:
gpu_freq=400
v3d_freq=300
sdram_freq=500
avoid_pwm_pll=1
force_turbo=1

If you don't want force_turbo it's a bit trickier. You have to go higher.
Code:
h264_freq_min=333
over_voltage_min=2

This should also work:
Code:
gpu_freq_min=240
h264_freq_min=300
over_voltage_min=2



RE: OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) - Milhouse - 2015-03-26

@popcornmix:

With build #0325 I'm seeing very stuttery playback with Blade Runner Final Cut mkv (VC1/1080, 5 audio streams one of which - the default - is TrueHD) over NFS (nfs://).

The last good (smooth playback) build is #0324.

debug log (omxplayer)

With dvdplayer, the video playback is again stuttering, but also seems to be playing the video too fast:

debug log (dvdplayer)

In both cases the audio (TrueHD) sounds OK (2.1 HDMI). Setting "Deinterlace video" to Off doesn't make any difference (the normal setting is Auto and MMAL-Advanced (Half)).

(Note: This is without any h264/gpu/pll overclock)

Edit: This 100MB dropbox sample demonstrates the video problem - with #0325 (omxplayer or dvdplayer) the tree is not drawn smoothly, nor does the image and subsequent text fade in/fade out smoothly (compared with #0324, or VLC etc.).