• 1
  • 87
  • 88
  • 89(current)
  • 90
  • 91
  • 156
OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0)
@Milhouse

we just had discussion here internally past hour about that and I was checking history of that file to help myself remember what that particular problem was. But based on missing comment from my side (in the reported issues regarding fps issue) it was something like stupid me .... or typo (while responding to OnScreenSaverDeactivated).

I'm pretty sure that bug was there at the time I shared with popcornmix - so if that fresh patch should help pretty much depends on how (and what) you was applying. If that past version, then yes, it should help.
But colleague @Anaconda is telling me that your build system if fetching all the patches each run. Then the answer would be no as there is ~1 change relevant to process of waking up (stopping the limiter) - or I got stupid in-between and am missing again (on first look unrelated) dependency of code which I missed also with ver 1 of that patch.

If possible without much hassle re-apply again and turn off TV. Check in logs for "CecStandby 1", turn TV back on. You will see in logs record about TV being "ON" again - problem is that this message comes from libCEC and comes not back to XBMC (as it is no message on CEC bus, but internal state change of libCEC for device 0(TV)). there is no OPCODE defined for device becoming ON (in contrast to dev going standby is required to be sent by the specific device).
I have the feeling that the first attempt - while trying to change as little of code as possible - was too optimistically depending on CEC messages and activity only (TV going OFF, TV changing source (so XBMC loosing ActiveSource attribute) and then back again with TV switching back to XBMC source (becoming ActiveSource again) or TV going OFF->ON - where (beside ugly LG) we don't get TVisON but TV should ask/reactivate last ActiveSource device so actually delivering the needed message to XBMC again (becoming AS)).
In reality that was far from paper specs... (not only for LG. there is also libCEC part like libCEC not reporting being AS if that info was already sent before - but not considering TV off-on cycle flushing all internal info about actual libCEC devices - so leaving TVs request to get info who is AS unanswered - limiting itself to DEBUG comment "not sending AS as libCEC is AS already and AS sent before")

to make this short - due to this (and also considering VNC usage where libCEC status is not touched in any way) I added calls to CecStandby triggered from Screensaver changing status too. I can't think currently of anything else.
As we speak in the process - realised otherwise clear consequence of that - if screensaver functionality is turned OFF but CEC as ON(xbmc's default) and otherwise CEC config in XBMC left to defaults also - XBMC will definitely sooner or later end up at 2fps limit. if not while changing sources then later after TV going through cycle OFF - > ON (as ON not being communicated -> with just one source (RPI), libCEC won't resend ActSource message, that won't wake up XBMC - and screensaver off event as helper is not existing).

If it is that case, we can re-add OPCODE handler for message type that is being send by TV during it's CEC init. CEC defines this as SET LANG to 0xf followed by GET VENDOR ID to 0xf (so we will create analogue to "TV is ON"). With LG it will be probably VENDOR ID followed by OPABORT (to reset/cleanup) existing bonds (undocumented LG only extensions).

To be even much shorter - LOG will get definitely handy - to cover the right OPCODE while not taking such which is being repeated constantly (again LG) - this would be turning the limiter off for no reason).
(and to provide user's choice/control to disable this feature completely - we can confront XBMC's CEC setting on each CecStandby() call (for instance again the "standby with screensaver")) - currently is checked only when handling the screensaver events.

I hope I didn't make the topic to sound/feel more complicated as it really is ...

btw: original idea was to turn off rendering completely. That is even more polite to XBMC code as Renderer() function is not messed at all and public function SetRenderGUI(or SetGUIRender) is called with true/false. It was/is working as expected on RPI but on IMX6 it was throwing VSync() apart - not working anymore upon reactivating GUIRenderer (probably by a leak in IMX6 implementation FBs MULTI_BUFFER gets destroyed). with new kernels this looks ok so once everybody is confident with the problem you have been experiencing I would propose switching from limiter to stop renderer - what can theoretically lead to later context offloads (releasing mem). RPI would profit from each 10M we can save.
btw2: rendereroff is causing xbmc going under 2%. that marginal load is caused by peripheral busses being polled and rescanned. I have seen you adapt that for CECbus already. But whole "input" subsystem is looping literally with no gaps (but most likely <2% is not worth anymore troubles).

mk
(2014-09-12, 06:41)mk01 Wrote: I'm pretty sure that bug was there at the time I shared with popcornmix - so if that fresh patch should help pretty much depends on how (and what) you was applying. If that past version, then yes, it should help.
But colleague @Anaconda is telling me that your build system if fetching all the patches each run. Then the answer would be no as there is ~1 change relevant to process of waking up (stopping the limiter) - or I got stupid in-between and am missing again (on first look unrelated) dependency of code which I missed also with ver 1 of that patch.

Yes, my build system is pulling the patch directly from the xbian github every time, and had been building with the version prior to this latest Sep 12 update.

I've uploaded a new build, #0911b, which is the same as #0911 but now with the re-inclusion of the CecStandbyRender patch.

Even if this latest build doesn't fix the problem it should ensure you have a known version of the code when trying to interpret any debug results (all the patches used by the build are included in the OpenELEC tar, in the archive milhouse.build.tar.gz).

I'll include this patch again in future builds in the hope we can get you the debug information when you need it.

(2014-09-12, 06:41)mk01 Wrote: If possible without much hassle re-apply again and turn off TV. Check in logs for "CecStandby 1", turn TV back on. You will see in logs record about TV being "ON" again - problem is that this message comes from libCEC and comes not back to XBMC (as it is no message on CEC bus, but internal state change of libCEC for device 0(TV)). there is no OPCODE defined for device becoming ON (in contrast to dev going standby is required to be sent by the specific device).
I have the feeling that the first attempt - while trying to change as little of code as possible - was too optimistically depending on CEC messages and activity only (TV going OFF, TV changing source (so XBMC loosing ActiveSource attribute) and then back again with TV switching back to XBMC source (becoming ActiveSource again) or TV going OFF->ON - where (beside ugly LG) we don't get TVisON but TV should ask/reactivate last ActiveSource device so actually delivering the needed message to XBMC again (becoming AS)).
In reality that was far from paper specs... (not only for LG. there is also libCEC part like libCEC not reporting being AS if that info was already sent before - but not considering TV off-on cycle flushing all internal info about actual libCEC devices - so leaving TVs request to get info who is AS unanswered - limiting itself to DEBUG comment "not sending AS as libCEC is AS already and AS sent before")

Unfortunately I don't have CEC screens here so can't help with the debugging, but hopefully other testers will be able to provide you with the details you require. I'm happy to include additional logging in future builds (experimental or otherwise) if you think that might help expedite a solution.
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-09-12, 01:50)mk01 Wrote:
(2014-09-08, 00:23)Milhouse Wrote: [*]New 3.16.2 kernel
[*]Temporarily dropped CEC Standby Fix[/url] to see if that helps prevent GUI framerate problems

Millhouse, colleagues,

does anyone have --debug log from that case of staying at 2fps? (grep 'CecLog\|CecStandby' will deliver enough info)

we had exactly that problem reported from users as well but it was back in June (https://github.com/xbianonpi/xbian/issue...closed+fps). If I remember correctly it was caused by strict expectation of becoming active source on cec bus and going off "standby" mode via "onscreensaverdeactivated" event was put badly into the IF.

second problem was with TVs without CEC - that can be solved by setting "cec enabled" to off or just "standby devices on screensaver" to off in XBMC's input device / cec setting.

in regards to LG's, yes, unfortunately LG on top of not very good implementation added own extensions to CEC with ignoring some events at the same time. but that can be fixed by integrating proper (LG) opcode into XBMC's process message handler (to trigger standby off) - like for instance "set language", or "report vendorid" or others.

@mk01, a debug log showing what you want is here.

Debug log procedure: I enabled debug, rebooted the Pi and did absolutely nothing with it. Just left it running over night (my Pis are always on) and the result is the same: a very laggy GUI running at precisely 2fps.

I'll test build #0911b tonight and post the results.
Those users that reported addon/artwork/streaming issues (apparently curl-related), can you confirm if build #0911/#0911b resolves the issue?

Today has been a quiet day with no new commits, so there won't be a new build.
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
Movie
AVI: 1.54 GiB, 1h 51min Writting library: VirtualDub
1 Video Stream: MPEG-4 build 32593/release
Visual (XviD)
1 Audio Stream: AC-3
1580 Kbps, 720x384 (1.875), at 23.973 fps, MPEG-4 Visual (XviD) (Packed bitstream) (Advanced Simple@L5) (BVOP2)
Audio
384 Kbps, 48.0 KHz, 16 bits, 6 channels, AC-3

I just play the movie and wait. After some time audio and video are unsynchronized. If I fastforward it synchronizes. If I stop it and play again it's synchronized (a couple of jumps/stop/play at the beggining)

Video and Audio settings:
http://imgur.com/UQvGEnF,h0yAqFz,7FZDnTY
(2014-09-12, 21:53)Milhouse Wrote: Those users that reported addon/artwork/streaming issues (apparently curl-related), can you confirm if build #0911/#0911b resolves the issue?

Today has been a quiet day with no new commits, so there won't be a new build.
FWIW, I tried a couple of streaming apps (IPlayer, USVoD) with the suspect build, and was able to play content in each. There may be something other than curl in play.
@Milhouse,

Build #0911b is unusable with PVR enabled. It just enters in an endless loop: Kodi start -> pvr update -> Kodi segfault/restart -> back to pvr update -> ...
Had to nuke EPG/TV databases to start Kodi. I'll let it run overnight to test the new CEC patch.

Is this build using the latest PVR API addons bump? aka 1.9.2?

I know we're talking about a moving target, but there's something fishy with the PVR.

Build #0907 running here on two other RPis is OK...

Just to answer my one question about PVR: PR:5290
@allan87: ok thanks, I may switch back to upstream curl 7.38 for the next release if #0910 is now Ok, maybe it was an external issue.

@h.udo: Yes, #0911/#0911b both include the latest 1.9.2 pvr addons. My plan is to include the latest xbmc-pvr-addons as standard in future builds although I've a feeling this is going to cause as many problems as it solves...
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.
To be clear, I was not one of the people who alerted you to a problem with 0910.
Ok thanks. In that case if there's no feedback one way or the other I'll revert back to upstream with the next build as the point is to keep as close to OE master as possible.
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.
I've managed to reproduce the curl issues in the standard YouTube plugin. Pretty straight forward, just go to YouTube -> Explore YouTube -> YouTube Categories -> Film & Animation, and none of the thumbnails will appear (as long as they're not already in the cache) due to curl timeouts while using build #0910 (curl 7.38.0). Switch to #0911 (old curl 7.37.1) and now the thumbnails appear. YouTube video streaming also isn't possible in #0910, works in #0911.

I've chatted with @sraue, and the curl update will be reverted upstream tomorrow.
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.
@Milhouse and @mk01,

Debug log using the new CECStandbyRender patch. Problem persists: after a few hours(?) UI gets stuck at 2fps. Unusable...

There's a bunch of CecLogMessage and CecStandby in the debug log. Too many to paste here.
@mk01,

just to make your life easier, a debug log containing only CEC messages.
New OpenELEC Helix build: #0913
(Supercedes previous build)

Code:
# uname -a
Linux rpi512 3.16.2 #1 PREEMPT Sat Sep 13 20:23:57 BST 2014 armv6l GNU/Linux

# vcgencmd version
Sep  8 2014 18:59:28
Copyright (c) 2012 Broadcom
version 3f2f2607186be72e4945cfa8edc77872dfc73195 (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20140913233905-r19230-g9ab2c87 [Build #0913]

Based on tip of OpenELEC master (9ab2c87e, changelog) and tip of XBMC master (7c4baeec, 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-3.16.y
  • Excludes the OpenELEC xbmc-001-newclock3 patch in favour of sourcing these and possibly more recent patches directly from newclock4 branch
  • Default setting for "Show RSS Feed" changed to disabled
  • Disabled "Total Duration" in Confluence (see build #0221 for details)
  • Adapted service.openelec.settings to take advantage of PR5217
  • Includes latest libnfs master (49397f07)
  • Includes latest libcec master (81e38211)
  • Includes latest xbmc-pvr-addons master (39495020)
  • Includes libcec double-key suppression.
  • Includes libcec CEC Standby Fix.
  • Increase scan interval of PeripBusCEC from 5000 to 60000, reducing CPU loading by about 2% (1GHz Pi) every 5 seconds (even when CEC is "disabled")
  • Includes CONFIG_COREDUMP=y to allow creation of coredumps (see here)
  • Includes PR5222: videodb: Add column name on GROUP query otherwise sub query returns no rows
  • Includes PR5237: [WIP][3D] add support for stereomode switches in video playlist
  • Includes PR5247: StringUtils: optimize Split(), new overloads for Split() and Tokenize()
  • Includes PR5307: [UX] Play button/action should not pause
  • Includes PR5312: dvdplayer: do a seek after having changed subtitle stream
  • Includes PR5324: Add setting to hide library clean progress bar.
  • Includes PR5363: Disable textbox autoscrolling while on screensaver.
Build Highlights:
  1. Revert curl 7.38.0 upgrade.
  2. Built with proposed new linker options
Build Details:
  1. OpenELEC:
    • libcec: add upstream patches
    • gcc: add patch from fedora
    • linux: update to linux-cuboxi-3.14-e85332f
    • fuse-exfat: update to fuse-exfat-1.1.0
    • [systemd] Fix non-existant display-manager dependency
    • binutils: update to 2.24
    • boost can compile with LTO
    • boost can compile with lto
    • mesa can compile with gold
    • Revert "curl: update to curl-7.38.0"
    • compile with lto
    • binutils: update to 2.24 (PR:3476, 2 commits, 5 files changed)
    • compile e2fsprogs with lto (PR:3482, 1 commit, 1 file changed)
    • boost can compile with lto (PR:3477, 1 commit, 1 file changed)
    • mesa can compile with gold (PR:3478, 1 commit, 1 file changed)
    • [systemd] Cosmetic: Fix non-existant display-manager dependency (PR:3474, 1 commit, 1 file changed)
  2. XBMC:
    • vaapi: fix potential segfault when pp method is changed (PR:5352, 1 commit, 1 file changed)
    • dxva: fix RelBuffer, use correct CDecoder object (PR:5361, 2 commits, 1 file changed)
    • Android: Splash: Fix progressbar/text overlap (PR:5323, 1 commit, 1 file changed)
  3. Custom:
    • Added: PR:3479 compile llvm with lto and add fPIC
    • Added: PR:3480 compile with lto
    • Added: PR:3481 compile ffmpeg with lto but not for 32bit
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.
@millhouse
The PlayPause action added in PR:5307 pauses the video if I press it to stop fast forwarding a video and resume playback, unlike the old Play action.
Do you experience the same thing on your end?

Edit: Apparently the PlayPause action isn't new.
  • 1
  • 87
  • 88
  • 89(current)
  • 90
  • 91
  • 156

Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0)8