[f1vefour]

Is there anything I can do to fix broken plugins on kodi? I know this isn't the right place to ask but being a testing thread I figured the answer may be useful to others.

[Milhouse]

@f1vefour: contacting the add-on author for an updated version of the add-on would be the first step. If the Helix compatible add-on then works correctly on a different Helix architecture (eg. x86) or platform (eg. Raspbmc) but has errors in my OpenELEC Pi builds then that might be worthwhile investigating further.

[f1vefour]

Thanks Milhouse, I will contact the appropriate authors. I don't run on x86 so I don't know if it is Pi specific. Likely not if I had to guess.

[allan87]

I noticed something yesterday, which may has something to do with my TV turning on in the middle of the night.

When i start my RPi with my TV off, the TV turns on automatically even though i turned this feature off in the cec settings.
Shouldn`t the TV stay turned off?
Can anyone confirm this behaviour?

Same here. Happens with release versions too (i.e. 4.0.7). Not supposed to happen.

[h.udo]

[...]

I'm also seeing something fishy with newclock4 OSD and video FPS decoupled mechanism. Behaviour goes like this:

Power on RPi >> OSD FPS stays around 30 like it does with newclock3
After a while(?) >> OSD FPS drops to 2 and stays there

After FPS drop, OSD becomes very sluggish and unresponsive. I'm seeing something like 5 secs to respond to remote control, i.e. nearly unusable.

It feels like the CPU is busy with something and can't process commands fast enough. Videos play nice and without problems.

All in all, excellent work guys!

h.udo

Finally had the time to investigate this one.

This doesn't occur with newclock3, only 4. I can't pinpoint what's causing it. It takes a few hours to show this behaviour (the debug log spans over 14h) and I have absolutely no idea what's causing it.

What I find curious is that GUI render stays at exactly 2.00FPS. No variation whatsoever.

Debug log, cleaned from CEC and PVR crap. Complete debug log is available but is >18MB.

bcmstat log with GUI at ~30FPS and 2FPS.






Thanks for all the hard work!

h.udo

Hi popcornmix,

New debug log from another Pi with the same behaviour. 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.

If you need more info, debug logs, etc., just let me know. I'm on the same timezone and if you feel it can help, I can give you SSH credentials to both Pis.

[Milhouse]

New OpenELEC Helix build: #0905
(Supercedes previous build)

Code:

# uname -a
Linux rpi512 3.16.1 #1 PREEMPT Fri Sep 5 21:05:25 BST 2014 armv6l GNU/Linux

# vcgencmd version
Sep  4 2014 16:52:09
Copyright (c) 2012 Broadcom
version 2563b1662eca44dd77f49587fc3f3a4a290597c6 (tainted) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20140905205748-r19183-g75ed770 [Build #0905]

Based on tip of OpenELEC master (75ed7708, changelog) and tip of XBMC master (bb5cdbcf, 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 (5fe97d10)
  
• Includes latest libcec master (81e38211)
  
• 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 PR5245: [UX] consistent playback behavior for music and video
  
• 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
  

Build Highlights:

1. Fix for PS3 bluetooth remote.
   
2. Use a job queue when marking watched
   

Build Details:

1. OpenELEC:
   • Updated patch for 3.1.6.1 kernel driver
     
   • Mesa: update to Mesa-10.3.0-rc3
     
   • llvm: update to llvm-3.5.0
     
   • Updated patch for 3.1.6.1 kernel driver (PR:3459, 1 commit, 1 file changed)
     
2. XBMC:
   • [X11] Add support for EGL/GLESv2 when using X11 (PR:5113, 1 commit, 11 files changed)
     
   • [pvr] sync selected item between pvr windows (PR:5199, 2 commits, 7 files changed)
     
   • handle mark watched via job queue (PR:4923, 2 commits, 11 files changed)
     
   • [darwin] Add model detection for OS X (PR:5317, 1 commit, 1 file changed)
     
   • [pvr] fix selecting playing item in PVR windows (PR:5325, 2 commits, 3 files changed)
     
   • dvdplayer: remove log spam after 7ab52a00ac516ecb784f86a190fd44c523359cf7
     

[pootler]

Build #0902 includes PR5307 which changes the default mapping of the "<play>" button for various multi-button control devices (Apple Remote, PS3 Remote and also regular IR remotes). The <play> button mapping is changed from "Play" (ie. only ever start playback) to "PlayPause" (ie. toggle between playback and pause).

Please can you test the updated system remote.xml by temporarily removing any custom mappings you may have from /storage/.xbmc/userdata/keymaps/remote.xml, and restart xbmc (systemctl restart xbmc). You should still have play and pause functionality when using your IR remote with the new system default remote.xml.

If you have any unusual play or pause functionality please post details, particularly of your remote control device (ie. make/model etc.). Silence will be assumed to mean it's all good.

0902 build

Using HAUPPAUGE A415-HPG-A remote

play/pause seems to be working.

FF/RW seems to work well -much less visual distortion - however- when I try to go back to play from faster speed, then video stops,- saying \seeking\ - for a second and then if I press play, the audio continues but the video freezes?

sometimes the video starts but with audio/video out of sync by many seconds

Happens on recorded, and live ( VDR time shift) programs.
Audio files seem to FF/RW fine
Only the video component seems to freeze?


pootler

[Milhouse]

@pootler: thanks for the play/pause feedback - the change doesn't appear to be causing any problems so should be safe to merge.

[popcornmix]

FF/RW seems to work well -much less visual distortion - however- when I try to go back to play from faster speed, then video stops,- saying \seeking\ - for a second and then if I press play, the audio continues but the video freezes?

I did see something like this in my main setup, but haven't seen it when debugging - I'll try to reproduce.
This probably only affects "omxplayer" acceleration, so you could try disabling that.

[pogo1975]

Thanks Milhouse, I will contact the appropriate authors. I don't run on x86 so I don't know if it is Pi specific. Likely not if I had to guess.

Plugins does not work probably because there was a change in inserting plugins on path (now only plugins that are specified as required in addon.xml is loaded)

[pootler]

FF/RW seems to work well -much less visual distortion - however- when I try to go back to play from faster speed, then video stops,- saying \seeking\ - for a second and then if I press play, the audio continues but the video freezes?

I did see something like this in my main setup, but haven't seen it when debugging - I'll try to reproduce.
This probably only affects "omxplayer" acceleration, so you could try disabling that.

Glad to see somebody else sees it

And yes - turning off omxplayer hardware acceleration does seem to solve it ( although the responsiveness is a little bit flakier than usual)


thank you

pootler

[pootler]

Extra to above

Video searching is better without omx acceleration, but when using live tv ,if you select 'channels' ( so that the tv picture becomes minimised) then the inset preview channel stutters badly- until you go to full screen in which case the stutter disappears completely!

pootler

[Milhouse]

New OpenELEC Helix build: #0906
(Supercedes previous build)

Code:

# uname -a
Linux rpi512 3.16.1 #1 PREEMPT Sat Sep 6 22:32:19 BST 2014 armv6l GNU/Linux

# vcgencmd version
Sep  4 2014 16:52:09
Copyright (c) 2012 Broadcom
version 2563b1662eca44dd77f49587fc3f3a4a290597c6 (tainted) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20140906223038-r19194-gd66494b [Build #0906]

Based on tip of OpenELEC master (d66494b9, changelog) and tip of XBMC master (f6786284, 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 (5fe97d10)
  
• Includes latest libcec master (81e38211)
  
• 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
  

Build Details:

1. OpenELEC:
   • projects/Cuboxi/linux: enable CONFIG_UACCESS_WITH_MEMCPY
     
   • libpcap: update to libpcap-1.6.2
     
   • libgcrypt: update to libgcrypt-1.6.2
     
   • udevil: mount mmc block devices
     
   • u-boot: copy both img and imx images
     
   • projects/Cuboxi/patches/linux: add device tree for TBS Matrix system this is start of moving to common i.MX6 project
     
   • projects/*/linux: add STK1160 support
     
2. XBMC:
   • [UX] consistent playback behavior for music and video (PR:5245, 1 commit, 1 file changed)
     

[User 209257]

[...]

I'm also seeing something fishy with newclock4 OSD and video FPS decoupled mechanism. Behaviour goes like this:

Power on RPi >> OSD FPS stays around 30 like it does with newclock3
After a while(?) >> OSD FPS drops to 2 and stays there

After FPS drop, OSD becomes very sluggish and unresponsive. I'm seeing something like 5 secs to respond to remote control, i.e. nearly unusable.

It feels like the CPU is busy with something and can't process commands fast enough. Videos play nice and without problems.

All in all, excellent work guys!

h.udo

Finally had the time to investigate this one.

This doesn't occur with newclock3, only 4. I can't pinpoint what's causing it. It takes a few hours to show this behaviour (the debug log spans over 14h) and I have absolutely no idea what's causing it.

What I find curious is that GUI render stays at exactly 2.00FPS. No variation whatsoever.

Debug log, cleaned from CEC and PVR crap. Complete debug log is available but is >18MB.

bcmstat log with GUI at ~30FPS and 2FPS.

Thanks for all the hard work!

h.udo

Hi popcornmix,

New debug log from another Pi with the same behaviour. 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.

If you need more info, debug logs, etc., just let me know. I'm on the same timezone and if you feel it can help, I can give you SSH credentials to both Pis.

By any chance, are you using CEC?

I've noticed this type of behavior on my pi if I haven't used it in a bit (very sluggish UI). I have an LG TV and when I switch to another Simplink source (LG's name for CEC) and back to the pi, it seems to be back to normal again.

[h.udo]

Yes, using CEC with 2 LG TV's. Changing CEC source and back doesn't solve it. I know LG CEC implementation is crap but this is the first time I'm seeing this kind of problem.

Funny thing is I made a new newclock4 SD card, configured config.txt/OE/Kodi exactly like the old card and problem is gone. It still shows 2fps but as soon as I press any key on the remote framerate jumps to normal values, i.e., ~30fps.

Old card doesn't recover from sluggish UI. Might this be related to me performing an update from newclok3 to 4?

popcornmix, Milhouse, any thoughts?