Media list (grid) scroll/page down button on IR remote

[jamo]

Good news! Let me know if there's anything I can test or help out with.

[phenigma]

I hope to have something for you within the week (hopefully sooner).  This issue also seems to be affecting usb game pads.

Jason.

[phenigma]

On your MD that you are trying to use the remote with can you try this .deb and let me know if it fixes the issue with your remote.

Code: [Select]

wget http://dl.dropbox.com/u/118201886/pluto-orbiter_2.0.0.45.13022727209_i386.deb
dpkg -i pluto-orbiter_2.0.0.45.13022727209_i386.deb

J.

[phenigma]

Is this happening on your core, an MD or both?

J.

[jamo]

Can try the package tonight.

It is only happening on the MD- am only trying it on the MD. Core is headless in closet.

[phenigma]

Thanks jamo, that shoots down my working theory.

J.

[jamo]

Ummm... what does that mean? Should I try it or not? What is your theory?

[phenigma]

I expect the .deb will work for you.  However, it is not the 'proper' final solution.  A step on the way to finding the actual problem.  I was seeing common issues on hybrids and thought it may be isolated to hybrids, your issue shoots that working theory but helps to narrow my search.

Let me know if it solves your issue and that will help me going forward.

Jason

[jamo]

Afraid not... .deb applied fine. I rebooted the MD and still no page down.

Tail from DCErouter.log on pressing the skip-next or ch-down buttons:

Code: [Select]

8      02/27/13 21:20:20.495           Received Message from 175 (USB UIRT 0038 / TV Room) to 10 (Media Plug-in / Server Closet), type 1 id 65 Command:Jump Position In Playlist, retry none, parameters: <0x78cfdb70>
08      02/27/13 21:20:20.495             Parameter 5(Value To Assign): +1 <0x78cfdb70>
08      02/27/13 21:20:21.599           Received Message from 175 (USB UIRT 0038 / TV Room) to 10 (Media Plug-in / Server Closet), type 1 id 65 Command:Jump Position In Playlist, retry none, parameters: <0x78cfdb70>
08      02/27/13 21:20:21.599             Parameter 5(Value To Assign): +1 <0x78cfdb70>
08      02/27/13 21:20:24.591           Received Message from 175 (USB UIRT 0038 / TV Room) to 10 (Media Plug-in / Server Closet), type 1 id 65 Command:Jump Position In Playlist, retry none, parameters: <0x78cfdb70>
08      02/27/13 21:20:24.591             Parameter 5(Value To Assign): +1 <0x78cfdb70>
08      02/27/13 21:20:37.181           Received Message from 175 (USB UIRT 0038 / TV Room) to 10 (Media Plug-in / Server Closet), type 1 id 65 Command:Jump Position In Playlist, retry none, parameters: <0x78cfdb70>
08      02/27/13 21:20:37.181             Parameter 5(Value To Assign): +1 <0x78cfdb70>
08      02/27/13 21:20:49.047           Received Message from 175 (USB UIRT 0038 / TV Room) to 10 (Media Plug-in / Server Closet), type 1 id 65 Command:Jump Position In Playlist, retry none, parameters: <0x78cfdb70>
08      02/27/13 21:20:49.047             Parameter 5(Value To Assign): -1 <0x78cfdb70>


[phenigma]

Hrmph.  Okay, that leads me to believe we've got seperate issues.  Lets work yours through again.  I see a command being sent from the UIRT to the Media Plugin. 

The incorrect command is being sent from your UIRT to the Media Plug-in to cause the list to scroll.  When my system scrolls the list it sends a 'Simulate Keypress' command.  Yours is sending the 'Jump Position In Playlist' command,  which is the 'track forward' command that would be sent to a playback device.

Hmm.  After looking at your logs and comparing them to mine, I think that button mapping/screen types are not set correctly in your template.  I've never touched an IR remote template so I'm in new territory there.  The screen type is being set and button presses are being passed to the Media Plug-in.  So, lets look at the template.

J.

[jamo]

