View Full Version : [GiGaBlue QUAD] Delay on keys with longpress functions (Zeus)
After installing the new Zeus release on my GB Quad and it felt slower then then 3.0 version.
I've noticed there have been added some longpress functionalities to the (channel) up/down buttons. These longpress actions (logically) add a delay to the buttons which makes the reciever feel slow in reacting on normal keypresses. I normally use a Harmony remote, but the original remote seems to have the same problems.
Features on longpresses can be a nice addition, but I don't think they should interfere with the receivers basic functionalities (viewing tv, zapping, navigating the channel- / bouqet-list).
I've changed the values in keymap.xml and the reciever is reacting as it should again. I prefer a fast channel switching and navigation to things like PiP zap any day.
I got the same delay with my quad.
Where can I find keymap.xml and what did you change?
sent from Pipo M9 Pro
The file:
/usr/share/enigma2/keymap.xml
Changes:
<map context="InfobarChannelSelection">
<key id="KEY_LEFT" mapto="LeftPressed" flags="mr" />
<key id="KEY_RIGHT" mapto="RightPressed" flags="mr" />
<key id="KEY_UP" mapto="switchChannelUp" flags="m" />
<key id="KEY_DOWN" mapto="switchChannelDown" flags="m" />
<!--
<key id="KEY_UP" mapto="switchChannelUpLong" flags="l" />
<key id="KEY_DOWN" mapto="switchChannelDownLong" flags="l" />
-->
<key id="KEY_PREVIOUS" mapto="historyBack" flags="mr" />
<key id="KEY_NEXT" mapto="historyNext" flags="mr" />
<key id="KEY_BACK" mapto="historyBack" flags="mr" />
<key id="KEY_FORWARD" mapto="historyNext" flags="mr" />
<key id="KEY_CHANNELUP" mapto="ChannelPlusPressed" flags="m" />
<key id="KEY_CHANNELDOWN" mapto="ChannelMinusPressed" flags="m" />
<!--
<key id="KEY_CHANNELUP" mapto="ChannelPlusPressedLong" flags="l" />
<key id="KEY_CHANNELDOWN" mapto="ChannelMinusPressedLong" flags="l" />
-->
<key id="BTN_0" mapto="zapUp" flags="mr" />
<key id="BTN_1" mapto="zapDown" flags="mr" />
<key id="KEY_SAT" mapto="openSatellites" flags="m" />
</map>
thanks :)
sent from Pipo M9 Pro
remember changing this file will get reverted on every update.
why not just let go of the button quicker ?
Rob van der Does
12-03-14, 18:03
remember changing this file will get reverted on every update.
Exactly. Messing system-files is never a good idea (IMHO).
Anyway: what if you just use a short-press? As said before: the box reacts on letting the button go, not on pressing it.
Guys, what do you think most ppl would like :
pip-zap at cost of faster zapping or
faster zapping without pip-zap?
letting the button go quicker doesn't make it faster zapping.
I liked my fast-zapping quad, not this way.
It's just copying over the keymap.xml time after time, I guess.
sent from Pipo M9 Pro
Rob van der Does
12-03-14, 18:16
I don't have a quad, but on the boxes I do have there's no slower zapping then before.
I 100% agree with skippie, I rarely use pip and have no use for the long press, and pressing it quickly does not make it quicker. Please give us the option to turn it off, otherwise we will have to overwrite the key map.xml after every update. My Quad is a lot quicker now the keymap file has been amended.
Hi,
Pointed out the exact same issue yesterday, and just to confirm, releasing the button quicker makes no difference at all.
http://www.world-of-satellite.com/showthread.php?36152-Slight-delay-on-calling-up-Bouquet-List-(Zeus)
GAH
I'm aware that changes will be lost after an update, but it's the only way of 'fixing' it for now (for me at least).
Like stated above, short-pressing a button doesn't help, there is a delay of ca. 1 sec for all buttons with long-press functions (on my gigablue quad).
then is an issue with drivers. how long delay is it ?
short-pressing a button doesn't help, there is a delay of ca. 1 sec for all buttons with long-press functions (on my gigablue quad).
then def a driver issue, no such delay on ET's, VU's etc.
This driver issue problem we didn't have with 3.0 ;)
Sent from my GT-I9300 using Tapatalk
This driver issue problem we didn't have with 3.0 ;)
Sent from my GT-I9300 using Tapatalk
And did you update the drivers to the latest in the older 3.0 build??? Or, was it using the older drivers, so a bug could've been introduced with newer drivers?
Personally haven't got a gb machine myself, so don't know. But the vu/et I've tested haven't shown these issues...
With all drivers we didn't have this issue
Sent from my GT-I9300 using Tapatalk
I went back to 808, because of slow button response and I don't have time at the moment to make all my settings to Zeus.
I didn't have time to test with vix 3.0 yet, but I think the issue was already present.
It just wasn't as noticable because of the type of keys that had key-release / long-press actions (color-keys instead of main-navigation / ch- / ch+).
I didn't have this problem at all with 3.0
sent from Pipo M9 Pro
wangled592
13-03-14, 17:33
yea slow here to ,back to 808 :-(
I see slow reaction when I push up and down channel button (not in bouquet). I have gigablue quad..
Openvix 3.0 was more reactive..
that's because PIP zap is enabled unfortunately
sent from Pipo M9 Pro
I see a different reaction from open vix versions for a low press also, not only for pip feature (long press).
yea slow here to ,back to 808 :-(
might go back to 3.0 also
sent from Pipo M9 Pro
Have any of you tried todays GBQuad drivers with Zeus 022?
http://archiv.openmips.com/gigablue-drivers-3.3.8-2.0-gbquad-20140416.zip
Makes it feel like a new box... but we need more feedback to make sure nothing else has broken.
BubbleBalls
17-04-14, 00:26
There's a report that today's drivers still make some timers record with zero lenght of time, a more important feature, methinks.
Tapatalker
Think that was drivers dated 15th & should have a fix in drivers dated 16th? Never had this issue with my quad so hard to tell here, but all recordings working fine so far with these drivers.
Powered by vBulletin® Version 4.2.5 Copyright © 2024 vBulletin Solutions Inc. All rights reserved.