Ok, this sends the strings - complete with delay but the player software still continues to skip ahead like the button is held down !


Code is here (ps I am updating this code as I go, sorry for any confusion)
http://www.jonshouse.co.uk/broadcastfb_proc.c

Code output
Got 10 bytes from receiving UDP socket [0x0020DF11]
sent BUTTONRAW=0x0020DF11, got 20
sent BUTTONRAW=0x0020DF11.R, got 22

Player seems to ignore the .R ? I have inserted a 250ms delay in between the 20DF11 and the 20DF11.R line.


Understood, but in this application a non empeg is decoding the infra-red and sending it to the empeg for decode.




Sorry, this is me adding confusion - the name /proc/empeg_ir was from an older experiment and was still in the printf - my code has always been talking to /proc/empeg_notify.


My code now does :
A write - sent BUTTONRAW=0x0020DF11, got 20
A delay - usleep(250000);
Appends ".R" to the string - strcat(st,".R");
A second write - sent BUTTONRAW=0x0020DF11.R, got 22

Player skips ahead forever ? Note the second write got the string length back from the write (22) so I have no idea what I am doing wrong !

Tried writing a bit of shell script to run on the player, I cant generate a 250ms dielay with ease so I used "echo Hello >/dev/null" 30 times. I cut&pasted your script example but that does exactly the same as my C code - it seems to ignore the.R and acts as if the button is held down.

I've made it work - but with a hack. I write 0xFFFFFFFF to cancel the key, that sems to work ! Odd !

Got 10 bytes from receiving UDP socket [0x0020DF11]
sent BUTTONRAW=0x0020DF11, result 20
sent BUTTONRAW=0xFFFFFFFF, result 20


Sorry for the effort involved, I am not going to mad but this box just does not seem to act as described - it ignores the .R ? Tried .R in lower and upper case, same result

Thanks for the help :-) , if you have any ideas why I need the hack then let me know and and I will clean up my code.

Good news is it seems to proxy IR now - pretty cool.

Jon