From: Johnny W. <joh...@gm...> - 2009-12-03 00:45:58
|
On Tue, Dec 1, 2009 at 8:40 PM, Jarod Wilson <ja...@wi...> wrote: > On 11/30/2009 10:03 AM, Johnny Walker wrote: >> >> This weekend the LCD has been lockign up in under an hour reliably. I >> don't see anything in logs regarding it. The good news is the remote >> still works when the LCD locks up. Anything you can suggest? > > If there's nothing in the logs... Then I'm hesitant to believe its a driver > problem. At least, its not hte problem others were having -- they had > distinct send_packet failed messages in their system logs. > > On 12/01/2009 05:44 PM, Johnny Walker wrote: >>>> >>>> Feedback when using your device with a test patch I posted two or three >>>> weeks back would be useful (you should be able to find it in the list >>>> archives, needs to be applied to the lirc_imon driver). Basically, so far as >>>> we can determine, some LCD/VFD can't keep up with constant writes to the >>>> display, so we hack in a delay before returning from any writes, hoping that >>>> with delay, the display can then keep up. >> >> So now that I've corrected the LCD Server setting to localhost I can >> see in the mythfrontend.log when the lcd device stops working: >> >> 2009-12-01 15:21:17.003 lcddevice: Connection to LCDServer died >> unexpectedly. >> Trying to reconnect every 10 seconds. . . >> >> But I don't see any write errors being logged in the kern.log. >> >> It seems to restart the mythlcdserver and then keep trying... >> >> 2009-12-01 15:29:17.248 Starting mythlcdserver >> QWidget: Cannot create a QWidget when no GUI is being used >> 2009-12-01 15:29:17.757 Connecting to lcd server: 127.0.0.1:6545 (try 1 of >> 10) >> 2009-12-01 15:29:18.258 Connecting to lcd server: 127.0.0.1:6545 (try 2 of >> 10) >> 2009-12-01 15:29:18.758 Connecting to lcd server: 127.0.0.1:6545 (try 3 of >> 10) >> 2009-12-01 15:29:19.259 Connecting to lcd server: 127.0.0.1:6545 (try 4 of >> 10) >> 2009-12-01 15:29:19.760 Connecting to lcd server: 127.0.0.1:6545 (try 5 of >> 10) >> 2009-12-01 15:29:20.260 Connecting to lcd server: 127.0.0.1:6545 (try 6 of >> 10) >> 2009-12-01 15:29:20.761 Connecting to lcd server: 127.0.0.1:6545 (try 7 of >> 10) >> 2009-12-01 15:29:21.261 Connecting to lcd server: 127.0.0.1:6545 (try 8 of >> 10) >> 2009-12-01 15:29:21.762 Connecting to lcd server: 127.0.0.1:6545 (try 9 of >> 10) >> 2009-12-01 15:29:22.262 Connecting to lcd server: 127.0.0.1:6545 (try 10 >> of 10) >> 2009-12-01 15:29:27.251 Starting mythlcdserver >> 2009-12-01 15:29:27.759 Connecting to lcd server: 127.0.0.1:6545 (try 1 of >> 10) >> >> Should I take this up on the lcdproc mailing list - or is this handled >> by the lirc_imon module? > > I don't know if that's an lcdproc error or a mythlcdserver error there. But > it definitely looks to me like lirc_imon isn't at fault. > ok - so the last few days I've zeroed in on what's actually happening. The pad on the imon remote is what stops. That includes my enter key which is on that pad. This is all that's in the logs: Dec 2 17:31:33 mythliving kernel: [38109.134168] intf0 decoded packet: 01 00 00 7f 00 00 00 00 Dec 2 17:31:33 mythliving kernel: [38109.174168] intf0 decoded packet: 01 00 00 7f 00 00 00 00 Dec 2 17:31:33 mythliving kernel: [38109.206156] intf0 decoded packet: 01 00 00 7f 00 00 00 00 Dec 2 17:31:36 mythliving kernel: [38112.694506] intf0 decoded packet: 28 a1 95 b7 00 00 24 01 Dec 2 17:31:37 mythliving kernel: [38112.862519] intf0 decoded packet: 28 a1 d5 b7 00 00 24 01 Dec 2 17:40:50 mythliving kernel: [38666.122449] intf0 decoded packet: 28 a1 95 b7 00 00 24 01 Dec 2 17:40:50 mythliving kernel: [38666.290457] intf0 decoded packet: 28 a1 d5 b7 ff 00 24 01 These go on and on until they suddenly stop. The LCD is still updating this time - so it's just the pad on the remote that has stopped functioning. Actually I just tested it and it seems the entire remote has now stopped functioning. What could be the issue here? |