• 1
  • 258
  • 259
  • 260(current)
  • 261
  • 262
  • 277
OpenELEC Testbuilds for RaspberryPi Part 2
(2014-04-01, 23:44)MilhouseVH Wrote: That /is/ a build from master, but it doesn't include the libass commit. Match the sha in the filename (4244f63) against the commits on the OpenELEC master branch to determine what the last commit is, in this case it's "nasm: update to nasm-2.11.02" which is the commit just before libass...

Ah, now it all makes sense Smile

(2014-04-01, 23:44)MilhouseVH Wrote:
(2014-04-01, 23:40)bagofcrap24 Wrote: it did not fix the problem. but thank you for trying anyway

Oh well, then I guess the options are to hope for an upstream fix, or revert back to 0.10.2 assuming this is possible/desirable (there may have been a specific reason for updating to 0.11.1).

just tried the build you recommended and the issue comes back so its pretty safe to say its the update lib

to be fair its not really a massive problem even if they don't fix it. as it only happens half a dozen times during a 20minute episode and even then. its pretty easy to figure out what that missing word is
(2014-04-01, 23:56)bagofcrap24 Wrote: just tried the build you recommended and the issue comes back so its pretty safe to say its the update lib

@sraue (OE developer) has asked me to create a build with the libass change reverted, so can you try this build - it's the #0401 build but with the original libass 0.10.2. Please post the results here and on your OE issue. Thanks.
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.
(2014-04-01, 07:53)M3Rocket Wrote:
(2014-04-01, 00:52)sraue Wrote: Hi all,

before we release our beta 4 soon, we need help to test the just updated kernel (3.14) which are included in this builds:
http://snapshots.openelec.tv/OpenELEC-RP...b1b.img.gz (Diskimage)
http://snapshots.openelec.tv/OpenELEC-RP...9f1b1b.tar (tarball)

