Remote not controlling PVR properly (not batteries)

One thought (clutching at straws): remove batteries, press buttons (to force any charge stored to dissipate), leave for a bit, press buttons some more, replace batteries.
 
I have the full code list for the Humax and Kameleon somewhere. If I haven't posted them on here before I'll dig them out when I get home tomorrow.
 
I did not know that.

I do not have money to throw away, so can only afford ancient models (S4) when the price has dropped :eek: :o_O: :roflmao:

Edit to add: You can buy an IR emitter that plugs into the 3.5mm jack. Cost £0.99
 
Last edited:
Now that you have custom firmware installed, if you run the ir3/debugon diagnostic and reboot then you will get a log file called humaxtv.log which will contain more information about the IR signals being received. Try sending some of the codes from your broken remote and post what you pressed and what appears in the log.
 
Before I spend the money on a new RM-F04, does anyone have any thoughts on how to force the RM-F04 to send the correct codes?
(I've already tried changing it to another remote mode/channel, but the remote isn't communicating that correctly to the Hummy and it therefore just ends up on a different mode, while the box is still in mode 1)
We have a way of forcing the box into a different mode without a handset so a solution might be for you to get the handset into mode 2 then put the box into the same mode. I'll dig out the command for you.
 
Just found it on the wiki (https://wiki.hummy.tv/wiki/WebIf_Remote_Controller)

Run this from the command line to put the box in mode 2.

Code:
humax# ir CURMODE MODE DELAY2 MODE2

You need to access the box's command line interface through the telnet menu or the web interface diagnostics->web shell if you have that installed.
The humax# bit is the box prompt so don't type that, just the bit from ir CURMODE onwards.
 
Black Hole, thanks for your suggestion. Worth trying, but it didn't work

af123, I managed to get the Humax to change remote mode and the remote to change mode to match it. Unfortunately, the problem existed in all the remote modes - exactly the same behaviour, with the same buttons turning off the box.
 
I haven't yet worked out how to run the ir3/debugon diagnostic, but I did run the command ir -l in the web shell, which gave the results below. On first sight I thought there might be some problems (e.g. 8 = a), but as there aren't multiple commands mapped to standby, I assume they're correct. I'll look up how to do ir3/debugon and will report back.

Thanks again for the help

POWER - 0
STANDBY - 0
SOURCE - 2
ONE - 3
TWO - 4
THREE - 5
FOUR - 6
FIVE - 7
SIX - 8
SEVEN - 9
EIGHT - a
NINE - b
ZERO - c
0 - c
1 - 3
2 - 4
3 - 5
4 - 6
5 - 7
6 - 8
7 - 9
8 - a
9 - b
TV/RADIO - d
MENU - e
P- - f
P+ - 10
UP - 11
LEFT - 12
OK - 13
RIGHT - 14
DOWN - 15
EXIT - 16
MUTE - 18
YELLOW - 1a
GUIDE - 1b
RED - 1c
GREEN - 1d
BLUE - 1e
VOL+ - 1f
VOL- - 40
BACK - 41
OPT+ - 42
INFO - 43
AUDIO - 45
SUB - 46
PORTAL - 4b
SLEEP - 4c
LIST - 4d
WIDE - 4e
V-FORMAT - 4f
PLAY - 60
REC - 61
PAUSE - 62
STOP - 63
FF - 64
REW - 65
SKIP/BACK - 66
SKIP/FORW - 67
ADDBOOKMARK - 6a
BOOKMARKS - 6b
SLOW - 6c
TEXT - 6e
MEDIA - 6f
MODE - 70
MODE1 - 71
MODE2 - 72
MODE3 - 73
MODE4 - 74
MODE5 - 75
MODE6 - 76
CURMODE - 7f
PVR - 80
TV - 81
DVD - 82
AUDIOD - 83
 
I haven't yet worked out how to run the ir3/debugon diagnostic
Either start a Telnet session and use the menu, or WebIF >> Diagnostics and type the required diagnostic name in place of where it is defaulted to "general".
 
Thanks. I also added the file .irhold in /tmp/ as per the Wiki to make sure that I didn't turn off the box when pressing the various buttons that make it turn off.

I've attached the humaxtv.log file and the list of buttons on the remote that I pressed (commands.txt). I tried to do the same with the One For All remote, but the log file came back empty, so I might have to figure that out over the weekend.
If anyone can give any insight, I'd really appreciate it.
 

Attachments

  • humaxtv.log.txt
    13.4 KB · Views: 30
  • Commands.txt
    94 bytes · Views: 17
There doesn't seem to be any corruption in that data stream but there is a lot of IR activity for a non-Humax device which would usually mean that something else in the room was flooding the sensor. In this case it could be that your remote control is broken in a way that makes it send the TV & PVR signals together in PVR mode but that's clutching at straws.

The other device is using NEC1 4.251 which usually means an LG television (or an old Vizio TV).
 
Does the OP have any unaccounted for remote control handsets? A couple of years ago the HDR-FOX in our lounge began to respond a bit sluggishly. I assumed its remote control needed new batteries but I was confused because the red light on it was bright when pushing buttons. After investigating I found that the spare TV remote was down the side of an armchair with the IR emitter pointing forwards. Pressure from the chair cushion was keeping one of the buttons pushed in and this was causing the problem.
 
Thanks MontysEvilTwin In my original investigation, I checked there were no batteries in any other remotes in the room, and even moved them and the Nintendo Wii remotes out of the room. The only change since then is that I've been using the One For All Kameleon (in combination with the RM-F04, since I haven't yet programmed all the functions into the it). I'll move that out of the room and retry.

