• 1
  • 238
  • 239
  • 240(current)
  • 241
  • 242
  • 277
OpenELEC Testbuilds for RaspberryPi Part 2
Are the changes to bcm2835-bootloader only for 'new' SD cards, or are those also applied to the current working setups?
Occording to the filename, it's only about new ones. Is this correct?
https://github.com/OpenELEC/OpenELEC.tv/...19f313e0da
Not sure if you are guys are actively monitoring the FIQ_FSM USB driver rewrite thread but today there was an update which might fix the network devices suddenly stop responding issue. I'm having that issue as well and it would be interesting to see if we can get rid of the "dwc_otg.fiq_fsm_enable=0" work-around now.
(2014-03-19, 16:55)popcornmix Wrote:
(2014-03-19, 03:28)MilhouseVH Wrote: New OpenELEC Gotham build: #0319

How is multichannel audio using Pi Sink (i.e. paplayer and dvdplayer) with this build?
The channels should be mapped correctly now.
Problems from this older post still stands with both -- PAPlayer and DVDPlayer. I've recorded a short clip to demonstrate the issue (the volume level is a bit low, tho): 24-bit, 44 kHz 5.1 sounds pretty bad: music is heard from front left channel all the time, center channel occasionally, the rest are mostly mute. Audio breaks every now and then, when garbled audio starts, moving cursor (in songs list) up and down fixes it for a short time (while cursor is sliding up or down), then it breaks again.

With OXMPlayer 24-44 works fine, except, I believe, that center and front right are swapped, and rear left sounds like LFE. Higher frequencies interrupts with songs list visible, works fine on full screen, but should be noted, that audio is down-sampled to 48 kHz.

I personally am quite happy with the progress made so far and the lack of multichannel audio is okay with me. It is exotic and unpopular enough and non-overclocked Pi is on the edge to keep up with decompression. I think it is a more realistic goal for a dedicated, GUI-less music player.

Update: Setup: Pi -> HDMI to the Receiver -> HDMI to the display.
I want to report somewhat unusually high utilization when Official XBMC Remote for iOS is connected and on Now Playing screen -- 15 to 20% CPU utilization on the Pi just because of that. I suppose it is unnoticeable on a higher-performace hardware, such as a commodity PC, but it's quite noticeable on Pi.
Image
(2014-03-19, 22:22)606u Wrote: I want to report somewhat unusually high utilization when Official XBMC Remote for iOS is connected and on Now Playing screen -- 15 to 20% CPU utilization on the Pi just because of that. I suppose it is unnoticeable on a higher-performace hardware, such as a commodity PC, but it's quite noticeable on Pi.

Do you get the same effect with a different xbmc remote (e.g. xbmc commander?)
Not sure there's much we can do if the remote is just sending messages continuously, but it might be worth mentioning on the XBMC remote forum.
@606u: turn on debug log (wiki), specifically JSON logging, and I'm pretty sure the reason for increased load will become clear. Unfortunately some smartphone remotes are just not that smart...
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-03-19, 22:42)MilhouseVH Wrote: @606u: turn on debug log (wiki), specifically JSON logging, and I'm pretty sure the reason for increased load will become clear. Unfortunately some smartphone remotes are just not that smart...
Here it is.
(2014-03-19, 23:15)606u Wrote:
(2014-03-19, 22:42)MilhouseVH Wrote: @606u: turn on debug log (wiki), specifically JSON logging, and I'm pretty sure the reason for increased load will become clear. Unfortunately some smartphone remotes are just not that smart...
Here it is.

Pretty much as suspected, the remote control app is spamming the client with JSON requests several times a second, most likely to maintain it's own state (what's playing, seek positiion etc.). Most (if not all of these) JSON requests are completely unnecessary, as the app could get the same information via JSON notifications without spamming the client.

