Yo! We're geting somewhere.
FINALLY!!!!! PROGRESS!!!!!
The remote still doesn't function as nothing happens in MP
That's not exactly accurate... Yes, the remote doesn't function.... But the state machine does... And the "guess" I made on how to handle the remote's "repeat" function appears to be valid... (The last set of logs you provided confirm it).
What happens is that the received data is scrubbed of invalid data (IE: data that can not be a temperature reading, or a remote button) and then it is processed. If the state machine receives a remote button press, it caches it... and waits for the 0x7E command (This appears to be a button press indicator...)... When the 0x7E indicator is received, it fires the event that is associated with the button. (but the last version tried to fire the 0x7E and not the cached button)
If a 0x7E is received AND there is no button in the cache AND at least 100ms has passed since the last event was fired, we fire the last button we received.
but the standby sequence seems to be OK now
Good... finally 8-}
I also notice, in the last logs you posted, that the 0xA0 command has a 2 second delay after being sent, and the 0x00 0x00 0x00 sequence has a 500ms delay....
So that probably means that the 0xA0 is a "reset" command and the 0x00 sequence is probably an "attention" command.
I have added the appropriate delays to the new version.
a warning saying, that some network drives lost there connection
That would be because MediaPortal does not wait for those drives to remount... MediaPortal start right where it left off, and expects all the device to be ready when it is... I beleive that this is already a known issue...
Now we still don't know what 0xA4 0x7E is.
This sequence is always sent immediately before the 0xA4 0x76 command, so I suspect that you are correct.
0xAE definately swithces on the device's standby mode?
MHC must REALLY want the display to go to standby mode.... it sends it to the display a lot!!!
Actually... the logs show that the 0x0B byte can also be 0x6F... It appears in your logs (although 0x0B is much more frequent) and the code provided by -Manfred-... I changed it to 0x0B because I assumed that it way an aberant occurence...Definately not as this 0x0B obviously never changes...
I've used it in the past as well... I'm still searching for an alternative for you 8-}"Device Monitoring Studio 5.22" by HHD software
If you'll excuse me.... I'm going to go crawl under a rock.... 8-}I am a ......
I especially like people who open a new thread asking for a better solution, because they don't like the current solution... when they did not participate in the development of the current solution....I will never understand these ppl who get in forums like that with a rather demanding attitude
Or, those who demand that a certain feature be added because their specific OEM hardware supports it....
Or, those who demand that the latest experimental source code gets added to the SVN...
or,.... Oh... Sorry... I'm ranting again... oops 8-}
I have a simple solution when things like that happen... I ignore them. I stop developing, and I take the code that I have written and I apply it to projects that I will actually use... Their loss.... I don't use MediaPortal for my HTPC... I use SageTV.... I develop code for MediaPortal because I like that challenges that come with driver development... If it's not appreciated, I'll move on to developing something else for something else.
Fortunately... The work on this driver seems to be appreciated... 8-}
When this is done, we might discuss....
Sure... No problem...
Regards,
CybrMage