please report back any issue kernel (driver) related (best compare with this builds (kernel 3.13):
http://snapshots.openelec.tv/OpenELEC-RP...47f.img.gz (Diskimage)
http://snapshots.openelec.tv/OpenELEC-RP...f4d47f.tar (tarball)

(there should not be any changes except the kernel update between the both)

Note: this builds contains not the newest patches from popcornmix, instead a almost vanilla XBMC Gotham Beta 3/4 is used with only a few backports.

Thanks much

With 3.95.1, 3.95.2 & 3.95.3, and all Millhouse builds (since 3/15, didn't try earlier), my Wi-Fi would mysteriously go up and down. As long as the slideshow screensaver wasn't running, I could "restart" the network about 50% of the time and get to it via SSH or Samba. I was running into "FIQ NYET" messages depending on FIQ configuration. Other times, I can see the WiFi reconnect multiple times via "dmesg" when I could get SSH to work. Sometimes, dmesg would be littered with "TX status timeouts." All during those times, video seemed to play OK. But once the slideshow screensaver started, it would cause the Samba and SSH connections to disconnect and not be found.

After many hours this past weekend, I settled on going to the OE Config Manager and looking at the connections refresh. What would happen is that during the refresh, the config would sometimes lose ALL the other 2.4GHz network listings except for the 5GHz connection. Whenever I could coax all the networks to appear on that screen, SSH and Samba would start working again.

Kernel 3.14 solved almost all my rPi intermitent network issues--at least that I can see in the last few hours. SSH and Samba connections are stable once again (staying connected) like it was with 3.2.4 and rBej builds. Curiously, I got only about two dozen TX status timeouts over the couple of hours. Normally, there would literally be hundreds and hundreds. Here's what the messages look like:

Code:
[ 5258.001742] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
[ 5258.002981] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
[ 5258.004252] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
[ 5258.005515] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2
[ 5258.006760] ieee80211 phy0: rt2800usb_entry_txstatus_timeout: Warning - TX status timeout for entry 7 in queue 2


I'm now going to test kernel 3.13 for comparison...

I abandoned kernel 3.13 after a few hours. While I wasn't getting the txstatus timeouts, everything was a little slow. It's like after a short period past bootup, SSH and Samba would either be slow to connect and eventually, it will disconnect. And if the Slideshow screensaver was running, even simple SSH is delayed.

I went back to kernel 3.14, and everything feels like 3.2.4. My SSH and Samba sessions are fast and persistent regardless of activity on the rPi. I do believe that there might still be some niggling problems with the FIQ driver since I'm getting the TX status timeouts, but there are much fewer than when it wasn't working. I even left it running the slideshow all day while I was at work and came home to instant SSH and Samba connections.

Gonna try Millhouse with 3.14 next...
(2014-03-31, 21:56)pplucky Wrote:
(2014-03-31, 21:54)popcornmix Wrote:
(2014-03-31, 21:49)pplucky Wrote: @popcornmix: Did you miss my previous post or you didn't have the time to check it?

Thanks in advance for any reply.

I believe it's the same bug as the post I linked to. I'm waiting for a fix from the author.
You could try OpenElec Gotham beta 3 which shouldn't have that bug in.

OK, thanks for the update and for following it up. I will anyway try OE beta3 and report back.

Exact same issue happens with a clean OE beta3 install with restored storage partition as from Milhouse build. Any other thoughts?
@millhouse, Popcornmix
Can RaspyFi features get included in one test build?

RaspyFi features:
-Supports almost all DACs
-Bit perfect playback (up to 32bit 192 khrtz)
@popcornmix

I tried to play another m2ts file this morning. Kinda same symptoms as before. Log is here : http://sprunge.us/XhaH

In the logs it looks like it fails immediately. but in fact the pi is unresponsive (but still replies to pings) for the duration of the movie that I tried to play. Once the movie time has elpased, it becomes responsive again. So far have tried this over nfs and samba. I guess the next test is local.

If this is a file error then no need to worry.

Thanks

PS. This is using build 330
(2014-04-02, 09:27)Stilt Wrote: @millhouse, Popcornmix
Can RaspyFi features get included in one test build?

RaspyFi features:
-Supports almost all DACs
-Bit perfect playback (up to 32bit 192 khrtz)

Ask the OpenELEC developers if they will support that functionality, though I suspect the answer is likely to be "no" unless it just means adding more sound drivers and is relatively straightforward.

The purpose of my builds is not to introduce functionality that is not and never will be supported by upstream OpenELEC, so if you want new functionality added to a test build then get the backing/support of OpenELEC first.
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.
(2014-04-01, 22:26)mildenhall Wrote:
(2014-04-01, 22:15)MilhouseVH Wrote: Try "dwc_otg.fiq_fsm_enable=0" in place of "dwc_otg.fiq_enable=0"

Basically the same thing! Confused

Code:
dwc_otg.fiq_enable=1 dwc_otg.fiq_fsm_enable=1 dwc_otg.fiq_fsm_mask=0x3 root=/dev/ram0 rdinit=/init BOOT_IMAGE=/kernel.img dma.dmachans=0x7f35 bcm2708_fb.fbwidth=1920 bcm2708_fb.fbheight=984 bcm2708.boardrev=0xf bcm2708.serial=0x9fb56012 smsc95xx.macaddr=B8:27:EB:B5:60:12 sdhci-bcm2708.emmc_clock_freq=250000000 vc_mem.mem_base=0x1ec00000 vc_mem.mem_size=0x20000000  boot=/dev/mmcblk0p1 disk=/dev/mmcblk0p2 dwc_otg.fiq_fsm_enable=0 quiet textmode

OK, I've tried (1) a new install, (2) a new SD card, and (3) a new PI. 1 and 2 still had the same problem. 3 didn't so I've ordered a new Pi. My two Pis were in the 2nd batch to ever be made and one of the Pis has always been slightly slower than the other Pi to download things.
(2014-04-02, 02:02)MilhouseVH Wrote:
(2014-04-01, 23:56)bagofcrap24 Wrote: just tried the build you recommended and the issue comes back so its pretty safe to say its the update lib

@sraue (OE developer) has asked me to create a build with the libass change reverted, so can you try this build - it's the #0401 build but with the original libass 0.10.2. Please post the results here and on your OE issue. Thanks.

sorry for the lateness. Just tried your 401 with original libass 0.10.2 and works perfectly fine so 100% is the culprit now

Image
@bagofcrap24: many thanks.
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.
Please check this sample. Only me dont have audio after seeking movie to beginning??.

http://speedy.sh/Ef6J9/sample.avi



New OpenELEC Gotham build: #0402
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 3.14.0 #1 PREEMPT Wed Apr 2 12:00:49 BST 2014 armv6l GNU/Linux

# vcgencmd version
Mar 30 2014 15:59:18
Copyright (c) 2012 Broadcom
version 8f13fa508997a043a3d78822e3f67ec044b4e7bf (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20140402115943-r18083-g960b3b5

Based on tip of XBMC master (1790b03, changelog) and tip of OpenELEC master (960b3b5, changelog) with the following modifications:
  • Includes newclock3 commits (except for 51c4acc, a patch to avoid hammering the GUI, which has been replaced with a static spinner)
  • Excludes the OpenELEC fernetmenta patches (due to conflict with newclock3)
  • Includes Python regex package for evaluation purposes. Initial benchmarking indicates generally positive (and in some cases, significant) performance gains. See this post for a description of how to test effectiveness of this package with addons
  • Default setting for "Show RSS Feed" changed to disabled
  • Disabled "Total Duration" in Confluence (see build #0221 for details)
  • ALSA is enabled and any suitable hardware should be available in XBMC Audio Settings
  • Includes newclock3: "More efficient infobool expression evaluator" (reverted in stock OpenELEC)
  • Includes newclock3: "Allow small audio packets to be concatenated to make better use of audio fifo" (reverted in stock OpenELEC)
Build Highlights:
  1. OpenELEC:
    • Revert "libass: update to libass-0.11.1"
    • freetype: update to freetype-2.5.3
    • rpcbind: update to rpcbind-0.2.1
    • pptp: update to pptp-1.8.0
    • wpa_supplicant: update to wpa_supplicant-2.1
    • ppp: update to ppp-2.4.6
    • libnl: update to libnl-3.2.24

Additional Testing Notes:
  1. Testers should try adding the following entry to their advancedsettings.xml:
    Code:
    <advancedsettings>
      <video>
        <defaultplayer>dvdplayer</defaultplayer>
        <defaultdvdplayer>dvdplayer</defaultdvdplayer>
      </video>
    </advancedsettings>
    and report if it is better/worse than omxplayer. You can still play files with omxplayer using the context-menu "Play using... OMXPlayer".

  2. The following settings are no longer required in config.txt and should be removed:
    Code:
    no_hdmi_resample=1
    hdmi_stream_channels=1
    no_resample_audio is now a default, and hdmi_stream_channels is switched based on audio content. For the time being when using passthrough, 2.0 speaker layout should continue to be used (you will still get 5.1 with AC3/DTS).

  3. The FIQ_FSM patch is now enabled by default in OpenELEC master. See the FIQ_FSM announce thread for details.

    One new feature, currently disabled by default, is accelerated support of high-speed isochronous transactions (webcams, real time devices, etc.). There's a possibility this could be used by ALSA or DVB modules (although not always) which may affect some users (hopefully for the better). If you might benefit from this, enable by adding the following option to the end of the line in your /flash/cmdline.txt file:
    Code:
    dwc_otg.fiq_fsm_mask=0x7
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
ran the music import again. Yesterday with MilhouseVH build #330 the issue was still there and it stalled at some point (using Confluence). SSH also broke at some point. Tried to reproduce today again but updated to #401. Using #401 the issue seems to be gone so far (still importing, but it's taking a while to complete - freezes used to occur after ~30-60 min). Having the bcmstat script running I noticed some oddities though. At some points the PI seems to be maxed out and the script is only executed every 10 mins. The PI recovered from this state though. I made a screenshot

edit: hang on, it froze this second. Doing tests you asked for now

edit2: here we go:
- screen is black and bmcstat script was stalled and only executed every ~10 mins (putty screenshot)
- I was not able to get any GUI output visible again using random remote buttons (like directly jumping to home or video library)
- after I had pressed some keys, it seems bmcstat recovered (putty screenshot)
- SSH is still active
- killing XBMC via "killall xbmc.bin" didn't reboot XBMC - screen stayed black
- top looks like this

PI is still running, so I can do further debugging. XBMC is already killed though.
@da-anda: Just a couple of observations regarding bcmstat.sh usage:
1) Are you on WiFi? By default it will monitor traffic over the eth0 interface, however if you add the parameter "-iwlan0" it should monitor the wlan0 i/f.
2) By default it runs at the lowest possible priority (nice +20). Specify "-N" (normal priority) or "-M" for maximum priority, the increased priority should ensure the script runs more often when the system is under heavy load. Obviously running the script frequently (default is every 2 seconds) and/or at higher priority has consequences as it can influence more significantly the load on the system.


Edit: The extremely high iowait in your screenshots would suggest the Pi is busy waiting on storage (writes?), if my understanding of iowait is correct. What is your storage (SD? USB?) and what filesystem (ext2, ext4, f2fs?)
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.
Yes, I'm on WiFi. Will use the wlan param for next debugging round Smile

edit: that's btw the startup info from the bcmstat script
Code:
Governor: ondemand
  Memory: 512MB (split 384MB ARM, 128MB GPU)
HW Block: |   ARM   |  Core  |  H264  |   SDRAM   |
Min Freq: |  700Mhz | 250Mhz |   0Mhz |   450Mhz  |
Max Freq: |  900Mhz | 333Mhz | 250Mhz |   450Mhz  |
Voltages: |         +2, 1.20V         |  0, 1.20V |
   Other: temp_limit=85
Firmware: Mar 30 2014 15:59:18, version 8f13fa508997a043a3d78822e3f67ec044b4e7bf (clean) (release)
  Codecs: H264 WVC1 MPG2 VP8 VORBIS MJPG
  Booted: Wed Apr  2 13:07:53 2014
  • 1
  • 258
  • 259
  • 260(current)
  • 261
  • 262
  • 277

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