multiple mplayer commands through lircrc failure

[elbeardmorez@…]

hi. my build of mplayer was 23Jan2012 r34588. with the following simple example taken from ​http://www.mplayerhq.hu/DOCS/HTML/en/control.html

begin mplayer

begin

button = full_screen
prog = mplayer
config = seek 0 1\npause
repeat = 0

end

end mplayer

hitting my remote control button gives:

mplayer: bad return packet
Error while reading command file descriptor 3: Success

..and the commands fail to take effect. i tried several quotation types for the special \n delimiter but none helped.

digging around and stepping through the appropriate lirc code, from mplayer's input/lirc.c call to 'lirc_code2char' i see that the use of the \n delimiter interferes with lirc's mechanism for verifying return packets from the lircd socket. the remote's code is correctly matched to the corresponding .lircrc config entry, and the multiple mplayer commands are returned in the lircd socket, however, a packet is only deemed successfully read if an END entry (line) directly proceeds the first (of the split) mplayer command. it very much looks like it's always been this way, with the relevant code not changing for many many (pre 2006?) years.

so the fix is either that LIRC either:
-writes to its socket (file) differently
-or it parse the config entry and substitute \n 'chars' for something else before writing to the socket (lircd) and then reverses this in the client

or mplayer
-doesn't use \n directly in .lircrc. \n is still ultimately used by mplayer to delimit multiple commands, and where these multiple commands eminate from REPEATED lirc remote code translations there's no problem, but these 'multiple commands per single config' certainly need different treatment

this trivial patch swaps \n for \t as the required .lircrc config entry for mplayer, reversing this substitution when safely back in mplayer space. minimal international DOC changes are made, English DOC file modification beyond the '\n'->'\t' changes were made in order to try and further distinguish the concepts of multiple commands per config entry, and multiple commands due to multiple config entries, something that appears to be confused in many forum posts

#debug session
[mplayer/input/lirc.c]mp_input_lirc_read->[lirc/tools/lirc_client.c]lirc_code2char->lirc_send_command

here, after the command is written to the server's socket, the DATA portion of the packet written to the socket in reponse is ALWAYS going to be longer than the (hardcoded in lircd) P_DATA_N = 1. hence following the first (only) P_DATA_N switch case, 'state' is prematurely set to P_END, and then this case is hit with the next \n delimited command instead of the 'required' END string which then results a 'bad return packet' error.

cheers,
Pete

[elbeardmorez@…]

trivial patch to swap \n to an alternative delimiter