Solved Is the UDP socket used by kodi-send rate limited?
#1
I'm writing some code to forward media keys to kodi using kodi-send, because I want to run kodi from within a desktop environment where the window manager eats the media keys (gnome-shell on linux).

Everything is working well, except that after a while of mashing buttons, kodi stops responding to them. If I reduce my code to a simple "kodi-send -a Mute" in a loop once a second or so, the problem still occurs, with muting and unmuting for about 15 seconds before kodi stops responding to them. It then starts responding again, seemingly about 15 seconds later. 

I've verified with netcat listening on port 9777 that the UDP packets are being sent and that netcat can recieve them, so this makes me think it's kodi.

It looks like a rate limit - that kodi ignores further UDP packets if it recieves more than some threshold in a 15 second interval or so. Is this intentionally the case?

If so, can it be changed in any way? Holding down a volume key generates several events a second, and if you adjust the volume more than a few times in a 15 second interval, this is enough to trip the rate limiter and prevent further action for about 15 seconds.

Actually, looking at EventServer.cpp, I see there is a maximum number of clients (20), and a 1 second receive timeout per client. Perhaps each call to kodi-send is a separate client, and the maximum number of clients is being reached?

Anyway, if anyone has advice for how I can write my code to be friendlier so that all events are received, that would be appreciated.

Perhaps this is a bug: I don't see kodi-send sending a 'BYE' packet when it is done, that might be causing the number of clients to go over the limit because they are not being cleaned up until they timeout.

EDIT: I see in the log: "WARNING: ES: Cannot accept any more clients, maximum client count reached", so suspicion confirmed. Haven't worked out how to avoid this quite yet, modifying kodi-send to send a BYE packet doesn't seem to help.
Reply
#2
Problem is solved: each time kodi-send is called, it's a new originating UDP socket, which counts as a new client as far as kodi is concerned (BYE packets don't seem to remove the clients from the list of clients, so there doesn't seem to be a way to shut down cleanly). So you have to not use a new socket every time if you don't want to hit this effective rate limit. I'm doing this by using xbmcclient.py directly from Python so that it can re-use the socket. Or something like that, I'm not totally sure of the reason behind it, but just using the library the same way that kodi-send does totally fixes the problem.
Reply
#3
Thread marked solved.
Reply
#4
(2018-05-22, 08:57)chrisjbillington Wrote: Problem is solved: each time kodi-send is called, it's a new originating UDP socket, which counts as a new client as far as kodi is concerned (BYE packets don't seem to remove the clients from the list of clients, so there doesn't seem to be a way to shut down cleanly). So you have to not use a new socket every time if you don't want to hit this effective rate limit. I'm doing this by using xbmcclient.py directly from Python so that it can re-use the socket. Or something like that, I'm not totally sure of the reason behind it, but just using the library the same way that kodi-send does totally fixes the problem.

Hi Chris, You seem to have solved this problem with kodi-send, but it is not clear to me how you did it. Do you still know what you did to solve this in python ?
Thanks
Rene
Reply

Logout Mark Read Team Forum Stats Members Help
Is the UDP socket used by kodi-send rate limited?0