[mythtv-commits] Ticket #9922: Frontend network control sends two responses after 'play program'

[MythTV]

#9922: Frontend network control sends two responses after 'play program'
----------------------------------------------+----------------------------
 Reporter:  Gregory Moyer <moyerg@…>          |           Type:  Patch -
   Status:  new                               |  Bug Fix
Milestone:  unknown                           |       Priority:  minor
  Version:  Trunk Head                        |      Component:  MythTV -
 Keywords:                                    |  General
                                              |       Severity:  medium
                                              |  Ticket locked:  0
----------------------------------------------+----------------------------
 My patch for #9725 overlooked the fact that the 'play program' command was
 relying on empty responses not being sent to the client.

 In the processPlay method in networkcontrol.cpp for a 'play program'
 command, the result string is cleared when the NETWORK_CONTROL event to
 actually trigger playback is sent. Before the patch, when this function
 returned with an empty result, no message would have been sent back to the
 client and the client would still be waiting at this point. Once the
 playback request is received, networkcontrol.cpp will see a
 NETWORK_CONTROL RESPONSE event in the function customEvent and that will
 trigger the "OK" response to the client. This is the only place I found in
 which the result is cleared while a response is expected via an event
 later.

 Now, after the fix from #9725, the empty response sends a prompt back to
 the user immediately and a short time later when the RESPONSE event is
 received, a second message of "OK" with another prompt is sent to the
 user. Therefore, in a netcat session, the user seems something like the
 attached nc-broken.log output.

 My approach to correct this involves setting the response to a null
 QString (as QString defines null using the no-arg constructor) rather than
 an empty string when no response should be sent. Instead of checking for
 an empty string, the if check that was removed in #9725 is now verifying
 that the response is not null. This allows for both scenarios where an
 empty message can be returned to the user (such as when a 'query
 recordings' command is issued and no recordings exist), but an immediate
 response can also be stopped to allow for a delayed response triggered via
 other means, such as an event in the case of a 'play program' request.

 This patch also changes the default response to 'query recordings' to a an
 empty string instead of a null string to comply with the above.

-- 
Ticket URL: <http://code.mythtv.org/trac/ticket/9922>
MythTV <http://code.mythtv.org/trac>
MythTV Media Center