Bugzilla – Bug 11804
Unkown IR codes not being reported to WebUI and CLI (was: --d_ir no longer works?)
Last modified: 2009-05-04 09:34:58 UTC
is it just my impression or the --d_ir option is gone? I'm trying to debug a 3rd party remote control but I'm not being able to get the unkownir events despite the player.ir being on debug mode on the Squeezecenter > Advanced > Logging Am I missing something? Best regards
--d_* options are all long gone (save for a few specific startup-related options). Logging is now based on log4perl and operates via the --debug command line option. Options from the web UI match the options that you can set from the --debug flag. If you want the logging options saved through server restarts, make sure you have checked that option in the WEBUI as well. the player.ir option in the UI will enable ir logging. "unknownir" event's are handled via the event notification API rather than being logged. However, the unknown byte codes are still reported at INFO or higher level (thus, DEBUG is included), with the message "$irCodeBytes -> unknown". If you have further questions, please take the discussion to the forum as this isn't really bug material. If you are not seeing any output at all from player.ir, feel free to reopen the bug.
KDF, thanks for the answer. It worth to mention that some pages in the wiki still point to the d_ir (http://wiki.slimdevices.com/index.php/Log_File) I did suspect the options were gone and then turned on player.ir in debug mode o the webui ( Squeezecenter > Advanced > Logging > player.ir = DEBUG ) but still have no unknownir events coming through, I reopened the bug to reflect this. Note; Using IR blaster learning wizard I can see the SB3 is able to receive/learn the IR codes.
"unknownir" events, as I stated are now processed through the event notification API. You will not see this specific message. What exactly is the nature of the bug you are reporting? Are you not seeing ANY ir log output? Are you not seeing the specific message that I already mentioned in my earlier comment? Let me make it clear again that you will at no point see "unknownir", but the raw codes are most certainly still expected to be showing up, albeit with slight different message wording. Wiki isn't an official document. It is an openly edittable system. Feel free to correct them as you see fit.
KDF, Parsing of IR commands work. Logging works as well but I repeat, no signs of unknown ir codes being notified. This is a typical output of my logfile with the player.ir enabled in debug mode. [09-04-15 16:37:03.5904] Slim::Hardware::IR::lookupCodeBytes (452) 7689b04f -> code: arrow_down [09-04-15 16:37:03.5907] Slim::Hardware::IR::lookupCodeBytes (452) 7689b04f -> code: arrow_down For what I understand this is the mapping of IR code 7689b04f to arrow_down as defined on the remote controller configuration file. So far so good. Based on the message above I believe that when I press a button on a 3rd party remote, I should be able to see something like: Slim::Hardware::IR::lookupCodeBytes (452) XYZIRCODE -> unknown where XYZIRCODE equals the hex of the IR code received by the SB3. However, when using a 3rd party controller I cannot see any events/messages/log at all. Am I correct to expect the "Slim::Hardware::IR::lookupCodeBytes (452) XYZIRCODE -> unknown" message ?
If SC receives raw codes, you should see: Slim::Hardware::IR::lookupCodeBytes (459) XYZIRCODE -> unknown You can set network.protocol.slimproto and see if you are getting the BUTN event from the player. After that, the only thing that would block it from getting to the "unknown" message would be if the code received is coming up as all zeros but you should see that in the BUTN log messages: Slim::Networking::Slimproto::_button_handler (1312) Hard button: $button time: $time You'll also need to set plugin.irblaster as the IRBlaster plugin does intercept the standard processing path.
KDF, Thank you for your answers. Did the following: * Removed the IR Blaster plug-in * Restarted squeezecenter * Ensured IR Blaster was gone. * Configured logging network.protocol.slimproto = Debug Still no signs of the IR codes. Does it worth to check it over the CLI?
Are you seeing any kind of log output at all? Try using the links on the server settings->information/status page. Make sure you are at least looking at the right place for output. If the slimproto logging isn't showing anything, then your player is not receiving any codes. This isn't really the best place to debug/diagnose, and I'm not really the person to keep walking you through everything (The support team is FAR better at that, or the forum users). Basically, you will never see the unknown ir logging if you never see the BUTN messages.
(In reply to comment #7) > Are you seeing any kind of log output at all? Try using the links on the > server settings->information/status page. Make sure you are at least looking > at the right place for output. :-) I double checked the log URL and it is fine. :-) That's a sample output from few moments ago: [09-04-16 09:30:19.5108] Slim::Player::Squeezebox::sendFrame (1041) sending squeezebox frame: visu, length: 2 [09-04-16 09:30:19.5111] Slim::Player::Squeezebox::sendFrame (1041) sending squeezebox frame: grfe, length: 1284 [09-04-16 09:30:19.6112] Slim::Networking::Slimproto::client_readable (388) Slimproto frame: IR , len: 10 [09-04-16 09:30:19.6116] Slim::Hardware::IR::lookupCodeBytes (452) 768940bf -> code: power [09-04-16 09:30:19.6118] Slim::Hardware::IR::processIR (692) 768940bf 769919.948 1239838219.6117 [09-04-16 09:30:19.6121] Slim::Hardware::IR::lookup (481) Found button power for 768940bf [09-04-16 09:30:19.6123] Slim::Hardware::IR::lookupFunction (532) irCode not defined: [power.repeat] for mode: [OFF.datetime] [09-04-16 09:30:19.6125] Slim::Hardware::IR::repeatCode (972) irCode = [undef] timer = [769919.948] timediff = [0.108999999938533] last = [power_toggle] [09-04-16 09:30:19.7614] Slim::Hardware::IR::lookup (481) Found button power for 768940bf [09-04-16 09:30:19.7617] Slim::Hardware::IR::lookupFunction (532) irCode not defined: [power.single] for mode: [OFF.datetime] [09-04-16 09:30:20.5137] Slim::Player::Squeezebox::sendFrame (1041) sending squeezebox frame: grfe, length: 1284 [09-04-16 09:30:20.7432] Slim::Networking::Slimproto::client_readable (388) Slimproto frame: IR , len: 10 [09-04-16 09:30:20.7437] Slim::Hardware::IR::lookupCodeBytes (452) 768940bf -> code: power [09-04-16 09:30:20.7439] Slim::Hardware::IR::processIR (692) 768940bf 769921.08 1239838220.7438 [09-04-16 09:30:20.7442] Slim::Hardware::IR::lookup (481) Found button power for 768940bf [09-04-16 09:30:20.7444] Slim::Hardware::IR::lookupFunction (525) Found function: power_toggle for button power in mode common [09-04-16 09:30:20.7447] Slim::Hardware::IR::processIR (786) irCode = [power_toggle] timer = [769921.08] timediff = [1.13199999998324] last = [power_toggle] [09-04-16 09:30:20.7449] Slim::Hardware::IR::processCode (1119) irCode: power_toggle, 00:04:20:06:52:d7 [09-04-16 09:30:20.7452] Slim::Hardware::IR::lookupFunction (532) irCode not defined: [power_toggle] for mode: [OFF.datetime] [09-04-16 09:30:20.7454] Slim::Hardware::IR::executeButton (1066) Trying to execute button [power_toggle] for irCode: [power_toggle] [09-04-16 09:30:20.7457] Slim::Hardware::IR::executeButton (1097) Executing button [power_toggle] for irCode: [power_toggle] Slim::Buttons::Common::__ANON__ [09-04-16 09:30:20.7462] Slim::Player::Squeezebox::sendFrame (1041) sending squeezebox frame: aude, length: 2 [09-04-16 09:30:20.7468] Slim::Player::Squeezebox::sendFrame (1041) sending squeezebox frame: grfe, length: 1284 [09-04-16 09:30:20.7477] Slim::Player::Squeezebox::sendFrame (1041) sending squeezebox frame: grfb, length: 2 [09-04-16 09:30:20.7483] Slim::Player::Squeezebox::sendFrame (1041) sending squeezebox frame: grfe, length: 1284 [09-04-16 09:30:20.7489] Slim::Networking::Slimproto::client_readable (388) Slimproto frame: STAT, len: 55 [09-04-16 09:30:20.7493] Slim::Networking::Slimproto::_stat_handler (756) 00:04:20:06:52:d7: STAT-aude: fullness=0, output_fullness=3521152, elapsed=0.000 [09-04-16 09:30:20.7495] Slim::Networking::Slimproto::_stat_handler (783) 00:04:20:06:52:d7 Squeezebox stream status: > If the slimproto logging isn't showing anything, then your player is not > receiving any codes. This isn't really the best place to debug/diagnose, and > I'm not really the person to keep walking you through everything (The support > team is FAR better at that, or the forum users). I agree with you. My impression is that the IR debug feature for logging unknown IR beans isn't working. My initial suspicion was that the syntax of the Squeecenter changed, something that you confirmed (debuging now happens over the WebUI) I tried to get the events using the CLI but no success as well. I guess it is related to the I'll change the bug description and affected software. > Basically, you will never see the unknown ir logging if you never see the BUTN > messages. As I guessed.
Felix would know better, specifically, but I suspect this is a case of SC no longer handling unknown IR at all. I don't recall any note regarding this in firmware updates, but it not a simple thing to search for any more. This was dropped once before, and may have been so again given that the IRBlaster plugin can do learning quite well, and has options for showing raw codes in other ways. Having the IRBlaster as a recommended plugin does make internal handing needs much slimpler.
This feature hasn't changed in fw for a long time and it is still working for unknown remotes if the remote uses 32 bit NEC commands like SB3, TR etc. remotes do. I captured this with a 7.3 SC r25910 and player.ir debug turned on: [09-04-27 17:27:27.4962] Slim::Hardware::IR::lookupCodeBytes (459) 4eb338c7 -> unknown [09-04-27 17:27:29.3294] Slim::Hardware::IR::lookupCodeBytes (459) 4eb312ed -> unknown [09-04-27 17:27:50.6421] Slim::Hardware::IR::lookupCodeBytes (459) 82a222dd -> unknown [09-04-27 17:27:51.1194] Slim::Hardware::IR::lookupCodeBytes (459) 82a2a25d -> unknown However if the remote uses a different command length or pattern then nothing is seen by SC even if player.ir is turned on. My guess is that the remote you are trying with falls into this category and that is why you don't see any output.