Ticket #180 (closed defect: worksforme)

Opened 5 months ago

Last modified 5 months ago

Possible failed USB IR device

Reported by: citabjockey Owned by: bluey
Priority: highest Component: Fedora
Version: Severity: normal
Keywords: Cc: mythtv@…

Description

The device was working for the past two weeks. Then it stopped. When I attempt to run igdaemon by hand I get the following:

root@clawhammer Iguana]# igdaemon -n -v -v -v Mar 03 08:43:58 2010 DEBUG: Parameters: Mar 03 08:43:58 2010 DEBUG: recvTimeout: 1000 Mar 03 08:43:58 2010 DEBUG: sendTimeout: 1000 Mar 03 08:43:58 2010 INFO: Loaded driver: /usr/lib/iguanaIR/libusbpre1.so Mar 03 08:43:58 2010 INFO: Worker 0 starting Mar 03 08:43:58 2010 DEBUG2: o0x0000cd01 Mar 03 08:43:58 2010 DEBUG: Handling 1 device(s): Mar 03 08:43:58 2010 DEBUG: 0) usb:3.6 id=0 addr=0x9745b70 Mar 03 08:43:58 2010 DEBUG2: i0x0000dc010603 Mar 03 08:43:58 2010 DEBUG: Received ctl header: 0x1 Mar 03 08:43:58 2010 INFO: Transaction: 0x1 (16468 microseconds) Mar 03 08:43:58 2010 INFO: Found device version 0x306 Mar 03 08:43:58 2010 DEBUG2: o0x0000cd1f Mar 03 08:43:59 2010 INFO: Timeout while waiting for response from device. Mar 03 08:43:59 2010 INFO: Failed to get id. Device may not have one assigned. Mar 03 08:44:02 2010 INFO: Device 0 unplugged Mar 03 08:44:02 2010 INFO: Worker 0 exiting

Can you please clarify why it claims Device 0 is unplugged?

Change History

Changed 5 months ago by jdunn

Could you please try running igdaemon -nvvv --no-ids and see if that changes the behavior? If it does then in a different console run igclient --set-id '' and restart the daemon without the --no-ids option. I doubt this is the problem, but it's worth checking before bouncing this hardware through the mail.

If this does not fix it please email me directly (jdunn) and we'll coordinate the return.

Changed 5 months ago by citabjockey

This corrected the issue, THANKS! Any idea why this was necessary? Should I put these steps into my init.d startup somehow?

Thanks

Rob

Changed 5 months ago by bluey

  • status changed from new to closed
  • resolution set to fixed
  • component changed from Hardware to Debian/Ubuntu

I have no idea why it would have changed -- but somehow the part of the code that sets the device name got corrupted. Maybe from a --set-id command that went bad? Maybe some cosmic rays? I don't know. But what we did was run the daemon without asking the device what its name was (avoiding the corrupted code) and then reset that code. You shouldn't have to run this again (or in the first place for that matter).

I'm going to close the ticket -- please reopen if it happens again and we'll try to figure out what is corrupting the code.

Changed 5 months ago by citabjockey

  • cc mythtv@… added
  • priority changed from normal to highest
  • status changed from closed to reopened
  • component changed from Debian/Ubuntu to Fedora
  • resolution fixed deleted

Seems to be failing again - but in a different mode. I sent you an email as well. Here is the content:

I got the ID reset but soon after that whenever it did the igdaemon -nvvv

I get the following (and lircd cannot make heads or tails of the data). This
is which no IR source pointing at the device (I even wrapped it up in aluminum
foil). I cannot get it to work. Does this trace look suspicious?

thanks

rob

