•   
  • 1
  • 123
  • 124
  • 125(current)
  • 126
  • 127
  • 156
  •   
  Thread Closed
OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0)
(2014-10-30, 23:01)Forage Wrote:
  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 guess your TV isn't sending button up events. Strange as my Panasonic does. Can you enable debugging and "CEC" component specific debugging and press a few keys and check for lines like:
Code:
10:21:13 30651.439453 T:2947544144   DEBUG: CecLogMessage - >> TV (0) -> Playback 1 (4): vendor remote button up (8B)

If you don't get any "button up" events then a non-zero release is required. It may be possible to determine this at runtime.
I've noticed the "CEC settings changed" popup only occurs once. Don't think it's related to this change but probably an existing bug. I'll have a dig around.
I'll try with a release of 400 to see if I see the same effect.
(2014-10-31, 06:52)allan87 Wrote: • 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.

Do you have a release of 0? Can you check log for "button up" events?
The lack of a button up event leads to overrunning by the release amount. If release is 0 and there are no "button up" events then the release is assumed after 500ms.
Setting release to a smaller number (e.g. 300 may overshoot less).

It could be a cpu issue where the button events are not being consumed quickly enough and the queue gets longer when scrolling.
I haven't seen that, but explain where in the xbmc UI you are when this happens, and perhaps post a log (with debug and CEC component logging enabled).
there seems to be a Problem with IPTV (simple PVR Addon) in the new builds, when i activate the LIVE TV, and look a stream in HD from my movie portal, the movie will freeze after a few minutes.

When i deactivate LiveTV everything is fine
(2014-10-31, 13:39)eikman2k Wrote: there seems to be a Problem with IPTV (simple PVR Addon) in teh ne builds, when i activate the LIVE TV, and look a stream in HD from my movie portal, the movie will freeze after a few minutes.

When i deactivate LiveTV everything is fine

Did this start occurring recently? Can you identify the first build with the problem?
it shold be teh build from 28 or 29 from this month..
(2014-10-31, 15:19)eikman2k Wrote: it shold be teh build from 28 or 29 from this month..

Can you test and identify the exact build?
(2014-10-31, 13:34)popcornmix Wrote:
(2014-10-31, 06:52)allan87 Wrote: • 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.

Do you have a release of 0? Can you check log for "button up" events?
The lack of a button up event leads to overrunning by the release amount. If release is 0 and there are no "button up" events then the release is assumed after 500ms.
Setting release to a smaller number (e.g. 300 may overshoot less).

It could be a cpu issue where the button events are not being consumed quickly enough and the queue gets longer when scrolling.
I haven't seen that, but explain where in the xbmc UI you are when this happens, and perhaps post a log (with debug and CEC component logging enabled).
I do have a release of 0, and apparently misunderstand what 'release' is supposed to do. I assumed that button up is supposed to put on the brakes so, I figured, let's do that right away, so 0 was the way to go. Clearly, I am confused.

I will do further testing over the weekend.
(2014-10-31, 17:32)allan87 Wrote: I do have a release of 0, and apparently misunderstand what 'release' is supposed to do. I assumed that button up is supposed to put on the brakes so, I figured, let's do that right away, so 0 was the way to go. Clearly, I am confused.

