LinuxMCE Forums
General => Developers => Topic started by: rwilson131 on January 06, 2008, 08:47:48 pm
-
I have been working on GSD template for LG LCD TV's. I have it working, but it appears that a couple things are happening:
Here is part of my log for LG LCD which reflects the my observations.
05 01/06/08 10:47:08.760 GSDMessageTranslator isCmdImplemented = true <0xb5ff1b90>
05 01/06/08 10:47:08.760 #### Pre-Process Queue = 1 <0xb5ff1b90>
05 01/06/08 10:47:09.176 GSDMessageTranslator isCmdImplemented = true <0xb5ff1b90>
05 01/06/08 10:47:09.176 #### Pre-Process Queue = 2 <0xb5ff1b90>
(***):Received: kf\ 01\ 11\r\nf\ 00\ OK11x\r\n
(***):kf\ 01\ 11\r\nf\ 00\ OK11x\r\n: Command Processed Successfully
01 01/06/08 10:47:25.001 Ruby was unable to handle the command in reasonable amount of time <0xb77f4b90>
05 01/06/08 10:47:25.101 GSD-Sleep Post 89 : 100 <0xb77f4b90>
05 01/06/08 10:47:25.101 _QueueProc Post - 89 : 100 <0xb77f4b90>
05 01/06/08 10:47:25.101 ---- _QueueProc Ignored - 89 <0xb77f4b90>
05 01/06/08 10:47:25.101 ---- _QueueProc Ignored - 89 <0xb77f4b90>
1. There is a built in sleep period. Based on GSD-Sleep Post 89: 100
2. Commands are queued. Based on #### Pre-Process Queue = 2
3. And if not performed in a set amount of time there are removed from que: Ruby was unable to handle the command in reasonable amount of time and ---- _QueueProc Ignored - 89.
By the way, command 89 is Volume Up
I also have a PNP script to Detect LG LCD tv's of various models, but I have been reluctant to post about it due to this inability to control TV in timely manner.
I know that all codes are correct. The last problem I have been trying to figure out is that it if I wait a few seconds between Remote Control Inputs the commands are sent immediately, but if I try to repeat commands there is a few second pause before the commands are executed. Obviously this is a challenge for LiveTV which is the last barrier for my wife to switch completely to LMCE.
I am also seeing the same types of messages from UIRT-USB logs if that makes an difference.
05 01/06/08 12:10:42.168 #### Pre-Process Queue = 4 <0xb5f67b90>
05 01/06/08 12:10:42.192 _QueueProc Pre - 205 : 0 <0xb5766b90>
05 01/06/08 12:10:42.192 GSD-Sleep Pre 205 : 0 <0xb5766b90>
05 01/06/08 12:10:42.832 GSD-Sleep Post 205 : 100 <0xb5766b90>
Which also does not respond to Remote Control Inputs in a timely manner.
Any input would be appreciated.
Thanks,
Rob
-
Interesting.. My Insteon driver has 0 in both the pre and post GSD-Sleep..
Yes, commands are queued. Your GSD code should finish with the command as soon as possible. You will then get the next command in the queue.
The only time I get the 'Ruby was unable to handle the command in reasonable amount of time' is when I have an error in the code, and the code stops. Otherwise, if the code executes successfully, the return values are set properly.
(The return values are automatically added to the code along with various values passed to ruby in the beginning of the code)
see http://wiki.linuxmce.org/index.php/Generic_Serial_Device for more info.
HTH,
Dan
-
I was able to fix the problem. It turns out I had a timeout value to high within the conn_.Recv command. Lower the timeout fixes the problem. Fires almost immediately.
I have a few loose ends to tie up and I will be posting the Ruby code and a PNP script for LG LCD TV's
Thanks ddamron for the link, it is what pointed me to the timeout value.
I have one question, I hope someone can answer. the LG returns the following string:
kf 01 f\r\ne 00 OK0fx\r\n
but when I log the string it puts in the line breaks, I was able to fix the problem by using Regexp.escape, but this returns a string which I am able to log on one line, but the format is off slightly.
kf\ 01\ f\r\nf\ 00\ OK0fx\r\n
\ in front of spaces. Obviously this is purely comestic, but I have been searching for a solution. I hate not being able to figure something out.
Thanks,
Rob
-
try using String#gsub and/or String#chomp! (or String#split for that matter...)
Glad to help...
-
I was able to fix the problem. It turns out I had a timeout value to high within the conn_.Recv command. Lower the timeout fixes the problem. Fires almost immediately.
I have a few loose ends to tie up and I will be posting the Ruby code and a PNP script for LG LCD TV's
Thanks ddamron for the link, it is what pointed me to the timeout value.
I have one question, I hope someone can answer. the LG returns the following string:
kf 01 f\r\ne 00 OK0fx\r\n
but when I log the string it puts in the line breaks, I was able to fix the problem by using Regexp.escape, but this returns a string which I am able to log on one line, but the format is off slightly.
kf\ 01\ f\r\nf\ 00\ OK0fx\r\n
\ in front of spaces. Obviously this is purely comestic, but I have been searching for a solution. I hate not being able to figure something out.
FWIW, that data looks like the '\ ', '\n' and '\r' are single metacharacters (for space/delimiter, newline and carriage-return, respectively), which are each to be processed as a single character, even though they're transmitted as double characters (including the leading '\' character that escapes them to distinguish them from the simple printed character in the alphabet). Just in case you didn't realize that, and if it matters in that context.