• 1
  • 46
  • 47
  • 48(current)
  • 49
  • 50
  • 89
OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 2
(2015-05-19, 18:43)Milhouse Wrote: There's not really anything relevant in that log, which is to be expected if the OS is freezing. Maybe there'd be something in dmesg, but capturing this information is a problem when the OS has already frozen. Being able to reliably reproduce the freeze is important, and the steps to reproduce might provide some clue as to what is happening. Knowing for sure when the problem started is also useful.

Are you overclocked? If so, test again without any overclocks. If you're using the sdhost driver, switch to the mmc driver and see if the problem goes away. Finally, do you have any rainbow or red coloured squares that appear in the top right corner of your TV display?

I can't seem to reproduce the issue manually, it just seems to happen after watching videos for about 90 minutes.

I have the overclock set to High. I'll disable it.
I have the GPU memory in MB set to 448; I'll reset it to 256.
I have it set to output the maximum 1.2A USB (it's the only way I can use my USB 3.0 HDD).
I don't see the rainbow square.

And I don't know about:
Quote:If you're using the sdhost driver, switch to the mmc driver and see if the problem goes away.
(2015-05-19, 18:51)Mfleigle Wrote: And I don't know about:
Quote:If you're using the sdhost driver, switch to the mmc driver and see if the problem goes away.

If you haven't added dtoverlay=sdhost to config.txt you'll be using the standard mmc driver, which is fine.

One other thing to do would be to run "bcmstat.sh cgxpd10" in an ssh window, this will allow you to monitor various system stats up until the point where the system freezes (make the ssh window wide enough to prevent the lines from wrapping). If ARM or GPU memory is being leaked somewhere, this could explain the freeze.
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.
(2015-05-19, 19:12)Milhouse Wrote:
(2015-05-19, 18:51)Mfleigle Wrote: And I don't know about:
Quote:If you're using the sdhost driver, switch to the mmc driver and see if the problem goes away.

If you haven't added dtoverlay=sdhost to config.txt you'll be using the standard mmc driver, which is fine.

One other thing to do would be to run "bcmstat.sh cgxpd10" in an ssh window, this will allow you to monitor various system stats up until the point where the system freezes (make the ssh window wide enough to prevent the lines from wrapping). If ARM or GPU memory is being leaked somewhere, this could explain the freeze.
I'll try the ssh command.

The only other change I have done since this problem started is I switched from using tx3g/srt subtitles to using Advanced Substation Alpha. I'm not sure if that's relevant but thought I'd add that.
Well, there's a suspected memory leak in libass which is the library used to render both ASS and ASA subtitles - see trac #15820. Currently no solution, and it affects all platforms including x86.

Monitoring with bcmstat.sh will confirm if your ARM memory is disappearing, although exhausting RAM should result in the out of memory (OOM) killer killing kodi.bin which should then restart, rather than the whole OS freezing.
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.
(2015-05-19, 19:26)Milhouse Wrote: Well, there's a suspected memory leak in libass which is the library used to render both ASS and ASA subtitles - see trac #15820. Currently no solution, and it affects all platforms including x86.

Monitoring with bcmstat.sh will confirm if your ARM memory is disappearing, although exhausting RAM should result in the out of memory (OOM) killer killing kodi.bin which should then restart, rather than the whole OS freezing.

OK I forgot, but that's why I hadn't post the problem the day it happened. I thought maybe the ASS subtitles were the culprit, and was waiting to see if a later build fixed it. Yes I know I should have posted instead of waiting for another person to report/fix but usually that happens.

The system I used before I got the RPi2 (and am using when I get tired of the RPi locking up) is currently running OpenELEC-Nvidia_Legacy.x86_64-5.95.1 and I don't have the problem. It has 4GB Ram and 1GB GPU Ram (I think).
(2015-05-19, 19:34)Mfleigle Wrote: The system I used before I got the RPi2 (and am using when I get tired of the RPi locking up) is currently running OpenELEC-Nvidia_Legacy.x86_64-5.95.1 and I don't have the problem. It has 4GB Ram and 1GB GPU Ram (I think).

Your x86 system almost certainly has the same ASS problem - I tested an OpenELEC x86-based system with ASS subtitles and observed the x86 system leaking RAM. It's just that your x86 system has well over 4x the amount of free RAM your RPi2 has, and it will take the x86 system a lot longer to exhaust all of the available RAM and show any problem..

These are very rough figures, but let's assume your 4GB x86 system has 3.5GB of free RAM, at a leak rate of 132KB/second it will take almost 8 hours of continuous playback before exhausting all available RAM. An RPi2 with about 700MB free RAM will take... 90 minutes.
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.
(2015-05-19, 19:44)Milhouse Wrote:
(2015-05-19, 19:34)Mfleigle Wrote: The system I used before I got the RPi2 (and am using when I get tired of the RPi locking up) is currently running OpenELEC-Nvidia_Legacy.x86_64-5.95.1 and I don't have the problem. It has 4GB Ram and 1GB GPU Ram (I think).

Your x86 system almost certainly has the same ASS problem - I tested an OpenELEC x86-based system with ASS subtitles and observed the x86 system leaking RAM. It's just that your x86 system has well over 4x the amount of free RAM your RPi2 has, and it will take the x86 system a lot longer to exhaust all of the available RAM and show any problem..
So I guess I either wait till the ASS bug is patched or switch back to srt. I love the way the ASS subtitles appear (they look real dvd/bluray subs Laugh)

This is slightly off topic, but why does the OpenELEC-Nvidia_Legacy.x86_64 have the correct keyboard layout for my logitech K400 (I can use the home button to go to the home screen)? All RPi builds I've tried do not see the button, and I can't seem to get it to map using the keymap addon.
(2015-05-19, 19:49)Mfleigle Wrote: This is slightly off topic, but why does the OpenELEC-Nvidia_Legacy.x86_64 have the correct keyboard layout for my logitech K400 (I can use the home button to go to the home screen)? All RPi builds I've tried do not see the button, and I can't seem to get it to map using the keymap addon.

Sorry no idea, best to start a new thread or check/ask in the OpenELEC forum. I run a custom Nvidia_Legacy x86 build on my Revo3700 and have no problem with the Home button when using a VRC-1100.
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.
(2015-05-19, 19:56)Milhouse Wrote:
(2015-05-19, 19:49)Mfleigle Wrote: This is slightly off topic, but why does the OpenELEC-Nvidia_Legacy.x86_64 have the correct keyboard layout for my logitech K400 (I can use the home button to go to the home screen)? All RPi builds I've tried do not see the button, and I can't seem to get it to map using the keymap addon.

Sorry no idea, best to start a new thread or check/ask in the OpenELEC forum. I run a custom Nvidia_Legacy x86 build on my Revo3700 and have no problem with the Home button when using a VRC-1100.
I only have the problem on the RPi. The x86 builds work fine
Sorry. I meant to say I have no problem with the Home button on my RPi builds, this also works on my Nvidia_Legacy build (all use the same remote, VRC-1100, albeit Harmony One emulating VRC-1100 in the case of the x86). There are architectural differences between OE RPi and OE x86, eg. lack of x.org in RPi builds, maybe the Logitech K400 driver is doing something stupid that depends on something which is missing from the RPi - you'll need to dig deeper or find someone that can investigate.
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.
(2015-05-19, 20:04)Milhouse Wrote: Sorry. I meant to say I have no problem with the Home button on my RPi builds, this also works on my Nvidia_Legacy build (all use the same remote, VRC-1100, albeit Harmony One emulating VRC-1100 in the case of the x86). There are architectural differences between OE RPi and OE x86, eg. lack of x.org in RPi builds, maybe the Logitech K400 driver is doing something stupid that depends on something which is missing from the RPi - you'll need to dig deeper or find someone that can investigate.

Alright. Thanks for the advice, and for all work you do for the builds.

One last question do you know a subtitle format that is similar to ASS that Kodi agrees with? I like the light shadows I can use with ASS. SRT subs are to thick or nonexistent
@Milhouse

As for my previous problems, I have found some mass packet dropping over wlan.
http://sprunge.us/cDEW

Is there any way I can get a test build which includes RTL8188EU from the head of https://github.com/lwfinger/rtl8188eu ? There are some fixes for n-wireless with newer kernels where there was a struct out of alignment, among other things, and the patches in OE/packages/linux-drivers/RTL8188EU/patches are no longer needed as well.

Although I have had a few build errors over the past few days, I can build it myself, but I would like to keep it as close to your build as possible to rule out any other changes if the updated RTL8188EU driver improves the issue.
New OpenELEC Isengard build #0519: RPi / RPi2
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 4.0.4 #1 Tue May 19 21:02:57 BST 2015 armv6l GNU/Linux

# vcgencmd version
May 18 2015 16:26:35
Copyright (c) 2012 Broadcom
version dda584d6907a6c642dcae5a260aa3396f9146cd2 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20150519210208-#0519-gdd9b49e [Build #0519]

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

# Kernel device tree status: Enabled

Based on tip of OpenELEC master (dd9b49e6, changelog) and tip of XBMC master (da65bf6b, changelog) with the following modifications: Build Highlights:
  1. New kernel 4.0.4
  2. Bump ffmpeg 2.6.3
  3. Fix issue when adding actors to SQLite video db (reported by @querty1000, @robnix)
Build Details:
  1. OpenELEC:
    • dcadec: update to dcadec-37d8e68 (0bcf4370)
    • randrproto: update to randrproto-1.5.0 (04e3b4e0)
    • libXrandr: update to libXrandr-1.5.0 (08f6a971)
    • linux: update to linux-4.0.4 (9eb3b6d0)
    • ffmpeg: update to ffmpeg-2.6.3 (1ceb0889)
  2. XBMC:
    • [osx] - fix timebase of vblankhandler (PR:7143, 11 commits, 8 files changed)
    • [pvr] bump pvr.vbox (PR:7162, 1 commit, 1 file changed)
  3. dcadec:
    • Add XLL+X96 sample to the test suite. (f5ffe27a)
  4. pvr.vbox:
    • added some notes about the new connection settings to README.md (6539b395)
    • bump to version 1.1.1 (83f27246)
  5. kernel 4.0.y:
    • New commits in this build:
      • fbdev: bcm2708_fb: Add ARCH_BCM2835 support (76842aa3)
      • BCM270x: Remove header file mach/dma.h (8e4daae2)
      • BCM270x_DT: Add bcm2708-fb device (61021b58)
      • ARM: bcm2835: Use 0x4 prefix for DMA bus addresses to SDRAM. (48473996)
      • bcm2835: Add bcm2708-fb to Device Tree (16ed47cb)
      • bcm2835: bcm2835_defconfig use FB_BCM2708 (18282745)
      • Merge pull request #970 from notro/fb (9112b62c)
      • BCM2708_DT: Enable mmc and fb in the CM dtsi (1dd8cb48)
      • BCM270x: Add vchiq device to platform file and Device Tree (cce0a62b)
      • bcm2708: vchiq: Add Device Tree support (6ca53d1e)
      • bcm2835: Add bcm2835-vchiq to Device Tree (346c1e2b)
      • Merge pull request #973 from notro/vchiq (e72ad4ba)
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.
(2015-05-20, 03:04)miigotu Wrote: Is there any way I can get a test build which includes RTL8188EU from the head of https://github.com/lwfinger/rtl8188eu ? There are some fixes for n-wireless with newer kernels where there was a struct out of alignment, among other things, and the patches in OE/packages/linux-drivers/RTL8188EU/patches are no longer needed as well.

I'll include the latest commits from the rtl8188eu repo for the next few builds, and I've uploaded a Pi2 test build based on #0519 with the new RTL8188EU commits here. However I don't want to carry these commits long term, so if they're of any benefit you'll need to pester the OpenELEC developers so that master is updated.
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.
(2015-05-20, 04:36)Milhouse Wrote:
(2015-05-20, 03:04)miigotu Wrote: Is there any way I can get a test build which includes RTL8188EU from the head of https://github.com/lwfinger/rtl8188eu ? There are some fixes for n-wireless with newer kernels where there was a struct out of alignment, among other things, and the patches in OE/packages/linux-drivers/RTL8188EU/patches are no longer needed as well.

I'll include the latest commits from the rtl8188eu repo for the next few builds, and I've uploaded a Pi2 test build based on #0519 with the new RTL8188EU commits here. However I don't want to carry these commits long term, so if they're of any benefit you'll need to pester the OpenELEC developers so that master is updated.

Thanks. I'll test it out. About 50 commits over the past 15 months for RTL8188EU lol. Should help.

EDIT: @Milhouse I guess no need to add this to the next few days builds, as I still have packet loss (about half as many packets for the same Tx though), and I still have the random failed video starts. Log is pretty much the same as well: http://sprunge.us/GbKg

Since none of my other devices have an dropped packets, and this Pi is the closest device to my router, I am going to just assume its a hardware/antenna problem.
I have ordered a Panda PAU06 which I think is supported with the mt7601u driver, and has an external antenna.
  • 1
  • 46
  • 47
  • 48(current)
  • 49
  • 50
  • 89

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi (Kodi 15.0) Part 214