af123 my TV is an LG plasma, so your theory could be correct, though the RM-F04 doesn't activate any controls on the TV when it's in PVR mode. From trying to match up the commands I pressed against the IR received just now, I can see what you mean about there being too many different IR codes received. I'll give it another try this weekend to monitor live exactly what IR codes are logged against each button. BTW, is it normal for each IR code to repeat multiple times?

Whatever the outcome of that, it seems like I should either programme the One For All properly or buy a new RM-F04.

Thanks all.
 
BTW, is it normal for each IR code to repeat multiple times?
Yes, and the log shows events for both 'button down' and 'button up' which results in more log lines. Here's your log for pressing the MUTE button (button code 18) for example:
Code:
Real IR code: 00000000 0xe7181000 (18) [foreign=0]
Real IR code: 0x000001 0xe7181000 (18) [foreign=0]
Real IR code: 0x000001 0xe7181000 (18) [foreign=0]
Real IR code: 0x000001 0xe7181000 (18) [foreign=0]
Real IR code: 00000000 0xe7181000 (18) [foreign=0]
Real IR code: 0x000001 0xe7181000 (18) [foreign=0]
Real IR code: 0x000001 0xe7181000 (18) [foreign=0]
Real IR code: 0x000001 0xe7181000 (18) [foreign=0]

The foreign codes that are associated with an LG TV have fb04 in them, like this one:
Code:
Real IR code: 0x000001 0xfc03fb04 (3) [foreign=1]

It's a feature of the Humax IR receiver that it passes all received NEC1 control codes up to the Humax software whether it's for the Humax or not.

Whatever the outcome of that, it seems like I should either programme the One For All properly or buy a new RM-F04.
Yes, seems so. I have several RM-F04s that have never been used. If you PM me your address I will post one to you if you want.
 
Oh, one thought. How about reprogramming the TV button to a completely different TV and see if it fixes PVR mode or at least changes the foreign codes in the log.
 
No. It could be so that the different modes can be supported. If the filtering was done at the hardware then that would be harder.
 
Yes, and the log shows events for both 'button down' and 'button up'
Are you sure about that? The NEC format as used by the Humax transmits the address and data code once on a button press followed by the short 'repeat' code if it's held down. The multiple log entries for one button press seem to indicate the log software adding one complete code to the log for every repeat code received.

(I did a fair bit of commercial work with remotes ten years or so back, long enough not be able recall all the details and have to refer to my notes.)
 
Back
Top