[maxodolo]

Because for me the symptoms you describe are happening, when OMX is deactivated and MMAL is activated.

With active OMX: no stalls, no problems.

With active MMAL/deactive OMX: stalls frequently, i could trigger a stall often (video freezes, audio plays, kodi not responsive, ssh working, reboot necessary) especially when acivating the codec overlay and another overlay (pvr channels), and navigating in the channels overlay.

Are you still getting stalls with #0804? There seems to be a report that #0804 doesn't have that issue.

Tried #804 today and had the same problems. Definitely not fixed for me.

Max

[Milhouse]

No crash log have been generated. Kodi just restarts.

Maybe it's an out of memory situation due to all the recursion - after Kodi has restarted, run "journalctl --no-pager | paste" and paste the link.

[Milhouse]

New OpenELEC Jarvis build #0805: RPi / RPi2
(Supercedes previous build)

Code:

# uname -a
Linux rpi512 4.1.4 #1 Wed Aug 5 22:10:43 BST 2015 armv6l GNU/Linux

# vcgencmd version
Aug  3 2015 14:56:05
Copyright (c) 2012 Broadcom
version 4b51d81eb0068a875b336f4cc2c468cbdd06d0c5 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150805220441-#0805-g15ce945 [Build #0805]

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

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (15ce9459, changelog) and tip of XBMC master (9628f606, changelog) with the following modifications:

• Includes newclock4 patches
  
• Excludes the OpenELEC fernetmenta patches due to conflicts with newclock4
  
• Excludes the OpenELEC linux-01-RPi_support patch in favour of sourcing these and possibly more recent patches directly from kernel branch rpi-4.1.y
  
• Default setting for "Show RSS Feed" changed to disabled (new installs only) [patch details]
  
