[ir] Web-based Remote Control

Black Hole said:
Why not simply not pass the code on?
Click to expand...
The code is interposing on a function which returns a value. If you don't return something, then the system gets in a mess and stops responding to IR input entirely.

Try the version I just uploaded to the beta repository (1.18) - that should fix your problem with foreign code mapping being overridden, and it adds a new option to block repeated codes.
 
af123 said:
Try the version I just uploaded to the beta repository (1.18) - that should fix your problem with foreign code mapping being overridden, and it adds a new option to block repeated codes.
Click to expand...
Perfek!

In fact, I don't expect to use foreign mapping with blocked native mapping "in production", I just came across the bug during play. However, I will definitely use the repeat code blocking. Thanks.

I see no need to keep this at beta status.
 
As a slight aside, I have two boxes in the same room, one in Mode 1 and one in Mode 2.
Both have the Swap Info/List setting enabled.
Pressing the real List button to bring up the Info on either remote control activates Info on both machines.
This is quite a nuisance. Any ideas of cause/cure?
 
af123 said:
If you don't return something, then the system gets in a mess and stops responding to IR input entirely.
Click to expand...
I've had this happen several times. Don't know the cause, but probably nothing to do with IR control, more some sort of crash. The only way out is to power cycle the box, which is inconvenient if it's recording (and usually the recording is fine if left to finish, so not a complete crash).
 
prpr said:
As a slight aside, I have two boxes in the same room, one in Mode 1 and one in Mode 2.
Both have the Swap Info/List setting enabled.
Pressing the real List button to bring up the Info on either remote control activates Info on both machines.
This is quite a nuisance. Any ideas of cause/cure?
Click to expand...
Ah yes, I can see how that would happen.

Beta 1.19 is there.
(It involved quite a restructure but should resolve this particular problem)