Code:
23:06:29  62.758083 T:2667574352   DEBUG: JSONRPC: Incoming request: {"method":"Player.GetProperties","id":-472574362,"jsonrpc":"2.0","params":{"playerid":1,"properties":["percentage","time","totaltime","partymode","position","canrepeat","canshuffle","repeat","shuffled","canseek"]}}
23:06:29  62.760704 T:2794067024   DEBUG: JSONRPC: Incoming request: {"method":"Player.GetItem","id":-613133993,"jsonrpc":"2.0","params":{"playerid":1,"properties":["album","artist","title","thumbnail","track","studio","showtitle","episode","season"]}}
23:06:29  62.881805 T:2794067024   DEBUG: GetMovieId (nfs://192.168.0.2/c/media/Series/Lilo & Stitch. The Series/s01e01 Richter (513).m4v), query = select idMovie from movie where idFile=467
23:06:29  62.891171 T:2794067024   DEBUG: GetEpisodeId (nfs://192.168.0.2/c/media/Series/Lilo & Stitch. The Series/s01e01 Richter (513).m4v), query = select idEpisode from episode where idFile=467
23:06:29  63.084656 T:2667574352   DEBUG: webserver: request received for /jsonrpc
23:06:29  63.085541 T:2667574352   DEBUG: JSONRPC: Incoming request: {"method":"XBMC.GetInfoLabels","id":456093242,"jsonrpc":"2.0","params":{"labels":["MusicPlayer.Codec","MusicPlayer.SampleRate","MusicPlayer.BitRate","VideoPlayer.VideoResolution","VideoPlayer.VideoAspect"]}}
23:06:30  63.725456 T:2794067024   DEBUG: webserver: request received for /jsonrpc
23:06:30  63.726749 T:2794067024   DEBUG: JSONRPC: Incoming request: {"method":"Player.GetActivePlayers","id":1121127974,"jsonrpc":"2.0","params":{}}

Note how there are two separate threads (T:2667574352 and T:2794067024) on the Pi both responding to JSON requests, suggesting that you have the same app running on two iOS devices and that when you start playing a movie on the XBMC client the app on each device goes into overdrive spamming the XBMC client with JSON requrests just to maintain it's own internal state. If you add this app to a third iOS device... well, you can see the problem, eventually you won't be able to play movies! There's an Android app (Yatse) that does the same, it's ridiculous.

My advice would be to uninstall this garbage and find a smarter app...

(2014-03-19, 21:45)ijsbeer79 Wrote: Are the changes to bcm2835-bootloader only for 'new' SD cards, or are those also applied to the current working setups?
Occording to the filename, it's only about new ones. Is this correct?
https://github.com/OpenELEC/OpenELEC.tv/...19f313e0da

Yes, it would be for when creating a new installation from scratch, it will have no effect when updating an existing installation.
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.
New OpenELEC Gotham build: #0320b
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 3.13.6 #1 PREEMPT Wed Mar 19 22:38:17 GMT 2014 armv6l GNU/Linux

# vcgencmd version
Mar 19 2014 23:26:47
Copyright (c) 2012 Broadcom
version 98eb97cd0061f2fcff808fe5f32f851d5eada1ee (tainted) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20140320001024-r17977-ge57e1bc

Based on tip of XBMC master (33133a5, changelog) and tip of OpenELEC master (e57e1bc, changelog) with the following modifications:
  • Includes newclock3 commits (except for d8a2d2d which I've replaced with a static spinner to avoid hammering the GUI)
  • Includes kernel 3.13.y-next commits (see below for details on enabling FIQ_FSM patch)
  • 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. Replace "import re" with "import regex as re" in addons to test effectiveness.
  • 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:
FIQ FSM has been updated, please re-enable and re-test if you were experiencing problems. Removing any dwc_otg.* options from cmdline.txt should be sufficient to re-enable FIQ FSM. This may resolve issues for those that were losing their network connection.
  1. New Firmware Mar 19:
    • firmware: audio_render: Fix for repeating noise when paused playing multichannel audio
  2. OpenELEC:
    • Fixed lcdd dependencies
    • curl: re-enable rtsp
  3. newclock3:
    • TrueHD optimisations by Ben Avison - from popcornmix:
      Quote:Ben's just finishing the TrueHD optimisations. Looks like it's up to 40% faster (for 8 channel), and even faster if the downmix hack is used (I need to check more carefully if the downmix hack is working as you didn't see the same benefit as I did). Hopefully it's enough to make most TrueHD stream usable with overclock.
  4. kernel:
    • FIQ FSM has been updated to resolve some issues, please re-enable and re-test. From popcornmix:
      Quote:There is an update to fiq_fsm (and rpi-3.13.y-next tree) which should fix the "FIQ reported NYET. Data may have been lost." issue.
      (Basicaly the fiq was getting disabled, and causing lost usb messages).

      This could help a range of problems with USB and fiq_fsm.
  5. Custom:
    • #0320b: Adds Python regex package for evaluation purposes, which can be used as a direct replacement for the existing re package. Initial benchmarking indicates generally positive (and in some cases, significant) performance gains. If you wish to help test the effectiveness of this new package, replace "import re" with "import regex as re" in addons source code - timed before/after results would be most appreciated.

    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.
Updated last build with addition of Python package regex.
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.
For some of the channels the top few row of pixels are not being displayed properly. I went to video calibration and adjusted the screen and now the offending row of pixels are not shown however the issue is that by doing this I have pushed the skin's clock too far and I only see 3 quarters of it and it looks horrible now.

Is it possible to adjust overscan for live tv for those few channels without adjusting the skin which shows properly without the video calibration adjustment. I am using default omxplayer I have tried dvdplayer but it manages to crash XBMC on certain channel change.
(2014-02-10, 21:15)michbeck100 Wrote:
(2014-02-09, 01:42)michbeck100 Wrote: I'm using Hyperion successfully since a few weeks, now. It's great, taking about 4-5% CPU. I packed the whole thing into an Openelec addon and I'm planning to make it available soon. Just have a look at the Hyperion thread (http://forum.stmlabs.com/showthread.php?tid=11053).

I finally finished my XBMC add-on to install hyperion to Openelec systems. It's available at Github. Download the add-on as ZIP file from here . If there are any issues please pm me. I'll try to fix any issues ASAP and update the add-on if any hyperion updates are available or changes to the test builds break the installation.

Did anyone test this?
Image
(2014-03-19, 22:11)606u Wrote: Problems from this older post still stands with both -- PAPlayer and DVDPlayer. I've recorded a short clip to demonstrate the issue (the volume level is a bit low, tho): 24-bit, 44 kHz 5.1 sounds pretty bad: music is heard from front left channel all the time, center channel occasionally, the rest are mostly mute. Audio breaks every now and then, when garbled audio starts, moving cursor (in songs list) up and down fixes it for a short time (while cursor is sliding up or down), then it breaks again.

The audio break up (a repeated rumbling noise) should be fixed in latest Milhouse build.
If you still believe channels are mapped wrongly, then can you upload a sample file and describe your audio settings.
(2014-03-20, 15:10)Eoghlear Wrote:
(2014-02-10, 21:15)michbeck100 Wrote:
(2014-02-09, 01:42)michbeck100 Wrote: I'm using Hyperion successfully since a few weeks, now. It's great, taking about 4-5% CPU. I packed the whole thing into an Openelec addon and I'm planning to make it available soon. Just have a look at the Hyperion thread (http://forum.stmlabs.com/showthread.php?tid=11053).

I finally finished my XBMC add-on to install hyperion to Openelec systems. It's available at Github. Download the add-on as ZIP file from here . If there are any issues please pm me. I'll try to fix any issues ASAP and update the add-on if any hyperion updates are available or changes to the test builds break the installation.

Did anyone test this?

Why would you? Hyperion could be installled to OE already. See theire wiki: https://github.com/tvdzwan/hyperion/wiki...h-OpenELEC
Is there or will there be a solution to just stop playback and go back to the Home screen of xbmc when the TV shuts off? (cec-commands?) Or can this be achieved somehow? I'd really love a solution like this since I'm using my TV's sleep timer a lot...
  • 1
  • 238
  • 239
  • 240(current)
  • 241
  • 242
  • 277

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