You say this works for everyone (except me) - can we confirm that? Is scroll down working for you from an IR remote? Anyone else? If so, then it would certainly suggest there's something odd about my particular setup. It doesn't rule out a bug that is only exposed by my setup but the likelihood is more that my setup is the problem. I will certainly have another look at my remote template... perhaps compare it to the MCE remote template to see if there are any glaring differences other than the obvious (IR CODES!).
Yes it is working on all systems. There is only one known bug where sometimes the SetScreenType command is not sent at all, this is not an issue on your system though.
Thanks again for your help and interest in this. I hope I'm not wasting everyone's time here with a silly mistake on my side but that's why I'm posting detail about structures and things I discover when I can in the hope that those parts of it may be useful to someone chasing down related problems in future.
I want to figure out what the heck is going one here too!
having a look at the uirt code, there is a method:
..
Edit:
Checked at home and confirmed that when I open the music or video list, the onscreen orbiter sends the message to the UIRT to say "Set screen type" but the UIRT log shows nothing. So either my assumption is wrong above that it should be logging something when this happens or there is a problem somewhere and that command is not received by the UIRT. The UIRT log is recording other things, like the unknown IR codes it receives... just not this.
This all looks good. The log event may not show depending on log levels, log levels are reduced to avoid filling your HD.
More code exploration... in the guts of IRReceiverBase.cpp - I found the method that appears to deal with received codes and even the section that seems to implement the "remote mapping hierarchy"-
...
And I think that what is happening here is that the pMapKeysToMessages structure at this point first line is trying to find a match for this particular command for a specific RemoteLayout, CurrentScreen. Then, if that fails, it tries to find one for a RemoteLayout and any screen. Then, if *that* fails, it tries to find one for any RemoteLayout and a specific screen and if that fails it tries to just find a command match.
Yep. Looks good here.
The assumption, of course, is that at this point the cRemoteLayout and m_cCurrentScreen variables are appropriately set. Who knows if that is the case or not. Presumably m_CurrentScreen is correctly set as per the CMD_Set_Screen_Type below but... who knows? Esp since that one isn't logged.
The cRemoteLayout var is set in this method but is set to a value in the m_mapRemoteLayout[] structure matched to the primary key of the remote. And I don't know where that structure is populated.
I am assuming (and fairly safely I believe) that the currentscreen is properly set. I am wondering about the RemoteLayout for your template. I am speculating here that perhaps the first is failing and that the second is matching causing the third to not get hit, which would prevent the proper codes from being sent. This is my current working theory.
Tshak mentioned earlier that the remotelayout is not used. If that is the case, then this would be an empty structure and presumably cRemoteLayout a null or something that would fail for the first and second itMessage assignments and drop through to the third.
I realize that tschak says that the remotelayout is not used (and he usually knows best), but it is being utilized in the function calls and *could* be causing an issue. The mapping is then checked against the values in the RemoteMapping table which would set the appropriate command for your chup/chdn buttons to Simulate Keypress. Everything here looks good. I'm wondering about the RemoteLayout and if that isn't where this is falling apart, even though it is 'not used'. I'm not at a system I can trace that through on right now though. Will trace that a bit when I get home. My mce remote has the remotelayout set to 'W', what is yours set for?
J.
