PDA

View Full Version : [GiGaBlue QUAD] Delay on keys with longpress functions (Zeus)



ronaldex
12-03-14, 10:17
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.

skippie
12-03-14, 12:24
I got the same delay with my quad.
Where can I find keymap.xml and what did you change?

sent from Pipo M9 Pro

ronaldex
12-03-14, 14:09
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>

skippie
12-03-14, 16:16
thanks :)

sent from Pipo M9 Pro

andyblac
12-03-14, 18:00
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.

skippie
12-03-14, 18:12
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.

d_f
12-03-14, 18:34
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.

GAH2402
12-03-14, 18:45
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

ronaldex
12-03-14, 18:51
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).

andyblac
12-03-14, 19:15
then is an issue with drivers. how long delay is it ?

andyblac
12-03-14, 19:16
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.

skippie
12-03-14, 20:24
This driver issue problem we didn't have with 3.0 ;)

Sent from my GT-I9300 using Tapatalk

pooface
12-03-14, 20:55
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...

skippie
12-03-14, 20:58
With all drivers we didn't have this issue

Sent from my GT-I9300 using Tapatalk

huve
13-03-14, 12:03
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.

ronaldex
13-03-14, 12:24
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+).

skippie
13-03-14, 13:07
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 :-(

alesh
20-03-14, 16:10
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..

skippie
20-03-14, 16:13
that's because PIP zap is enabled unfortunately

sent from Pipo M9 Pro

alesh
20-03-14, 16:16
I see a different reaction from open vix versions for a low press also, not only for pip feature (long press).

skippie
20-03-14, 19:21
yea slow here to ,back to 808 :-(

might go back to 3.0 also

sent from Pipo M9 Pro

judge
16-04-14, 23:55
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

judge
17-04-14, 00:52
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.