Hi Phenigma

Thanks for having a look at this. I will try to apply and test your patches on my false positives (hp6710b notebooks accelerometer) and let you know. Will be great if this is addressed.

Thanks for the reply, phenigma. I can at least confirm, then, that the UIRT is not transmitting (no red LED flashing on test code).

Will scour the logs on the MD. From memory, though, I believe there is no log for the "child" device- embedded transmitter at all. If you get a moment, would be handy if you could let me know if your MD with UIRT connected has a log for the child device... ie whether I should expect one.

I actually re-installed (ie deleted devices and then re-plugged them in) the UIRT over the weekend but that didn't help anything. Regarding the room association, I posted a screenshot higher up on the log that shows, as I interpret it, that the UIRT is assigned to the correct room.

Will tinker more this evening.

Thanks Thom, I found that one after much experimenting! Will post screenshot when I get home to help others.

And, in fact, it appeared that the 'buttons" were immediately gone from the UI2 menus although I have yet to confirm this. In fact, I have a feeling that regenning the orbiter brings them back but I'll confirm both of these later.

Either way, my scenarios are gone from the menu and all is much cleaner, many thanks.

I know the embedded transmitter (usb uirt embedded transmitter) is a child device, sort of a dummy device as referred to by Tshak, but should it still have a log file? Only the parent has a log file in my case (the parent being the receiver, which is working).

I do get the "some devices failed to start" message when I start up my MD. How do I track down which devices? Is it possible that the embedded transmitter is the one failing? Is it supposed to start (being a dummy/child device and all)?

I created a TV template for my TV as per the wiki entry. In order to be complete, and so others can potentially use it, I defined all the 11 or so inputs to the TV, even though at present I'm only using 2 of them.

I found that when I regened the orbiter, I now had scenarios for all the inputs on my TV. Fair enough, but I then went and deleted the scenarios I didn't need for now. After the next reload or regen or something (ie soon after!) all my scenarios are back. Hmmm. That's a bit of a pain because my media menu now is rather long with the majority of the buttons being meaningless to me.

Is it possible to delete scenarios more permanently or will the always be regenerated when you regen the orbiter?

Do I have to delete the individual inputs from my TV device that I'm not using? I presume this would not affect the template so I could still later upload the template for others to use if I'm happy with it.

Or should I disable the individual inputs - I see there is a "disabled" checkbox in the device in the wizard.

Any advice?

thanks
James

Haven't had a chance to look into this further yet, still fiddling with the remote mapping for the receiver, but I wanted to ask if anyone has one (USBUIRT) working as a transmitter in 10.04? If so, when you transmit a code (say in "Test" mode when you are entering codes and you press the test button), can you see a flash from the unit? I've tried using my mobile phone camera to watch the unit and I don't see anything so I'm presuming it isn't happening.

I see there was a bug in 07.10 and there are a few references in the wiki to transmission problems and I haven't tried any of those fixes, assuming they are no longer an issue in 10.04?

Anyone care to comment?

I need to see the from and to device parameters of the Set Screen Type, to see where the message is going.

-Thom

Ok, here's the log from the time I hit "enter" via IR remote on the "Audio" menu to the time I try to press the chdown button on the remote. Sorry about all the "populate data grid" nonsense but I didn't want to clip it and lose something.

Clipped section below:

Code:

