Page 1 of 2
Posted: Sun Dec 02, 2018 2:03 pm
XMBC Version: 2.17
Windows Version: Win 10 Pro 64
Mouse Information (brand/model): SteelSeries Rival 100
Computer Information: All is up to date, 8 Gb ram
Did the problem occur after an upgrade of XMBC or Windows?: not sure
How long have you used XMBC?: 24+ months
What language and keyboard layout do you use in Windows?: English USA
Clear description of the problem:
I need to use the Windows Magnifier so I used your software to link the Button 4 to Magnifier toggle on/Off function. I made sure to set it on both layers of the Default profile and also made a profile just for Firefox to be sure.
But when I click the button 4 not only the Magnifier open it also switch back to the previous window, whether I am in Firefox or any other programs that save a previous state, example Notepad++ if I moved from one opened page to another then it will go back to the previous page. I think it's the Default function in Windows. So it does two things when I click button 4, yours and the Windows Default.
As I stated above I am not sure if it's following an update because I have been in and out of hospitals in the last 12 months and probably didn't kept up to date on what's going on exactly with my machine.
But I am quite certain it didn't behave like that in the past.
I tried Button 5 or the Middle button and still behave the same way, it open the Magnifier and still execute the default function of whatever buttons I use.
Any idea why the Default is still working when using your software?
n.b. I tried with SteelSeries drivers and without, meaning just the generic Windows driver and I get the same results.
Thanks for your time.
Posted: Sun Dec 02, 2018 3:14 pm
Odd. Normally, XMBC blocks the button press when remapping it - and in this case it sounds like either XMBC is not blocking it, or something else is causing a default button 4 message to get through to Windows too.
Can you turn on debug logging for a bit (in the settings logging & updates tab - OK and APPLY that) then press the button 4 a few times (where it causes both magnify and back to trigger) then send me the log.
That will at least tell me if XMBC is blocking the default action or not - and we can proceed further from there.
Posted: Sun Dec 02, 2018 3:39 pm
Just had a quick look here and it happened for me too... Once!
It looks like the call to launch the magnifier may be throwing an exception that causes XMBC to not block the back button - so I can fix that BUT I'm not convinced that its the same problem so I would like to see your log to make sure its the same though.
Also, if the magnifier is already open and you press the button 4 (to close the magnifier) does that also cause a back to be sent or not (I suspect not but would like confirmation).
Posted: Mon Dec 03, 2018 7:08 pm
I got the log file but it's too big to paste it here and I cant find way to send it to you.
How do I proceed?
p.s. No it wont roll back if the magnifier is already opened. Not so far anyway.
Posted: Mon Dec 03, 2018 8:38 pm
You can zip up the log file and email it to me (phil at highrez dot co dot uk).... Or you can PM it to me here and attache the zip (you should be able to add attachments to the PM) or you could send it via something like pastebin (never used that myself).
OK, have you tried 2.18 beta 14 by any chance? I put a new exception handler in there that I hope might fix the problem - your log would still be useful of course!
Posted: Tue Dec 04, 2018 8:34 pm
Since I can't figure how by PM, I see no way to attach a file. I emaled it to you instead.
Posted: Tue Dec 04, 2018 10:45 pm
OK thanks got it...
Having looked, I do think 2.18 beta 14 (or 15) will fix it. But I need you to test that.
The beta is available here
Posted: Wed Dec 05, 2018 2:28 am
I already checked that thread but couldn't find the link for the file. Getting old sux.
n.b. Finally found the link for the file. I will install it now.
Posted: Wed Dec 05, 2018 2:40 am
I got the beta installed and linked the button 4 to Magnifier toggle On/Off.
Then opened a page in Firefox, moved to another site within the same page/tab.
Clicked on button 4 to toggle On the magnifier, then it roll back to the previous site.
So the issue still occurring it seem.
Posted: Wed Dec 05, 2018 8:32 am
That's going to make it more difficult then (I thought it was an easy one when it happened here that once because that was an obvious one).
Clearly its not going to be so obvious.
Leave it with me.
Posted: Wed Dec 05, 2018 8:50 am
I notice in your log that your hook timeout is set rather low (windows default) 200ms.
And you are getting an awful lot of hook timeouts. This may well be causing the problem.
Can you try increasing the hook time out to 1 second (1000ms) in the advanced settings tab. You will have to reboot after making this change before it is applied. Then see if the problem still occurs?
Posted: Thu Dec 06, 2018 2:25 am
If you mean the Windows low level hook timeout, in the beta(v2.18 Beta 15) that I have installed at the moment it is already a 1000ms.
Posted: Thu Dec 06, 2018 1:43 pm
Yesterday I increase the value to 1200 ms and this morning all the test I did were positive. So far no rolling back .
I will report back later today after a day of testing.
Posted: Thu Dec 06, 2018 7:52 pm
OK I do mean that setting - the log file you sent (pre 2.18 beta 15) it was saying it was set to 200ms (which is also the windows default when no value is set). Maybe installing 2.18 beta 15 set it back to 1000ms (I thought I set it higher than that by default - I used to use 2500ms) but in any case, it sounds like this is related and it makes much more sense.
For whatever reason, its taking more than 200ms or even 1000ms (1sec) to launch the magnifier which is blowing the hook timeout and causing the button to get leaked through. This may be because the disk drive is slow or simply that Windows is slower than it used to be (which shouldn't surprise me what with all the Intel CPU spectre patches that reduce performance - that alone may have been enough to push it over the edge).
What this tells me is that XMBC should NOT be trying to launch the process in the same thread while the hook is executing. It should queue it and let the hook release whilst launching from a separate thread - which will avoid all these problems of the launch potentially taking too long and timing the hook out. So whilst increasing the hook timeout is a workaround for now, I will try and change the code to launch any executable/explorer window etc outside of the time critical hook procedure - so a worthy investigation
Posted: Sat Dec 08, 2018 2:20 pm
Well so far all is good.
Glad my problems could be of any help
Thanks a lot for your help and patience.