• Disabled "Total Duration" in Confluence (see build #0221 for details)
  
• Includes latest dcadec master (2a9186e3, ahead +34)
  
• Includes latest kodi-platform master (15edaf78, ahead +2)
  
• Includes latest libcec master (e8506b3d, ahead +29)
  
• Includes latest libnfs master (e466dc6b, ahead +28)
  
• Includes latest platform master (081032fd, ahead +3)
  
• Includes latest addons: adsp.basic (da6ee5dd), adsp.biquad.filters (b6a31a90), adsp.freesurround (4dd3202f), asplib (490de460), pvr.argustv (b5fef151, +22), pvr.demo (bb2c46a6, +13), pvr.dvblink (65073157, +15), pvr.dvbviewer (65b86471, +12), pvr.filmon (5d1a5c13, +12), pvr.hts (78a6bd68, +34), pvr.iptvsimple (353cb28d, +12), pvr.mediaportal.tvserver (0de32b2b, +26), pvr.mythtv (75aa8eee, +59), pvr.nextpvr (a731f3c4, +15), pvr.njoy (43b4698f, +12), pvr.pctv (ff5d5360, +12), pvr.stalker (b8a61cb8, +12), pvr.vbox (48ebfdae, +24), pvr.vdr.vnsi (8dedf209, +11), pvr.vuplus (0702fc50, +14), pvr.wmc (e87f1328, +14)
  
• Exclude kodi-100.10-handle-SIGTERM.patch: Use updated Kodi patch from stefansaraev repo
  
• Include b24d9e06: handle SIGTERM
  
• Include patch: Fix PR7102 after PR7666
  
• Include patch: Fix devinput 18b8ba44
  
• Include patch: Add ffmpeg dependency and includes for HEVC optimisations
  
• Include patch: Add experimental splash video
  
• Include patch: Enable pvr addons, disable PVR updates
  
• Include PR:4228: ffmpeg: update to ffmpeg-2.7.1
  
• Include PR:4260: sshd: restart on failure. dont wait for network
  
• Include PR:4262: buildsys improvements
  
• Include PR:7462: added: hide thumbs for unwatched episodes option to show plot is off
  
• Revert 25a51dad: Not yet ready for prime time
  

Build Highlights:

1. New 4.1.4 kernel
   

Build Details:

1. OpenELEC:
   • cmake: set CMAKE_SYSTEM_PROCESSOR in toolchain file (PR:4263, 1 commit, 1 file changed)
     
   • linux: update to linux-4.1.4 (03171670)
     
   • linux: rename upstream patch, must be fixed (ed7bb70b)
     
   • libcec: update to libcec-3.0.1 (067fb846)
     
   • wireless-regdb: update to wireless-regdb-2015.07.20 (7d7cf749)
     
   • Revert "libcec: update to libcec-3.0.1" (15ce9459)
     
2. XBMC:
   • [pydocs] proper types in cast and castandrole (Listitem.setInfo()) (PR:7720, 1 commit, 1 file changed)
     
   • [pvr][fix] limit numeric dialog to fullscreen/visualisation window (fixes #16167) (PR:7699, 1 commit, 1 file changed)
     
   • [epg] adapt the progress texture's height to the actual height of the grid (PR:7370, 1 commit, 1 file changed)
     
   • [PVR] Confirm channel switch when flipping through channel informatio… (PR:7379, 1 commit, 14 files changed)
     
   • [settings] specifies constants for every setting id (PR:7721, 2 commits, 190 files changed)
     
   • fix overlapping subtitles (PR:7719, 2 commits, 3 files changed)
     
   • [pydocs] must use lowercase dictionary keys (19786851)
     
3. kodi-platform:
   • replace "darwin" with "osx" for CORE_SYSTEM_NAME (PR:11, 1 commit, 1 file changed)
     
4. libnfs:
   • socket: handle count == 0 in rpc_read_from_socket (PR:121, 1 commit, 1 file changed)
     
5. platform:
   • replace "darwin" with "osx" for CORE_SYSTEM_NAME (PR:14, 1 commit, 1 file changed)
     
6. newclock4:
   • New commits in this build:
     • [dvdplayeraudio] Avoid busy spinning when queue is empty (c6fd1b35)
       
   • Commits no longer in build:
     • Revert "[mmalrenderer] Wait for vsync before submitting to mmal when display sync is disabled" (98c58a2f)
       
     • Revert "[rbp] Refactor the vsync handle to support multiple callers" (6c088ec3)
       

[J_E_F_F]

with all the cool stuff you guys do to the test builds, why is there no option to change the SSH password yet?

[Milhouse]

with all the cool stuff you guys do to the test builds, why is there no option to change the SSH password yet?

Because you haven't written it yet?

If a pull request existed with that feature I'd include it. Until then, you can disable password access and rely on public/private keys for authentication, this is much more secure than any password you may set.

[MarkT]

When playing a broadcast MPEG2 stream on #0805 I can see in htop that the Kodi main process (w/ threads included) is guzzling up 35-45% of a core. Looking at kodi.bin's threads I can see the main culprit is ActiveAE i.e. the audio engine. Other threads are 1-3%. Now this is an MPEG Layer 2 audio stream at 192 kbps. The RPi2 has a MPEG2 hardware license. Any quick methods to push this CPU guzzler down to say 10%? Or figure out what it is doing?

The vdr.bin process requires about 12-20% of a core, which is consistent with a non-accelerated software CSA decrypter using libdvbcsa. There are patches by glenvt18 for libdvbcsa though that utilize the NEON instructions. The claimed speedup of 2.63x would push this process below 10% and allow even fat satellite HD streams with 25 Mbps data rate be decoded at 1/3 utilization of one core. If that ain't awesome then I don't know what is. ;-)

My own oscam build with a smartcard on USB card reader basically draws no CPU.

Haven't tried an HD stream yet, will need to borrow a smartcard from a friend.

[Patrics83]

No crash log have been generated. Kodi just restarts.

Maybe it's an out of memory situation due to all the recursion - after Kodi has restarted, run "journalctl --no-pager | paste" and paste the link.

I will do that when I get home from the vacation.
Maybe the gpu_mem split is problem?

[ivota]

Problem with reproduce movie .mp4 (log line 954)

http://pastebin.com/fLeX4a5e

[Milhouse]

Maybe the gpu_mem split is problem?

384MB is fine, Kodi really shouldn't be running out of memory on a Pi2 unless something has gone horribly wrong...

[Milhouse]

Problem with reproduce movie .mp4 (log line 954)

http://pastebin.com/fLeX4a5e

Can you upload a debug log (or provide the mediainfo for the file, or better yet a sample?)

[ivota]

http://pastebin.com/0gSAQmJC

[MrNice]

Install the Leopold OE updater addon and find the first build with the problem. You can probably do this in fifteen minutes. With this information you are much more likely to get a fix.

I did some tests, all with the same process, no setup change:
Directory in SD with inside 7 audio files (see post #276)
Install new build with add-on, go to the directory in the SD, move the selection on the file, wait 15 seconds, read value from ssh/top, move to the next file.
Results:
Build | low CPU% (good files) | High CPU% (bad files)
#19852 (date: 22/Dec) | 15 | 66
#19882 (date: 01/Jan) | 15 | 65
#20173 (date: 01/Feb) | 15 | 69
#0301 | 15 | 70
#0401 | 67 | 69
#0501 | 66 | 81
#0601 | 59 | 62
#0701 | 64 | 64
#0401 | 63 | 66 (again to be sure)
#0726 | 09 | 95 (again to be sure)

My conclusion as a user:
2 type of files
Builds #0501 and #0726 have higher values.

I'll try to find the last change between #0701 and #0726

I found the starting build:

Build | low CPU% (good files) | High CPU% (bad files)
#0712 | 64 | 65
#0713 | 72 | 95

Even there is a difference between "bad" and "good" file (I don't know why) there is also a difference between builds.
I'll try to find out why the difference between files.

A bit different with build #0805;
Good files have CPU usage (kodi.bin) around 10%
Bad files have around 60%
I recall that there is no activity, no play. I run a RPi1 512.

I use a RPi1 with a USB Flirc (it simulates a keyboard) and the AVR remote.
Until #0714 I could shutdown RPi by pressing a button simulating Ctrl-End.
From #0715b when I press the button, Rpi freeze but ssh still works, I can reboot from it.
Reboot and shutdown from the menu with mouse or remote works fine.

Could you confirm this bug?

Still the same

Log done from ssh as screen freezes:
http://sprunge.us/VjcO

[Milhouse]

The vdr.bin process requires about 12-20% of a core, which is consistent with a non-accelerated software CSA decrypter using libdvbcsa. There are patches by glenvt18 for libdvbcsa though that utilize the NEON instructions. The claimed speedup of 2.63x would push this process below 10% and allow even fat satellite HD streams with 25 Mbps data rate be decoded at 1/3 utilization of one core. If that ain't awesome then I don't know what is. ;-)

My own oscam build with a smartcard on USB card reader basically draws no CPU.

Haven't tried an HD stream yet, will need to borrow a smartcard from a friend.

Presumably you're referring to these commits. Unfortunately these commits don't apply cleanly on the version of libdvbcsa being used by OpenELEC as it appears glenvt18 has applied additional changes to master, so these also need to be added to OpenELEC.

Without any sign of these commits being pushed upstream (and the NEON performance stuff still in a development branch) it's pretty much a non-starter for upstream OpenELEC.

Just for the hell of it, I've uploaded a vdr-addon that includes the above glenvt18 commits (plus a build patch to enable NEON/SSE2) - give it a try, let us know what difference it makes. If the changes are positive, try to get glenvt18 to push his commits upstream.

[MarkT]

Presumably you're referring to these commits. Unfortunately these commits don't apply cleanly on the version of libdvbcsa being used by OpenELEC as it appears glenvt18 has applied additional changes to master, so these also need to be added to OpenELEC.

Without any sign of these commits being pushed upstream (and the NEON performance stuff still in a development branch) it's pretty much a non-starter for upstream OpenELEC.

Just for the hell of it, I've uploaded a vdr-addon that includes the above glenvt18 commits (plus a build patch to enable NEON/SSE2) - give it a try, let us know what difference it makes. If the changes are positive, try to get glenvt18 to push his commits upstream.

Looks like we did work in parallel while forum was down. I also ported those patches and recompiled vdr. My imho better libdvbcsa package.mk which will also enable MMX/SSE2/SSSE3 on x86 if available in the project:

Code:

PKG_NAME="libdvbcsa"
PKG_VERSION="1.1.0"
PKG_REV="2"
PKG_ARCH="any"
PKG_LICENSE="LGPL"
PKG_SITE="http://www.videolan.org/developers/libdvbcsa.html"
PKG_URL="http://download.videolan.org/pub/videolan/libdvbcsa/${PKG_VERSION}/libdvbcsa-${PKG_VERSION}.tar.gz"
PKG_DEPENDS_TARGET="toolchain"
PKG_PRIORITY="optional"
PKG_SECTION="lib"
PKG_SHORTDESC="libdvbcsa is a free implementation of the DVB Common Scrambling Algorithm - DVB/CSA - with encryption and decryption capabilities"
PKG_LONGDESC="libdvbcsa is a free implementation of the DVB Common Scrambling Algorithm - DVB/CSA - with encryption and decryption capabilities"

PKG_IS_ADDON="no"
PKG_AUTORECONF="yes"

if [ -z "$TARGET_FPU" ]; then
    # If TARGET_FPU is undefined, determine best performing x86 FPU capability from PROJECT_CFLAGS
    LIBDVBCSA_FPU=`echo $PROJECT_CFLAGS | \
        awk '
            /-mssse3( |$)/ { printf "--enable-ssse3" ; exit; }
            /-msse2( |$)/  { printf "--enable-sse2"  ; exit; }
            /-mmmx( |$)/   { printf "--enable-mmx"   ; exit; }
        '`
else
    # TARGET_FPU defined, enable best optimization as supported
    case "$TARGET_FPU" in
        neon*)        LIBDVBCSA_FPU="--enable-neon" ;;
        *)            LIBDVBCSA_FPU="" ;;
    esac
fi

# This library's configure will set aggressive optimisation flags by itself
CFLAGS=`echo $CFLAGS | sed -e "s|-Os||g"`

PKG_CONFIGURE_OPTS_TARGET="--disable-shared --enable-static --with-sysroot=$SYSROOT_PREFIX $LIBDVBCSA_FPU"

The patch itself libdvbcsa-1.1.0-rff.patch is too big (1.4 MB text) so can't be included here. Page me if interested. ZIP 300 KB.

Of course I did benchmark cpu time as shown by htop with 120 seconds of ~2 Mbps video each.
Focus was on the "device 1 receiv" receiver thread of vdr.bin, which handles decryption.

Code:

libdvbcsa 1.1.0:
FTA               1.08s
Encrypted        26.64s

libdvbcsa 1.1.0 w/NEON:
FTA               1.36s
Encrypted        13.67s

TLDR; CSA decryption speed using NEON instructions has doubled. Do legst di nieda is a saying where I live for such cases.

[Mfleigle]

Is there anyway to remove the pvr manager? I have all the pvr addons disabled, and still see "PVR Manager Is Starting Up" on boot.