8      01/30/13 20:15:33.525           Received Message from 121 (^[[36;1mUSB UIRT 0038 / TV Room^[[0m) to 78 (^[[36;1mOnScreen Orbiter / TV Room^[[0m), type 1 id 190 Command:^[[35;1mEnter/Go^[[0m, retry none, parameters: <0x6b5b1b70>
08      01/30/13 20:15:33.556           Received Message from 78 (^[[36;1mOnScreen Orbiter / TV Room^[[0m) to USB UIRT 0038(121), type 1 id  687 Command:^[[35;1mSet Screen Type^[[0m, retry none, parameters: <0x775c9b70>
08      01/30/13 20:15:33.556             Parameter 48(Value): 66 <0x775c9b70>
.
.
<snip populate datagrid stuff>
.
.
05      01/30/13 20:15:35.685           ^[[33;1mfile grid pics took 0 ms^[[0m <0x977efb70>
08      01/30/13 20:15:47.283           Received Message from 121 (^[[36;1mUSB UIRT 0038 / TV Room^[[0m) to 10 (^[[36;1mMedia Plug-in / Server Closet^[[0m), type 1 id 65 Command:^[[35;1mJump Position In Playlist^[[0m, retry none, parameters: <0x6b5b1b70>
08      01/30/13 20:15:47.283             Parameter 5(Value To Assign): -1 <0x6b5b1b70>
07      01/30/13 20:18:34.367           Event #75 has no handlers <0x81ddeb70>
07      01/30/13 20:18:34.367           Received Message from 18 (^[[36;1mAsterisk / Server Closet^[[0m) to -1001 (^[[36;1munknown / ^[[0m), type 2 id 75 Event:^[[32;1mExtensions Status^[[0m, retry none, parameters: <0x81ddeb70>
07      01/30/13 20:18:34.367             Parameter 13(Text): SIP/203:Registered <0x81ddeb70>

So as far as I can see- screen type is being set to 'B' and passed to USBUIRT correctly. So no idea why my next "chdown" press yields "Jump Position in Playlist" instead of scroll down as expected.

When I hit "Audio" from the media menu, a whole lot of stuff scrolls through the log (because the messages include basically everything that is populating the grid... which is a lot of album titles) but searching backwards to the "Set Screen Type" command, reveals the following

Code:

35;1mSet Screen Type^[[0m, retry none, parameters: <0x773f9b70>
08      01/22/13 21:55:19.657             Parameter 48(Value): 66 <0x773f9b70>

So, as delicately pointed out by yourself, that is screen type 'B' as per ascii code of 66.
That's from my previous post so I can't check what device it's going to - I'm not at my machine now but will try to have a squizz a bit later and maybe pastebin the whole log from the point where I choose the media list.

Jason, do you not see this if you open the log and search back to the point where you first opened the grid? you have to go back quite a bit...

Thom

Would like to help with the debugging if I can. Will help me to get a better understanding of the code and structures. Can you point me to which source code covers this section?

I still have the windows MCE remote as shown but I presume by interfaces you mean something else like the USBUIRT, of which I only have one. See screenshot. PS - presume it's ok to delete the default MCEremote?

Will check the web admin too but also think I have only one IR receiver defined.

I do have two remotes under that one - the std MCE remote that is set up when you install your usbuirt and the one I created, but as far as the receiver goes, I think only one device. Will confirm.

Thanks for the follow up Thom.

Hey, had to stop ya, because when it comes to the database, you have to be 100% correct, or stuff breaks spectacularly!
-Thom

Sure!

OK... no real progress last night except to say that after a little more log watching and reviewing the remote mapping, device tables etc, I'm convinced that for some reason the RemoteMapping for screentype 'B' is *not* being used. The keypresses I make on my remote generate messages in the DCERouter.log that correspond very accurately with the default RemoteMapping which leads me to suspect that the more specific Mapping for screentype 'B' is not being used, despite the current screen definitely being of type 'B'.

Also confirmed that the message that *should* be sent if mapping for 'B' is used would work- I used

Code:

/usr/pluto/bin/messagesend localhost 0 78 1 28 26 7

Where 78 is the onscreen orbiter in question (similar to virtual device -203) and command 28 is simulated keypress with parameter 7  mapped to "Scroll down". it works - the media grid scrolls.

And, afaict, this is what should happen when I press chdown on my remote when on screentype 'B'. But it doesn't, instead I get "jump to position in playlist" passed to the media plugin, which corresponds with what should happne if the default mapping is used.


Going to have to dig a bit further.

[type]

*Thanks Tschak for the correction delivered with all the subtlety and finesse of a Texan*

OK, sorry, that does make sense- so the message in the log

Code:

35;1mSet Screen Type^[[0m, retry none, parameters: <0x773f9b70>
08      01/22/13 21:55:19.657             Parameter 48(Value): 66 <0x773f9b70>

is noting the screen type being set as opposed to the actual screen ID. Which is what it says, of course!

Right, so the screen type at the point when I press chdown on the remote is 'B'. Remote layout is ignored, so, by Remote Mapping looking at ScreenType 'B', a chdown on the remote should fire one of these:

Code:

chdown;ChanDown;|0 -203 1 28 26 7

.
Which should be a message to the Onscreen Orbiter (-203) of type command (1) which is a simuated keypress (28) for which parameter 26 has the value 7. The button table would give 7 as "Scroll Down".

So all the setup looks good. Except that when I press the button on the remote, I get a

Code:

08      01/22/13 7:10:09.129            Received Message from 121 (USB UIRT 0038 / TV
Room) to 10 (Media Plug-in / Server Closet), type 1 id 65 Command:Jump Position In
Playlist, retry none, parameters: <0x6e69eb70>

Why, Mr Anderson, why?

I guess the first test I can do is hit the "play" button when I'm on the same grid because in the remote mapping, that is mapped to

Code:

Play;|0 -203 1 37

for screentype 'B' but is not mapped to that for any other screentype. So if the system is using that record in remotemapping, I would expect to get the associated command 37 which is "play media" send to the onscreen orbiter (device -203).

TShak has helped me shed some light on this-

When the media grid is up, I'm on screen 66. I know this from the DCERouter.log at thepoint where I hit the "Audio" from the media menu.

Code:

35;1mSet Screen Type^[[0m, retry none, parameters: <0x773f9b70>
08      01/22/13 21:55:19.657             Parameter 48(Value): 66 <0x773f9b70>

The screentype for this screen is revealed as NULL from the pluto database as follows

Code:

mysql> select ScreenType from DesignObj inner join Screen_DesignObj on DesignObj.PK_DesignObj = Screen_DesignObj.FK_DesignObj where Screen_DesignObj.FK_Screen = 66;
+------------+
| ScreenType |
+------------+
| NULL       |
+------------+
1 row in set (0.00 sec)

Therefore, I need to look at the remote mapping that matches to screentype=null and remotelayout='W'. Not quite sure why the remotelayout is 'W' but it is in the corresponding field in webadmin for my remote.

So, retrieve remotemapping as follows

Code:

mysql> select * from RemoteMapping where RemoteMapping.ScreenType is null and RemoteMapping.RemoteLayout = 'W';
Empty set (0.00 sec)

But... I seem to recall that the null/null option will be the default if you don't get a more specific match.

Code:

select * from RemoteMapping where RemoteMapping.ScreenType is null and RemoteMapping.RemoteLayout is null;

which returns 1 row with the relevant chup/chdown lines revealing

Code:

chup;ChanUp;|0 -106 1 65 5 +1
chdown;ChanDown;|0 -106 1 65 5 -1

Which corresponds nicely to what is happening as shown in the log below. The media plugin is getting the chup, chdown buttons as a "jump position in playlist" which is nice... but not what I want. The problem, to my mind, is that the context needs to be set... this is not media that's playing... this is a grid (or filelist) that's viewing. So the grid needs a screentype (not a null as I found it to be) and the screentype needs to correspond then to a remote mapping in the remote mapping table that transforms the remote buttons into something more appropriate to a grid/filelist.

David

Not sure how up to date the wiki is but a few things I've experienced with my TV-

Apart from it working as a TV - full HD, the look, size etc that you want, there are a couple of things to consider

1. Inputs - you need to think about what devices you're planning to connect and how. Ideally, IMHO, everything streams via the MD so all you need is one HDMI input direct from MD or from your AV Receiver, but it can be useful to have the others while you're getting going and/or as backup if your system is down for maintenance or whatever.
2. Control - this is probably the biggie. Even if everything comes via the MD/AV Receiver you will at least want to turn the thing on and off and possibly switch sources and you'd rather that all happened from LinuxMCE rather than you having to pick up the dedicated remote just to do that. You may also require volume and some other commands. Options are RS232, IR, Network (LAN), HDMI CEC. You need to see what the models you're looking at support and find out how easy it is to use those protocols. IR is the most common but can be a bit tricky. LAN and CEC are very new and rather proprietory and will take a fair bit of hacking. RS232 I gather is very reliable but getting rare. If you go IR, it helps if discrete codes are available for things like power (on/of) and input switching (discrete codes for each different source rather than a toggle button).

It helps to design your setup in diagrams and drawing apps with all the connections shown etc so you don't miss things and can ask questions.

I'm still very new at this but hopefully this gives you some food for thought.