It will need some regression testing before moving to the main repository.
(@Black Hole , since you're testing, could you exercise the options a bit too?)

I appreciate the reboots are a bit of a pain.. it never seemed necessary to put the time into making it update dynamically.
 
af123 said:
Black Hole , since you're testing, could you exercise the options a bit too?
Click to expand...
Will do, but today I'll be focused on optimising the target system.

af123 said:
The lookup table is just 256 bytes
Click to expand...
Does this impose an absolute limit on how much detail can be in ir3.map? Foreign codes occupy a lot of space, for example.

af123 said:
I appreciate the reboots are a bit of a pain.. it never seemed necessary to put the time into making it update dynamically.
Click to expand...
Don't worry about it. Once done, it's done.

By the way: it is now apparent how IR clutter can cause crashes - everything gets processed (occupying processor time), whether valid or not.
 
af123 said:
The code has this field as 0 = 'button down' and 1 = 'button up'
Click to expand...
Black Hole said:
No, sorry - hold a button down for a long time and you get a stream of reports with one initial "0" followed by loads of "1"s.
Click to expand...
It has just occurred to me that this behaviour might be dependent on the handset version. I have ADB 1.0 (and it's a good job I went into the battery compartment, because I found leaky Duracells marked 2023!). Anybody got the "other" version handset to test?
 
Black Hole said:
I have ADB 1.0 . . . Anybody got the "other" version handset to test?
Click to expand...
If the 'other' one is an MDB 1.3, then yes I've got 3 of them

The '1' does appear to indicate a repeated (held down) button :-
Code: 
Real IR code: 00000000 0xf30c1000 (c) [foreign=0]
Real IR code: 0x000001 0xf30c1000 (c) [foreign=0]
Real IR code: 0x000001 0xf30c1000 (c) [foreign=0]
Real IR code: 0x000001 0xf30c1000 (c) [foreign=0]
Real IR code: 0x000001 0xf30c1000 (c) [foreign=0]
Real IR code: 0x000001 0xf30c1000 (c) [foreign=0]
Real IR code: 0x000001 0xf30c1000 (c) [foreign=0]
Real IR code: 0x000001 0xf30c1000 (c) [foreign=0]
Real IR code: 0x000001 0xf30c1000 (c) [foreign=0]
Real IR code: 0x000001 0xf30c1000 (c) [foreign=0]
Real IR code: 0x000001 0xf30c1000 (c) [foreign=0]
Real IR code: 0x000001 0xf30c1000 (c) [foreign=0]
Real IR code: 0x000001 0xf30c1000 (c) [foreign=0]
Real IR code: 0x000001 0xf30c1000 (c) [foreign=0]

It is possible to get a single '0' entry in the log if you are quick or a more normal '0' + '1' double enrty if you are are bit slower with the release

BTW
You may find using this 'live' monitor better than examining historic files:-
Code: 
Humax1# tail -f /var/log/humaxtv.log
 
Last edited:
Black Hole said:
Packages have been updated, the box has been rebooted umpteen times, the mode has been checked (Mode 1)... but the litmus test of pressing "List" still produces a list (when the map file says to disable that button).

The only other thing I can think of (and I can't sort out right now) is CF3.11. Could that be the problem?
Click to expand...
Here's the problem:
Code: 
Initialising IR3 v1.19
IR3 debug: 1
IR3 Mode: 1 (0x1000)
IR3 Options: 0x18
IR3 - Loading custom keymap.
Map file '/var/lib/humaxtv/mod/ir3.map' too large.
Do comments count towards the "too large"?
 
Last edited:
Okay, so I've stripped out anything irrelevant (including comments), and now it loads.

In theory, as configured, pressing "6" is intended to produce "9 OK". What actually happens is "9 4". But "5" is intended to produce "5 OK" and that works fine.

Here's the relevant ir3.map line (comments re-added):
Code: 
08:0b,13:SIX -> BBC FOUR (9)
...and the relevant section of humaxtv.log:
Code: 
MACRO
Real IR code: 0x00000000 0xf40b1000 (8) [foreign=0]     ---- (8)?  Should read (b) for that code, but 8 was the input.
MACRO
macro thread starting.
Real IR code: 0x00000001 0xf40b1000 (8) [foreign=0]
Macro inject: 6
Injecting 06

InjectCommand: Got mutex
get_inbuf: Popped existing.
get_inbuf: Popped existing.
InjectCommand: Buffers 0 0100acf8 1 0100ad04
InjectCommand: Input list 0
InjectCommand: setting signal (0x100ab88)
GetQueueSize: 1
GetEvents(): faking key 06 (2)
Real IR code: 0x00000000 0xf9061000 (6) [foreign=0]
GetQueueSize: 1
GetEvents(): faking key 06 (1)
Real IR code: 0x00000001 0xf9061000 (6) [foreign=0]
Macro inject: 13
Injecting 13

InjectCommand: Got mutex
get_inbuf: Popped existing.
get_inbuf: Popped existing.
InjectCommand: Buffers 0 0100ad10 1 0100ad1c
InjectCommand: Input list 0
InjectCommand: setting signal (0x100ab88)
GetQueueSize: 1
GetEvents(): faking key 13 (2)
Real IR code: 0x00000000 0xec131000 (13) [foreign=0]
GetQueueSize: 1
GetEvents(): faking key 13 (1)
Real IR code: 0x00000001 0xec131000 (13) [foreign=0]
macro thread exiting.

This doesn't work either:
Code: 
0b:04,06,13:NINE -> ITV4 (24)
...it just does "2 OK". I get the feeling the codes in macro definitions are then getting expanded by other definitions.

Holding a button down which has a macro assigned crashes the box (multiple key presses are set to be suppressed).
 
Last edited:
It looks like I have a few more things to fix then. Since I've dusted the code off already, I'll have a look.
I can increase the allowed map file size too.
 
beta 1.20 is there now, and it should be a lot better in terms of macro handling (and log messages).

It will still crash if you hold a macro button down too long, but this seems to be a somewhat fundamental problem. If a real IR code is received just as one is being injected, it results in a crash. It's possible to replicate this without a macro being involved by pressing a remote control button at the same time as injecting a code from the command line. That's going to be hard to fix, and the reverse engineering for the injection wasn't done by me so I don't know all of the internals there.
 
You must log in or register to reply here.
Back
Top