If not in a VM, it would be ctrl + alt + f2

Of course, forgot the alt.

What's wrong with me, I used to be so precise.
I mean lucid. Precise will come.

One question though, how do I get to anything other than the Flickr art? When the computer boots up it goes right into the flickr background with the arrows. I'm not a Linux pro, so I'm not sure what to do to get around this..

I think what ggmce meant was- how do I get to a command prompt to run the commands that l3mce suggested. I don't think he wanted to know how to change the screensaver at this stage ;-)

For future reference- you should be able to drop to a terminal by pressing ctrl-F2. That should present you with a terminal where you can log in with your normal username and then "su -i" to become root.

The future of AV.

One day LMCE will not fight alsa, it will bend it to its will, and audio will "just work" on everything.

One day lmce video of any kind will play cleanly on almost everything without fiddling with it.

That is the only future of AV I can see from behind all the code.

And if you have anything to do with it, this will be the case, I am confident.

Another thought/question I've come across in the search for AV-control info/understanding/enlightenment-

App-control is a term that seems to be bandied around a bit. As I understand it this is the ability to download an APP to control your HT Receiver. Presumably to do this the Receiver must either be networked (wired/wireless) or bluetooth enabled. If the former, would a receiver that advertises App-control be easy (relatively) to setup a device template for, based on the assumption that the control protocol must be available if there is an APP that uses it? Any thoughts?

Re Motion wrapper: It is no longer really needed. Thanks to sambuca's advanced IP camera template, we no longer need the crouch motion.

Personally, I think I'd like to see zoneminder neatly integrated into LMCE. I've been experimenting a little with it and it looks really solid, powerful and extensible. If I could just clone myself (with a few enhancements ;-) I could spend some time on it. So many projects.

Well done, guys. Great punt Tschak- that's a darned useful summary for newbies. A nice default welcome pack/summary to send people who're curious.

Thanks J, agreed on just about all counts there.

Unfortunately my remote layout is also set to 'W'. In fact, for fear my template was the problem, I compared my template with the MCE Remote template side-by-side and the only difference was that the MCE Remote template had a "controlled by category" set to media director. So I set mine to the same, reboot etc but no change.

Shew....

I'm pretty stymied.

All I can think of is hacking into the USBUIRT code at that section I posted - where it takes the decision about the command and outputting everything that is going on to a custom (or normal) log and then compiling that and running it on my system. Prob is, I haven't the faintest idea how to do that... actually, I do... I think I need to set up a development system or something. Somewhere in the wiki about it. I'll read up. Probably about time I contributed, eh? Necessity is a mother.

http://wiki.linuxmce.org/index.php/Building_From_Source

Guess that's it ^^

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:

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.

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

Code:

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.

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.

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

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:

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>

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

Can try the package tonight.

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

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

Thanks, J.

No, the remote is not an Win MCE remote, it is the remote I got with the Zotac AD04 z-box I'm using as a media director. I  set up a template for it myself.

I guess pg-down is first step and it at least looks as though it is supposed to work whereas it seems as if using an IR remote for the "letter list" is not part of the plan.