Opened 12 years ago

Closed 12 years ago

#5421 closed defect (fixed)

Incorrect handling of responses from mythlcdserver

Reported by: dburr@… Owned by: Isaac Richards
Priority: minor Milestone: unknown
Component: mythtv Version: 0.21-fixes
Severity: low Keywords:
Cc: Ticket locked: no

Description

As reported in the mailing list post at http://www.gossamer-threads.com/lists/mythtv/users/333605 some users are seeing "lcddevice: received bad no. of arguments in CONNECTED response from LCDServer" in their logs. The reason for this is that libs/libmyth/lcddevice.cpp allows commands to be sent before it processes the response to the HELLO message. For example, assume that the following sequence of events was to take place:

  1. LCD::connectToHost() sends HELLO
  2. LCD::switchToTime() gets called and SWITCH_TO_TIME is sent
  3. readyReadThread_iffound() realises that data is available and calls LCD::readyRead()

The response string from the socket would then be read as something like "CONNECTED 16 2\r\nOK\r\n". This will be split into an QStringList with 4 elements "CONNECTED", "16", "2", "OK" which causes the warning to be output to the log file.

This can be fixed in 2 ways:

  1. Don't send any commands until after the response to HELLO has been received and processed.
  2. Make LCD::readyRead() more robust and able to process multiple response messages.

The attached patches fix the problem in both ways for 0.21-fixes and trunk. Note that this only fixes half of the problem described in the mailing list post. The other half of the problem is that LCD server communication does not start appear to start when Myth starts. Up until some time in the last few months I used to see a progress bar on the LCD when "Prescaling theme images" was done at startup. Now I see the LCDproc display until I start navigating the Myth menus.

Attachments (2)

myth-lcdfix-0.21-fixes.patch (3.7 KB) - added by dburr@… 12 years ago.
Patch for 0.21-fixes
myth-lcdfix-trunk.patch (3.7 KB) - added by dburr@… 12 years ago.
Patch for trunk

Download all attachments as: .zip

Change History (6)

Changed 12 years ago by dburr@…

Patch for 0.21-fixes

Changed 12 years ago by dburr@…

Attachment: myth-lcdfix-trunk.patch added

Patch for trunk

comment:1 Changed 12 years ago by dburr@…

On further reflection it would seem that the second error that I refer to would be the reason that the first was not seen until now. If the socket is not being opened until much later than it used to be then the HELLO message will be sent through very close to the actual commands, causing the CONNECT response to be mixed with the OK messages. The old behaviour must have opened the socket earlier, allowing time for the CONNECT response to be process before the OK messages begun to be received.

comment:2 Changed 12 years ago by anonymous

Further investigation has shown that mythfrontend *is* communicating with mythlcdserver at startup but it disconnects quickly (~1 second). When navigating through the menus the connection is re-established and the second connection does not drop out.

comment:3 Changed 12 years ago by paulh

(In [18245]) Fix a couple of problems with the LCD.

  1. Don't send any commands to mythlcdserver until we have a response to 'HELLO'. Refs #5421.
  1. Work around a problem with the LCD not always starting up properly. Refs #5648. Probably also fixes #5613.

The problem seems to be that if the readyread_thread is monitoring only one socket (the BE isn't running) then it can get into a state where it never wakes up to process a read. If another socket is added (the BE is started) or if it is forced to wake up then it starts to behave properly.

The hack is to Lock() and Unlock() the socket after the first write which is enough to get the readyready_thread working properly.

comment:4 Changed 12 years ago by paulh

Resolution: fixed
Status: newclosed

(In [18246]) Merge [18245] from trunk.

Fix a couple of problems with the LCD.

  1. Don't send any commands to mythlcdserver until we have a response to 'HELLO'. Fixes #5421.
  1. Work around a problem with the LCD not always starting up properly. Fixes #5648. Probably also fixes #5613.

The problem seems to be that if the readyread_thread is monitoring only one socket (the BE isn't running) then it can get into a state where it never wakes up to process a read. If another socket is added (the BE is started) or if it is forced to wake up then it starts to behave properly.

The hack is to Lock() and Unlock() the socket after the first write which is enough to get the readyready_thread working properly.

Note: See TracTickets for help on using tickets.