Incorrect handling of responses from mythlcdserver

[dburr@…]

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.

[dburr@…]

Patch for 0.21-fixes

[dburr@…]

Patch for trunk

[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.

[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.

[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.

2. 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.

[paulh]

(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.

2. 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.