[Forage]

Works like a charm! I wasn't able to reproduce the double key issue. Great to see that it has been properly fixed instead of using a work-around.

One thing I did notice is that responding becomes relatively slow when you press a key really, and I mean almost abnormally, fast. It actually goes faster when you press slightly less fast. Could this be because of the time-out increase?
I used the shutdown menu as a low action list instead of e.g. the movie library with heavier loads on switching entries for testing.
I do want to be able to navigate relatively fast every once in a while and the delay is on the fringe of being possibly annoying right now.

I'm happy with this being fixed in it's current state nevertheless.

Yes. The Panasonic TVs generate two button press events if you hold the button for more than about 250ms (which is a quite normal duration for a button press).
The workaround is to reject a second button if it occurs within ~300ms of the first.
Unfortunately two rapid presses produces the same result as the single leisurely press which means they also get filtered out.

I've been working on improving the behaviour of CEC remotes.
Currently when you hold down a button it repeats at a rate chosen by the TV. Typically that is between 2 and 5 times per second (varies with TV manufacturer).
This is a much slower repeat than a keyboard (repeats 12 times per second) which makes scrolling long lists slow with CEC.

My plan is to (optionally) ignore the CEC presses and generate a different stream of presses with a configurable repeat rate, (e.g. allowing 12 repeats per second).
Unfortunately CEC devices are pretty inconsistent in behaviour. It can be impossible to distinguish a few quick presses from a single longer press.
Some devices generate button released events which are useful, but the Sony in front of me doesn't always...
So I'll allow a few settings to tweak how it behaves and we'll see if people prefer it (the default will behave how it always has).

Not ready for tonight, but maybe tomorrow night.

It sounds like a lot of work for just a slightly better user experience. Though if it's perfection you're striving for... ;-)

Making these options available in the UI settings is handy during testing, but it introduces quite some complexity for the average user who are likely to mess things up. I'd recommend making them config file only settings at some stage and maybe introduce them again in the UI when there's a distinction between normal and expert settings on that level.

Thanks for the effort though, I sure will test the latest nightly and report my findings.

[allan87]

I agree that "Making these options available in the UI settings… introduces quite some complexity for the average user…". However, putting the tweaks into a config file makes it even more complicated and leaves the average user out in the cold.

