USBUIRT not transmitting in 10.04 [solved]

[jamo]

Yes, that seems to be it - as soon as I start to use the media director in a normal way - ie play music or whatever, thereafter the transmitter stops working. In fact, it fires something just when I start doing that so presumably it is something to do with my connections - what controls what and / or pipes?

[tschak909]

Pipes are interpreted by the Media Plugin. You should look in the Wizard > A/V Equipment page, to make sure your pipes are configured correctly, (either with the Connection wizard, or manually by clicking Edit Pipes)... Check the DCE Router log, when you send soemthing from your remote, to see if your pipes are being traversed.

-Thom

[jamo]

Thanks, I think one mistake I may have made was to connect the output from my media director directly to the TV HDMI input, instead of connecting it to the "subdevice" HDMI input which, in turn, connects to the TV. I think I've corrected that, although I've made a massive spaghetti mess of the wizard version. Does anyone else struggle to move the devices around on that screen? Pity, because it's a pretty cool wizard.

Anyway, will see if this improves things and scan the logs as well as Thom suggested.  Pain is every time I reload it stops working so each change that requires this essentially requires a reboot as well. Starting to feel like windows. 

[jamo]

Nope, that hasn't improved things.

I have established the following-

The first time I start the media director, absolutely before I do anything with it, the UIRT appears to be transmitting - in other words, if I click the "Test Code" button from the web admin / av DEVICES / AV properties IR codes section of my TV (controlled by UIRT) then I see a "flash" on the transmitter.

That works up until the moment I "play media" on the MD. So I can open a media grid (ie go to media->Audio), browse to a track. Up to that point, UIRT still transmits when I "test code". Then, as soon as I hit play and the media starts playing, the transmitter stops transmitting and won't do it again until (I think) the MD is rebooted. Note that I'm doing all this (controlling the MD) from a weborbiter rather than the IR remote in order not to confuse things by using the UIRT as a receiver.

So I have "clipped" the DCErouter log and the UIRT log from the appropriate MD and shown the entries from the moment I start playing the media. In other words, from the moment the UIRT stops working. Here they are:

dcerouter
usbuirt

So... the usbuirt is the simplest - apart from a bunch of "Cannot find anything for IR 170000F201CA" which is usually associated with IR signals received from an unknown remote/source, the only entry that could be of interest is "#### Pre-Process Queue = 1"
Does that mean anything to anyone?

And then on the dcerouter side, apart from all the subsequent messages showing what music I was listening to, possibly of interest -
"Received Message from 50 (HTC Web Orbiter / ) to 10 (Media Plug-in / Server Closet), type 1 id 43 Command:MH Play Media, retry none, parameters: <0x7bfb4b70>" <- the play media command to the plugin?

Then later " Received Message from 78 (OnScreen Orbiter / TV Room) to USB UIRT 0038(139), type 1 id  687 Command:Set Screen Type, retry none, parameters: <0x777abb70>
08      02/07/13 6:26:22.292              Parameter 48(Value): 0 <0x777abb70>" <- set screen type to USB UIRT?

Then later "Media_Plugin::CheckForAlternatePipes no destination for EA 3 TV Room <0x917dfb70>" <- ??

Shew.... not much to go on at this stage.

[tschak909]

No, if you look at the parameter value, Set Screen Type is set to 0, which is the default screen type. This is defined by the first entry in the RemoteMapping table. The command is sent from the on-screen orbiter to the USB UIRT, so that the driver knows which RemoteMapping to use.

-Thom

[jamo]

No, if you look at the parameter value, Set Screen Type is set to 0, which is the default screen type. This is defined by the first entry in the RemoteMapping table. The command is sent from the on-screen orbiter to the USB UIRT, so that the driver knows which RemoteMapping to use.

-Thom

Yes, but isn't RemoteMapping only relevant for IR receiving? What I'm trying to track down here is why the UIRT isn't transmitting. Am I missing something?

[tschak909]

correct, I am merely trying to answer specific questions.

-Thom