Jason - looking back at my initial troubleshooting on this, I was pretty sure that if the screentype were set to type 'B' as it was supposed to be, then the correct command should have been fired. It all adds up. To my mind, one of two things is happening-

1. Screentype at the time of pressing the chdown button, is not in fact type 'B'     -- OR
2. The mapping/logic that combines current screentype with remote control command received is failing.

I'm not sure how to test 1... the logs seem to show that screentype is 'B' but I don't know where this goes.

But I'm going to start with the USBUIRT device code, if I can find it. Because the "Set screen type" to 'B' command is sent *to* the USBUIRT device when I open the audio list and then, that (USBUIRT) device is sending the (incorrect) "jump position in playlist" command when I press chdown. so it's a good starting point. But where do I find the code?

I usually grab it from the svn http repository. If anyone can point me in the right dir...

[phenigma]

Jamo,

The UIRT is working properly passing commands.  And the ScreenType is being sent.

Source code is in the lmce svn, feel free to have a look.  It's not like this just wouldn't work for one person though.  This works for everyone right now, except in certain cases where the ScreenType is not set properly.  I would look at the device template initially, then did you make any alterations to your database?

Definitely the remotemapping is not being set they way it should be.  But I'm in new territory here.

J.

[jamo]

Jason

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!).

I agree the UIRT is sending and receiving messages correctly and "sending" the screentype... but is it "setting the screentype". I mean, it says screentype is 'B' but where is that "stored" and when/where is that checked to adjust the commands for the current context. Watch this space.

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.

[jamo]

having a look at the uirt code, there is a method:

Code: [Select]

void USB_UIRT_0038::CMD_Set_Screen_Type(int iValue,string &sCMD_Result,Message *pMessage)
//<-dceag-c687-e->
{
m_cCurrentScreen=(char) iValue;
LoggerWrapper::GetInstance()->Write(LV_STATUS,"USB_UIRT_0038::CMD_Set_Screen_Type Screen type now %c",m_cCurrentScreen);
}
That presumably is called when the device receives the message (from the onscreen orbiter) to set the screen type to 'B'. That message was showing in my DCErouter log as soon as I chose "audio". It looks to me as if the above method should write an entry in the USBUIRT log something like "USB_UIRT_0038::CMD_Set_Screen_Type Screen type now B" or something similar. Will check when I get home. Not sure what the first command- "m_cCurrentScreen=(char) iValue;" is doing except, rather obviousl, setting the variable m_cCurrentScreen to the char cast of the passed in value.... and presumably this is the important part but I can't find any code that "reads" or "uses" this value.... yet.

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.

[jamo]

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"-

Code: [Select]

void IRReceiverBase::ReceivedCode(int PK_Device_Remote,const char *pCode,const char *pRepeat, int iRepeat)
{
if( m_bIgnore )
return;

#ifdef DEBUG
LoggerWrapper::GetInstance()->Write(LV_STATUS,"IRReceiverBase::ReceivedCode device %d code %s repeat %s/%d",
PK_Device_Remote,pCode,pRepeat,iRepeat);
#endif

char cRemoteLayout = m_mapRemoteLayout[PK_Device_Remote];
map<string,MapKeysToMessages *>::iterator it = m_mapKeyMapping.find(StringUtils::ToUpper(pCode));
if( it!=m_mapKeyMapping.end() )
{
MapKeysToMessages *pMapKeysToMessages = it->second;
MapKeysToMessages::iterator itMessage;

itMessage = pMapKeysToMessages->find(make_pair<char,char> (cRemoteLayout,m_cCurrentScreen) );
if( itMessage==pMapKeysToMessages->end() )
itMessage = pMapKeysToMessages->find(make_pair<char,char> (cRemoteLayout,0) );
if( itMessage==pMapKeysToMessages->end() )
itMessage = pMapKeysToMessages->find(make_pair<char,char> (0,m_cCurrentScreen) );
if( itMessage==pMapKeysToMessages->end() )
itMessage = pMapKeysToMessages->find(make_pair<char,char> (0,0) );
.
.
.
.

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.

Interesting.

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.

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.