Reply to thread

Message

<blockquote data-quote="cybrmage" data-source="post: 220124" data-attributes="member: 51680">Volume knob????????? The device has a volume knob??????? oh, crap!! 8-}Which is really annoying... The logs you provided definately show a 0x7E following each valid button press.... and they are consistently 109ms -125ms behind the keypress....&nbsp;&nbsp; When the display is sending a 0x7E to indicate a repeat, they are consistently 90ms to 110ms apart...Good suggestions... but I think there will be a problem with the 0x7E codes... the mediaportal logs still show that a 0x7e gets send for each button pressed, it's just not being received when it is expected...I think that the first thing to do will be to change the receive threshold from 1 byte to 2 bytes... that way we can see if there really is a &quot;matched pair&quot; for the button presses without having to do another complete rewrite of some perfectly good code (well... that's my opion of it... and I am entitled to it!! 8-} )From MHC, they appear to be consistent... I even went back to the older logs to double check... and I figure that since the delays are in the Initialize() and Cleanup() routines(), that they can't hurt...Sorry... I mis-spelled it... it should be aberrant...aberrant: deviating from the ordinary, usual, or normal type; exceptional; abnormal. (If figured, with your cerdentials, that I should probably start using bigger word in order to save face 8-} )ROFL!!!! Brilliant!!!..... I'll continue programming once I manage to pry myself of the floor!!!!Attached is a version with the receive threshold increased to two... Please test and report (with mediaportal.log please)... If it makes no difference, then we'll have another try at rewriting the logic.Regards,CybrMage</blockquote>

[QUOTE="cybrmage, post: 220124, member: 51680"] Volume knob????????? The device has a volume knob??????? oh, crap!! 8-} Which is really annoying... The logs you provided definately show a 0x7E following each valid button press.... and they are consistently 109ms -125ms behind the keypress.... When the display is sending a 0x7E to indicate a repeat, they are consistently 90ms to 110ms apart... Good suggestions... but I think there will be a problem with the 0x7E codes... the mediaportal logs still show that a 0x7e gets send for each button pressed, it's just not being received when it is expected... I think that the first thing to do will be to change the receive threshold from 1 byte to 2 bytes... that way we can see if there really is a "matched pair" for the button presses without having to do another complete rewrite of some perfectly good code (well... that's my opion of it... and I am entitled to it!! 8-} ) From MHC, they appear to be consistent... I even went back to the older logs to double check... and I figure that since the delays are in the Initialize() and Cleanup() routines(), that they can't hurt... Sorry... I mis-spelled it... it should be aberrant... aberrant: deviating from the ordinary, usual, or normal type; exceptional; abnormal. (If figured, with your cerdentials, that I should probably start using bigger word in order to save face 8-} ) ROFL!!!! Brilliant!!!..... I'll continue programming once I manage to pry myself of the floor!!!! Attached is a version with the receive threshold increased to two... Please test and report (with mediaportal.log please)... If it makes no difference, then we'll have another try at rewriting the logic. Regards, CybrMage [/QUOTE]

Verification