In terms of user experience, since the CEC problems arise from inconsistent implementation from one manufacturer to another, an ideal solution would be to detect the manufacturer (I think that's possible over HDMI) and automatically configure settings that conservatively adjust for the particular manufacturer's ugliness.

[popcornmix]

In terms of user experience, since the CEC problems arise from inconsistent implementation from one manufacturer to another, an ideal solution would be to detect the manufacturer (I think that's possible over HDMI) and automatically configure settings that conservatively adjust for the particular manufacturer's ugliness.

I suspect it's more complicated than that. I wouldn't be surprised if a 5 year old Sony behaves differently from a 1 year old Sony.
For now I'd like reports like:

300, 80, 0 worked well on a Panasonic TX-P50VT30B.

or

300, 80, 0 didn't auto-repeat on a LG 42LB585V.
300, 80, 300 was the best setting for a LG 42LB585V. Auto-repeat worked, but it tended to overshoot when scrolling.

If we get a few dozen reports like this, we may be able to decide whether to automatically enable it for some manufacturers.
Maybe we'll decide that just an enable/disable setting is sufficient, as 300,80,0 works as well as any other enabled setting.
Maybe we'll decide that it's just a feature for test builds and is not ready for Helix.

But without people testing and reporting back we won't get anywhere.

[da-anda]

popcormnix - why bother with the CEC button repeat stuff? one click to the left/right and you focused the scroll bar and can browse quite fast - even with slow CEC repeat times.

[popcornmix]

popcormnix - why bother with the CEC button repeat stuff? one click to the left/right and you focused the scroll bar and can browse quite fast - even with slow CEC repeat times.

You could make the same argument about keyboards and IR remotes not needing to repeat, but they do.
Some controls in xbmc (like volume, amplification, audio offset) take forever to get from one extreme to the other with a CEC remote.
I think for consistency all remotes should behave the same way if possible.

[Milhouse]

It also takes forever to change volume with an IR remote as the volume control doesn't seem to support auto-repeat at all.

[popcornmix]

It also takes forever to change volume with an IR remote as the volume control doesn't seem to support auto-repeat at all.

It does now repeat (now) with CEC. Takes 11 seconds to get for min to max volume. Seems to be the same as an iOS remote (and presumably a keyboard).
I feel the IR remote should (ideally) behave the same way.

[Milhouse]

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

Code:

# uname -a
Linux rpi512 3.17.1 #1 PREEMPT Wed Oct 29 21:40:05 GMT 2014 armv6l GNU/Linux

# vcgencmd version
Oct 17 2014 17:56:05
Copyright (c) 2012 Broadcom
version 845092531e360acd37f2f1964157f8079c77edfb (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20141029213853-r19488-g4132867 [Build #1029]

Based on tip of OpenELEC master (41328677, changelog) and tip of XBMC master (d76d8f65, 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.17.y
  
• Excludes the OpenELEC xbmc-001-newclock4 patch in favour of sourcing these and possibly more recent patches directly from newclock4 branch
  
• Default setting for "Show RSS Feed" changed to disabled (new installs only) [patch details]
  
• Disabled "Total Duration" in Confluence (see build #0221 for details)
  
• Adapted service.openelec.settings to take advantage of PR:5217 [patch details]
  
• Includes latest libnfs master (ab1af695)
  
• Includes latest libcec master (9be2206f), with latest testing commits from popcornmix
  
• Includes latest xbmc-pvr-addons master (067befe6)
  
• Includes latest xbmc-addon-xvdr master (2bf2563c)
  
• Includes CONFIG_COREDUMP=y to allow creation of coredumps (see here)
  
• Includes additional ffmpeg codecs/muxers enabled for testing/benchmarking purposes. See patch
  
• Includes commits from libcec-2.2.0 (popcornmix)
  
• Includes PR:5312: dvdplayer: do a seek after having changed subtitle stream
  
• Includes PR:5416: added: POC mp4 movie/episode tag support
  
• Includes PR:5573: webserver: improved caching control (see discussion)
  
• Includes PR:5584: HTTP/Webdav encoding fixes - Fixes ticket #15365
  
• Includes PR:5587: Invalidate path hash on remove so the infoscanner can pick it up again
  
• Includes PR:5593: fix script.library type missing in runscript/runaddon checks.
  
• Includes PR:5601: [videodatabase] speed up the video database cleanup for archives
  
• Reverts e502b099: Segfault accessing DVD ISO/IFO over SMB (see PR5534)
  

Build Highlights:

1. Support for several new USB tuners
   
2. Faster video library cleaning of archives
   

Build Details:

1. OpenELEC:
   • linux: Add support for TechnoTrend CT2-4400 and 4650 USB tuners (PR:3581, 1 commit, 4 files changed)
     
   • linux: Add support for the DVB-T2/C tuner of DVBSky T9580 (PR:3583, 1 commit, 1 file changed)
     
   • [uefi] enable 32bit uefi support (PR:3574, 1 commit, 3 files changed)
     
   • enca: update to enca-1.16
     
   • linux: replace default hostname with $DISTRONAME while building
     
   • add package 'libirman'
     
2. XBMC:
   • fixup 5f5d8c86490510f49b82d05ff16011bfbf4cbfa8; re-add default joystick map (PR:5600, 1 commit, 1 file changed)
     
   • [darwin] - some pending xcode project changes (xcodes does those whenever opened so lets commit them)
     
3. newclock4:
   • [cec] Update to match header from libcec-2.2.0
     
4. Custom:
   • Added PR:5601: [videodatabase] speed up the video database cleanup for archives
     

[Milhouse]

It does now repeat (now) with CEC. Takes 11 seconds to get for min to max volume. Seems to be the same as an iOS remote (and presumably a keyboard).
I feel the IR remote should (ideally) behave the same way.

Yes, it seems odd that the IR remote doesn't auto-repeat - I have to mash away on the up/down buttons for ages.

Fortunately changing the volume isn't something I do often (it's either 100%, or muted), just something I've noticed while testing things.

[gendo]

Were these files usefull or do you need anything else?

Popcornmix i see that you reverted "hack: revert squash: don't update originaldts when marked as invalid", and now when there is a glitch in video it takes very long to resume and once it resumes it is like in slow motion once again. Anyway i updated to latest build and enabled dump out audio/video data.. here is a link to zip file containing relevant files https://dl.dropboxusercontent.com/u/5174...0Debug.zip . the behavior observed is that video/audio freeze for over 1 minute and then resume but are not smooth and sound is like breaking up. If i revert to the older build (29th) video audio resume correctly a couple of seconds after glitch..

popcornmix issue appears also on windows so i opened a bug report http://trac.xbmc.org/ticket/15514

[f1vefour]

I wouldn't normally ask a question like this but I am at wits end.

My Internet is often slow and when I try to start a Internet stream it will often timeout before starting after around 20 seconds. Is there a way to increase this timeout? I ask because I don't know what this function is called or if there is a way to adjust it.

[sparticle]

If I wanted to try out these builds on my test Pi B+ what do I need to do!

Is there a how to guide somewhere? Do I need to install openelec first and then download your tar etc.

Have been a RaspBMC user for a long time so OpenElec is new to me.

I currently have a Raspbian B+ that has Michael Gorvens xbmc repo on and Helix Alpha 4.

Cheers
Spart

[Forage]

Build Highlights:
[*]Add extra libcec de-bounce commits from popcornmix - new delay/repeat/release options in Settings -> System -> Input devices -> Peripherals -> CEC Adapter

If you use CEC then please test this.

New settings in system/input/peripherals/cec.

delay: duration before repeating (ms)
repeat: rate the button will repeat at when held (ms)
release: duration after less pressed message until button is considered released (ms)

Funky things are happening here.

For your reference, I've tested with a Panasonic TX-P42G30E.

1. Having the settings on 300/0/0 (default) will perform an action only ones when keeping the button pressed.
   
2. Changing the release setting to at least 50 fixes this.
   
3. Setting release to at least 250 is then required to prevent double actions from occurring
   
4. Changing the CEC settings also only works ones. After the first go you get the updated notification after pressing OK, this doesn't happen on a second attempt. A reboot is required to apply a subsequent change. The settings of the first change will be used until that time.
   
5. Setting release to 400 or higher makes it stop repeating again when keeping the button pressed
   

I haven't changed the delay and repeat settings yet.

[Milhouse]

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

Code:

# uname -a
Linux rpi512 3.17.1 #1 PREEMPT Thu Oct 30 21:03:56 GMT 2014 armv6l GNU/Linux

# vcgencmd version
Oct 17 2014 17:56:05
Copyright (c) 2012 Broadcom
version 845092531e360acd37f2f1964157f8079c77edfb (clean) (release)

# lsb_release
OpenELEC (Milhouse) - Version: devel-20141030210245-r19491-ge7e7ba0 [Build #1030]

Based on tip of OpenELEC master (e7e7ba0e, changelog) and tip of XBMC master (b8a89e5e, 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.17.y
  
• Excludes the OpenELEC xbmc-001-newclock4 patch in favour of sourcing these and possibly more recent patches directly from newclock4 branch
  
• Default setting for "Show RSS Feed" changed to disabled (new installs only) [patch details]
  
• Disabled "Total Duration" in Confluence (see build #0221 for details)
  
• Adapted service.openelec.settings to take advantage of PR:5217 [patch details]
  
• Includes latest libnfs master (ab1af695)
  
• Includes latest libcec master (9be2206f), with latest testing commits from popcornmix
  
• Includes latest xbmc-pvr-addons master (067befe6)
  
• Includes latest xbmc-addon-xvdr master (2bf2563c)
  
• Includes CONFIG_COREDUMP=y to allow creation of coredumps (see here)
  
• Includes additional ffmpeg codecs/muxers enabled for testing/benchmarking purposes. See patch
  
• Includes commits from libcec-2.2.0 (popcornmix)
  
• Includes PR:5312: dvdplayer: do a seek after having changed subtitle stream
  
• Includes PR:5573: webserver: improved caching control (see discussion)
  
• Includes PR:5584: HTTP/Webdav encoding fixes - Fixes ticket #15365
  
• Includes PR:5587: Invalidate path hash on remove so the infoscanner can pick it up again
  
• Includes PR:5593: fix script.library type missing in runscript/runaddon checks.
  
• Includes PR:5599: filesystem: add COverrideFile/COverrideDirectory to reduce code duplication
  
• Includes PR:5601: [videodatabase] speed up the video database cleanup for archives
  
• Reverts e502b099: Segfault accessing DVD ISO/IFO over SMB (see PR5534)
  

Build Highlights:

1. Added PR:5599: filesystem: add COverrideFile/COverrideDirectory to reduce code duplication
   
2. Add support for calling OnResetDevice on display mode change (see PR:325)
   

Build Details:

1. OpenELEC:
   • OpenELEC-settings: update to OpenELEC-settings-0.5.1
     
   • sqlite: update to sqlite-autoconf-3080701
     
   • openvpn: update to openvpn-2.3.5
     
2. XBMC:
   • [rbp] Fix for orientation handling of Pi textures (PR:5555, 1 commit, 4 files changed)
     
   • README fixes and rebranding (PR:5606, 1 commit, 3 files changed)
     
   • [droid] update Android manifest with <uses-feature> (PR:5576, 1 commit, 1 file changed)
     
   • [ios] - update readme
     
3. newclock4:
   • Add support for calling OnResetDevice on display mode change
     
4. Custom:
   • Added: PR:5599: filesystem: add COverrideFile/COverrideDirectory to reduce code duplication
     

[allan87]

New settings in system/input/peripherals/cec.

delay: duration before repeating (ms)
repeat: rate the button will repeat at when held (ms)
release: duration after less pressed message until button is considered released (ms)

delay should be set as low as possible, without unwanted double presses
increase rate for faster scrolling of lists when held down. The keyboard in xbmc uses 80ms.
if release is zero, we just rely on the released messages through CEC. Otherwise released messages are ignored and the release will occur after this duration.

I'd suggest trying delay=300, repeat=80, release=0 as a starting point, which works well on my Panasonic.

I tried a few different settings on a samsung C7000 series.

• 200 ms before repeating was fine. I did not see any point trying faster. 300 would also have been fine.
• I went as high as 150 on repeat rate, because I felt the repeat had to be slowed down. Even at 150, the interface lagged behind the button press - although it started to repeat quickly, it didn't start scrolling fast until a fairly sustained button down, and then it significantly outran the button release. I had to get the hang of how it responded, because it would inevitably run past 5 to 10 more items after button release.