Mar 04 15:46:30 2010 DEBUG: Parameters:
Mar 04 15:46:30 2010 DEBUG: recvTimeout: 1000
Mar 04 15:46:30 2010 DEBUG: sendTimeout: 1000
Mar 04 15:46:30 2010 INFO: Loaded driver: /usr/lib/iguanaIR/libusbpre1.so
Mar 04 15:46:30 2010 INFO: Worker 0 starting
Mar 04 15:46:30 2010 DEBUG2: o0x0000cd01
Mar 04 15:46:30 2010 DEBUG: Handling 1 device(s):
Mar 04 15:46:30 2010 DEBUG: 0) usb:3.31 id=0 addr=0x9db0b68
Mar 04 15:46:30 2010 DEBUG2: i0x0000dc010603
Mar 04 15:46:30 2010 DEBUG: Received ctl header: 0x1
Mar 04 15:46:30 2010 INFO: Transaction: 0x1 (12503 microseconds)
Mar 04 15:46:30 2010 INFO: Found device version 0x306
Mar 04 15:46:30 2010 DEBUG2: o0x0000cd1f
Mar 04 15:46:30 2010 DEBUG2: i0x0000dc204d595448
Mar 04 15:46:30 2010 DEBUG: Received ctl header: 0x20
Mar 04 15:46:30 2010 DEBUG2: i0x0000000000000000
Mar 04 15:46:30 2010 INFO: Transaction: 0x20 (19974 microseconds)
Mar 04 15:46:31 2010 INFO: Found client using protocol version 1
Mar 04 15:46:31 2010 INFO: Request handled within daemon: 0xfe
Mar 04 15:46:31 2010 INFO: Found client using protocol version 1
Mar 04 15:46:31 2010 INFO: Request handled within daemon: 0xfe
Mar 04 15:46:31 2010 DEBUG2: o0x0000cd12
Mar 04 15:46:31 2010 DEBUG2: i0x0000dc12
Mar 04 15:46:31 2010 DEBUG: Received ctl header: 0x12
Mar 04 15:46:31 2010 INFO: Transaction: 0x12 (14584 microseconds)
Mar 04 15:46:31 2010 DEBUG2: i0x8080808080808000
Mar 04 15:46:31 2010 DEBUG2: Data without ctl header assuming IG_DEV_RECV.
Mar 04 15:46:31 2010 DEBUG2: Returning data packet (0x30, 7 byte payload)
Mar 04 15:46:31 2010 DEBUG2: i0x8080808080808000
Mar 04 15:46:31 2010 DEBUG2: Data without ctl header assuming IG_DEV_RECV.
Mar 04 15:46:31 2010 DEBUG2: Returning data packet (0x30, 7 byte payload)
Mar 04 15:46:31 2010 DEBUG2: i0x8080808080808000
Mar 04 15:46:31 2010 DEBUG2: Data without ctl header assuming IG_DEV_RECV.
Mar 04 15:46:31 2010 DEBUG2: Returning data packet (0x30, 7 byte payload)
Mar 04 15:46:31 2010 DEBUG2: i0x8080808080808000
Mar 04 15:46:31 2010 DEBUG2: Data without ctl header assuming IG_DEV_RECV.
Mar 04 15:46:31 2010 DEBUG2: Returning data packet (0x30, 7 byte payload)
Mar 04 15:46:31 2010 DEBUG2: i0x8080808080808000
Mar 04 15:46:31 2010 DEBUG2: Data without ctl header assuming IG_DEV_RECV.
Mar 04 15:46:31 2010 DEBUG2: Returning data packet (0x30, 7 byte payload)
Mar 04 15:46:32 2010 DEBUG2: i0x8080808080808000
Mar 04 15:46:32 2010 DEBUG2: Data without ctl header assuming IG_DEV_RECV.
Mar 04 15:46:32 2010 DEBUG2: Returning data packet (0x30, 7 byte payload)
Mar 04 15:46:32 2010 DEBUG2: i0x8080808080808000
Mar 04 15:46:32 2010 DEBUG2: Data without ctl header assuming IG_DEV_RECV.
Mar 04 15:46:32 2010 DEBUG2: Returning data packet (0x30, 7 byte payload)
Mar 04 15:46:32 2010 DEBUG2: i0x8080808080808000
Mar 04 15:46:32 2010 DEBUG2: Data without ctl header assuming IG_DEV_RECV.
Mar 04 15:46:32 2010 DEBUG2: Returning data packet (0x30, 7 byte payload)
Mar 04 15:46:32 2010 DEBUG2: i0x8080808080808000
Mar 04 15:46:32 2010 DEBUG2: Data without ctl header assuming IG_DEV_RECV.
Mar 04 15:46:32 2010 DEBUG2: Returning data packet (0x30, 7 byte payload)
Mar 04 15:46:32 2010 DEBUG2: i0x8080808080808000
Mar 04 15:46:32 2010 DEBUG2: Data without ctl header assuming IG_DEV_RECV.
Mar 04 15:46:32 2010 DEBUG2: Returning data packet (0x30, 7 byte payload)
Mar 04 15:46:32 2010 DEBUG2: i0x8080808080808000
Mar 04 15:46:32 2010 DEBUG2: Data without ctl header assuming IG_DEV_RECV.
Mar 04 15:46:32 2010 INFO: Device 0 released
Mar 04 15:46:32 2010 DEBUG2: Returning data packet (0x30, 7 byte payload)
Mar 04 15:46:32 2010 INFO: Worker 0 exiting
Mar 04 15:46:32 2010 DEBUG: Reaped child: 0xb759db90

Changed 5 months ago by jdunn

I replied to your email about this, but I'll copy the response here for others to see. Stick to replying to the ticket so that both ben and I can keep an eye on it.

That trace looks just like it should. It is notifying you that it is seeing continuous "spaces" i.e. no signals. If you press a button on a remote pointed at the receiver do the lines of i0x8080808080808000 change?

Also, if you run igclient --receiver-on --sleep 10 while the device is plugged in it should tell you what signals it is seeing and sending to LIRC.

I believe you're basically at Step 2 off this page: GettingStarted

Changed 5 months ago by citabjockey

  • status changed from reopened to closed
  • resolution set to worksforme

the igclient returns good data. found stray IR radiation from a remote extender. Shut that down and codes from lirc using iguana are now corect again. Thanks!

I am closing the ticket.

Note: See TracTickets for help on using tickets.