[jamo]

Oh, I see, sorry. Got it.

[jamo]

OK, I sorted out the TV template and the connections pipes and I'm pretty sure everything is going correctly.

MD ====> Audio+Video ====> TV HDMI1 input
STB =====> Audio + Video ====> TV AV1 input

I confirmed that when I start up the media director, as soon as there is action, it transmits a "Toggle power" to the TV because it actually turns the TV on. But as soon as that has happened, there appears to be no more transmitting done. I would think that while using the MD, volume commands would be relayed to the TV but nothing is transmitted.
Then, if I hit the "STB" scenario, I would expect the USBUIRT to try to toggle the input selection on the TV to AV1 but nothing happens.
If I "Test" the TV av commands from the webadmin page, nothing happens.

Going to have to have an in-depth and close watch on the logs while this is all happening to see what the problem is. I gather the MediaPlugin is responsible for handing on IR commands so I maybe have to look at that code a bit and/or its log. Does it have a log?

[phenigma]

jamo it *should* be working as you expect.

J.

[jamo]

Ok, so here's what happens when I hit the "test code" from webadmin while my USBUIRT is in its "non transmitting" state:

DCERoute.log:

Code: [Select]

08      02/14/13 21:44:49.070           Received Message from 0 (unknown / ) to 157 (USB UIRT Embedded Transmit / TV Room), type 1 id 191 Command:Send Code, retry none, parameters: <0x6a09eb70>
08      02/14/13 21:44:49.070             Parameter 9(Text): 0000 0073 0000 000C 0020 0021 0020 0021 0040 0021 0020 0021 0020 0021 0020 0021 0020 0021 0020 0041 0040 0021 0020 0021 0020 0021 0020 0CC7 <0x6a09eb70>
05      02/14/13 21:44:49.120           Socket::ReceiveData 0xaeff6f08 failed, bytes left 0 start: 2320000 1: 0 1b: 0 2: 0 2b: 0 m_Socket: 175 Incoming_Conn Socket 175 ::ffff:127.0.0.1 <0x6a09eb70>
05      02/14/13 21:44:49.120           Socket::ReceiveString2 ReceiveData failed m_Socket: -1 Incoming_Conn Socket 175 ::ffff:127.0.0.1 <0x6a09eb70>
05      02/14/13 21:44:49.121           TCPIP: Closing connection to -1003 (Router Dev #0) 0xaeff6f08 m_Socket: -1 <0x6a09eb70>
05      02/14/13 21:44:49.121           Router::RemoveAndDeleteSocket 0xaeff6f08 -1003 <0x6a09eb70>


Help? Socket::ReceiveData failed. Why?

[jamo]

More info... OK, I don't think the Socket::ReceiveData failed is actually the problem because with further testing I see that successfully sent codes (the ones I can send prior to using the MD) show the same thing in the log but the code is sent, the UIRT flashes and the TV responds. So I *think* that's a red herring.

However, I had a closer look at the DCERouter log between the time I can send and the time I can't send and it seems that as soon as all the "on commands" are sent to the xxxxxx, the UIRT stops working immediately after:

Code: [Select]

05      02/16/13 0:08:02.902            Socket::ReceiveString2 ReceiveData failed m_Socket: -1 Incoming_Conn Socket 175 ::ffff:192.168.80.1 <0x69fdeb70>
05      02/16/13 0:08:02.902            TCPIP: Closing connection to -1003 (Router Dev #0) 0x9fab0028 m_Socket: -1 <0x69fdeb70>
05      02/16/13 0:08:02.902            Router::RemoveAndDeleteSocket 0x9fab0028 -1003 <0x69fdeb70>
08      02/16/13 0:08:14.431            Received Message from 156 (USB UIRT 0038 / TV Room) to 78 (OnScreen Orbiter / TV Room), type 1 id 203 Command:Move Right, retry none, parameters: <0x737f1b70>
08      02/16/13 0:08:14.434            Received Message from 78 (OnScreen Orbiter / TV Room) to 78 (OnScreen Orbiter / TV Room), type 1 id 192 Command:On, retry none, parameters: <0x79ffeb70>
08      02/16/13 0:08:14.434              Parameter 21(Force): 1 <0x79ffeb70>
08      02/16/13 0:08:14.434              Parameter 97(PK_Pipe): 0 <0x79ffeb70>
08      02/16/13 0:08:14.434              Parameter 98(PK_Device_Pipes):  <0x79ffeb70>
08      02/16/13 0:08:14.434            Received Message from 78 (OnScreen Orbiter / TV Room) to 76 (Zotac AD04 TV Room / TV Room), type 1 id 192 Command:On, retry none, parameters: <0xacdf9b70>
08      02/16/13 0:08:14.434              Parameter 21(Force): 1 <0xacdf9b70>
08      02/16/13 0:08:14.434              Parameter 97(PK_Pipe): 0 <0xacdf9b70>
08      02/16/13 0:08:14.434              Parameter 98(PK_Device_Pipes):  <0xacdf9b70>
08      02/16/13 0:08:14.434              Parameter 125(Already processed): 1 <0xacdf9b70>
08      02/16/13 0:08:14.434            Received Message from 78 (OnScreen Orbiter / TV Room) to 170 (40V86PE / TV Room), type 1 id 192 Command:On, retry none, parameters: <0xb77a8b70>
08      02/16/13 0:08:14.434              Parameter 98(PK_Device_Pipes):  <0xb77a8b70>
08      02/16/13 0:08:14.434            Received Message from 78 (OnScreen Orbiter / TV Room) to 170 (40V86PE / TV Room), type 1 id 91 Command:Input Select, retry none, parameters: <0xb77a8b70>
08      02/16/13 0:08:14.434              Parameter 71(PK_Command_Input(HDMI)): 361 <0xb77a8b70>

The log section above shows what happens as soon as I try to do something on the MD. Note that immediately prior to this, the UIRT was sending.
The first entry is the "move right" command, as received from my remote. This triggers an "On" command to the onscreen orbiter followed by an "On" command to the Media Director, followed by an "On" command to the TV and then an "Input select: HDMI" command to the TV.

That all makes sense.... (apart from the fact that the MD is already on and so is the TV).

But why, following this sequence, should the UIRT stop transmitting?

[phenigma]

But why, following this sequence, should the UIRT stop transmitting?

This all looks normal to me.  I see nothing that points to the problem here.  I'm not sure where to go from here.

Does the UIRT continue to receive from the remote when it stops transmitting?  Ie. does dcerouter get commands from the uirt/mce remote still?

J.

[jamo]

Cautiously optimistic....

Not going to mark it solved just yet but I'm holding thumbs here...

So looking at the log section below I figured that the transmission problem must be related to one of the 3 "on" commands that were sent prior to transmission failing. I tried manually sending the first (Onscreen orbiter) but that automatically fires the second and third so that doesn't help isolate the problem. I then tried just the 3rd (On to the TV) and that did cause the transmission to fail. So I began to suspect the TV device/template.

So I deleted the USBUIRT device from my tree (and hence the TV beneath it) and then re-added the USBUIRT.

Now, before adding the TV, I was able to test transmission using the webadmin and/or MessageSend commands directly. These worked, no matter what "state" the media director was in. So I figured the TV template was the problem. I created a new one, added it and, SO FAR SO GOOD! Transmission and Receiving seems to be working. Not only that but I think my receiving problem (after dcerouter reload) seems also to be resolved, yay!

Will wait a while and do a few more checks and tests, as well as deleting the old template (no mean achievemnt) before marking resolved.

Now if the TV would just respond to the IR commands... it seems pretty unreliable.

[phenigma]

Excellent!  I don't suppose you have an example of the IR code that was causing your uirt to fail and the new one that is not?  (To try and trace this back further).

You may wish to get an emmiter for the uirt that will sit immediately in front of your televisions ir receiver window.  Improves reliability.

J.