release=0 means rely on "button up" events (although there is a timeout of 500ms if they don't occur).
That is the ideal setting if your CEC hardware generates valid "button up" events.

If that doesn't work well, then you set a non-zero release value. That ignores "button up" events and assumes the release occurs "release" ms after the last button pressed message.
You'll probably find the CEC messages are periodic repeating "button down" messages.
Supose they repeat at a ~300ms rate, then set release a little higher than this (e.g. 350).
If you set this too low, you'll find auto-repeat isn't reliable. If you set it too high, repeat should work, but it may overshoot a little when you release the button.

if you are struggling to get value that works, then enable debugging and CEC component debugging.
Do a couple of short presses and a couple of long (e.g. 5 seconds) presses and post the log. I'll point what the imprortant messages are and what settings to try.
My testing is primarily to give you feedback as, other than the occasional double press in some builds, CEC has been very good on my Samsung.

Accordingly, I don't really need anything fixed, but if you would like me to try something specific that will give you some information you need, I would be happy to do it.

I will check to see what CEC events show up in the log, in any event.
(2014-10-31, 13:27)popcornmix Wrote:
(2014-10-30, 23:01)Forage Wrote:
  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 guess your TV isn't sending button up events. Strange as my Panasonic does. Can you enable debugging and "CEC" component specific debugging and press a few keys and check for lines like:
Code:
10:21:13 30651.439453 T:2947544144   DEBUG: CecLogMessage - >> TV (0) -> Playback 1 (4): vendor remote button up (8B)

If you don't get any "button up" events then a non-zero release is required. It may be possible to determine this at runtime.
I've noticed the "CEC settings changed" popup only occurs once. Don't think it's related to this change but probably an existing bug. I'll have a dig around.
I'll try with a release of 400 to see if I see the same effect.

Here's a snippet of the log after pressing the up and down button a couple of times with the release settings set to 0 again: http://pastebin.com/t0YuGQ3i

It does fire a button up event as far as I can tell.

Here's a log keeping the up button pressed for about 5 seconds: http://pastebin.com/dnmqbfdR
@Farage - shoudl really use pastebin type site for logs this big.

So a normal button press:
Code:
18:38:29 7109.953125 T:2952787024   DEBUG: CecLogMessage - >> TV (0) -> Playback 2 (8): user control pressed (44)
18:38:29 7110.160156 T:2952787024   DEBUG: CecLogMessage - >> TV (0) -> Playback 2 (8): vendor remote button up (8B)

This is the case where we need double press suppression:
Code:
18:38:30 7110.450195 T:2952787024   DEBUG: CecLogMessage - >> TV (0) -> Playback 2 (8): user control pressed (44)
18:38:30 7110.657227 T:2952787024   DEBUG: CecLogMessage - >> TV (0) -> Playback 2 (8): user control pressed (44)
18:38:30 7110.726562 T:2952787024   DEBUG: CecLogMessage - >> TV (0) -> Playback 2 (8): vendor remote button up (8B)

Note, two messages 207ms apart. So you need the "delay" setting greater than that to supress the second message.

The long press looks fine. It seems to send a pressed event every 400ms and then a "button up" at end.
This should work fine with release=0 (relying on the "button up" message).

With repeat disabled you'll get 2.5 repeats per second when held down. You should be able to configure for faster repeats if you want.

I'd suggest using my recommended settings of 300/80/0.
Please, use pastebin for such long logs - some of us use Tapatalk to browse the forum on mobile devices and now this page of the thread is completely inaccessible!
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-10-31, 20:03)Milhouse Wrote: Please, use pastebin for such long logs - some of us use Tapatalk to browse the forum on mobile devices and now this page of the thread is completely inaccessible!
My apologies! Fixed!
(2014-10-31, 19:54)popcornmix Wrote: The long press looks fine. It seems to send a pressed event every 400ms and then a "button up" at end.
This should work fine with release=0 (relying on the "button up" message).
It will fail to autoscroll with your default settings 300/0/0 if you keep the button pressed. At least, in my case. This can't be desired behaviour. Doesn't 0 for the repeat setting default to a sane value?
(2014-10-31, 19:54)popcornmix Wrote: I'd suggest using my recommended settings of 300/80/0.
Settings the repeat to a value higher than 0 does indeed fix the autoscroll as well, like increasing just the release setting. Strange that 0 for just the release setting, which should default to the device time, does not work. Again because of no sane default value for the repeat setting?

Repeat setting 80 is fine for some lists, but results in madness on the main XBMC menu screen when keeping left or right pressed btw. I'll lower it to a good balance.
If you wanted to be REALLY fancy, the repeat speed could initially be slow and accelerate with a longer button press.
  •   
  • 1
  • 123
  • 124
  • 125(current)
  • 126
  • 127
  • 156
  •   
  Thread Closed
 
Thread Rating:
  • 8 Vote(s) - 4.88 Average



Logout Mark Read Team Forum Stats Members Help
OpenELEC Testbuilds for RaspberryPi Part 3 (Kodi 14.0)4.888
This forum uses Lukasz Tkacz MyBB addons.