JSONRPC::requestMethod (455) request not dispatchable!

[Paul Webster]

I see quite a lot (10s per hour 24*7) of log entries like this - but with no discernible problems on the various players.

[18-10-12 10:13:22.9259] Slim::Web::JSONRPC::requestMethod (455) 00:04:20:xx:xx:xx: request not dispatchable!
[18-10-12 10:13:23.4076] Slim::Web::JSONRPC::requestMethod (455) bb:bb:ed:xx:xx:xx: request not dispatchable!
[18-10-12 10:13:23.4493] Slim::Web::JSONRPC::requestMethod (455) aa:aa:ed:xx:xx:xx: request not dispatchable!
[18-10-12 10:13:23.4883] Slim::Web::JSONRPC::requestMethod (455) aa:aa:eb:xx:xx:xx: request not dispatchable!
[18-10-12 10:13:23.5279] Slim::Web::JSONRPC::requestMethod (455) bb:bb:f2:xx:xx:xx: request not dispatchable!

Odd thing is only 1 of the MAC addresses seems to match a listed player (I have 10 listed).
The 00:04:20 is a Slim Devices box ... but does not match the SBR or SB2 that is connected (it is possible that another one is powered up somewhere).

Anyway ... is it worth trying to hunt down the cause of this or, if not, could that error message be moved to the Warn category so that it will disappear from logs that are set to Error (assuming it is "(network.jsonrpc) - JSON-RPC API Logging")?

[mherger]

> Odd thing is only 1 of the MAC addresses seems to match a listed player
> (I have 10 listed).

That's exactly why you see these in the log: some client (web UI,
smartphone app etc.) is requesting data for players which are not connected.

> Anyway ... is it worth trying to hunt down the cause of this or, if not,
> could that error message be moved to the Warn category so that it will
> disappear from logs that are set to Error (assuming it is
> "(network.jsonrpc) - JSON-RPC API Logging")?

I would try to figure out where those requests come from. Eg. by
enabling exactly that logging category.

--

Michael

[Paul Webster]

I have traced it to Domoticz - polling every 30 seconds.
Now to work out why it thinks I have devices that do not exist.

[Paul Webster]

Aha ... I think it might be related to UPnP Bridge.
Some devices (e.g. TV) are switched off ... UPnP Bridge removes them from the set of devices when they are unreachable ... and I think that would also explain the odd MAC addresses (UPnP Bridge faking them).