Kodi Community Forum

Full Version: Database request every 30 minutes, wakes NAS
You're currently viewing a stripped down version of our content. View the full version with proper formatting.
Hello,

I have an issue I'm not able to get rid of...

I have kodi 16.1 installed on a raspberry pi 3, with the osmc distrib.
I configured a MySQL database on my NAS (synology) to be able to share it between multiple kodi installs. But for now, the only kodi running is the one on the pi.

Kodi is running 24/7 so that I am able to wake the TV from any remote (eg. the kodi official remote on an iPad).

The issue is that every 30 minutes, kodi sends a request to the database, preventing the NAS to go in sleep mode.
At first it was waking the NAS every 10 minutes. Turns out it was the skin helper addon that had the random option activated. I turned it off and thought I was done.

But no, every precisely 30 minutes, the same request (concerning movie sets, which I did not activate) is sent. Since Sleep on the NAS is set after 30 Minutes of idling, NAS never go to sleep.

I had a look at every option, even tried a search in the xml files but did not find anything triggered every 30 minutes.

I activated all debug logs, and this is what the request looks like :

13:24:57 54960.828125 T:1732137968 DEBUG: JSONRPC: Incoming request: { "jsonrpc": "2.0", "method" : "VideoLibrary.GetMovieSets", "params": {}, "id":1 }
13:24:57 54960.828125 T:1732137968 NOTICE: WakeOnAccess [192.168.1.110] trigged by accessing : MySQL : Videos99
13:24:57 54960.859375 T:1732137968 NOTICE: WakeOnAccess success exit, server already running
13:24:58 54961.675781 T:1732137968 DEBUG: RunQuery took 771 ms for 125 items query: select * from movie_view JOIN sets ON movie_view.idSet = sets.idSet ORD
13:24:58 54961.789062 T:1732137968 DEBUG: JSONRPC: Incoming request: { "jsonrpc": "2.0", "method" : "VideoLibrary.GetMovieSetDetails", "params": {"setid": 1
13:24:58 54961.828125 T:1732137968 DEBUG: RunQuery took 16 ms for 1 items query: select * from movie_view JOIN sets ON movie_view.idSet = sets.idSet WHERE
13:24:58 54961.882812 T:1732137968 DEBUG: RunQuery took 15 ms for 1 items query: select * from movie_view WHERE movie_view.idSet = 1
13:24:58 54961.910156 T:1732137968 DEBUG: JSONRPC: Incoming request: { "jsonrpc": "2.0", "method" : "VideoLibrary.GetMovieSetDetails", "params": {"setid": 2
13:24:58 54961.960938 T:1732137968 DEBUG: RunQuery took 19 ms for 1 items query: select * from movie_view JOIN sets ON movie_view.idSet = sets.idSet WHERE
13:24:58 54962.007812 T:1732137968 DEBUG: RunQuery took 17 ms for 1 items query: select * from movie_view WHERE movie_view.idSet = 2

So it seems that it is triggered by a json RPC command, but I can't find where it comes from.

Can someone help me find the origin of this so I can let my NAS go to sleep sometimes ?

Thanks very much for any help!
The only add-on that I know of that uses that call is the skin helper service. That will be called from somewhere in the skin you are using. If you ask in the skin's support thread, someone may be able to help you further.
Thanks for the answer.

I was using the default OSMC skin, but changed to confluence when I turned on the debug logs, because it was easier to activate all the components traces in confluence skin. The traces show that the request is still there, still every 30 minutes.

Is it possible that it's en option in the skin that's persistent across skin changes?
OK, I found it.

There is a timer of 1800s (30 min) is skin helper (in ListItems.py) that triggers a bunch of background stuff, one of which is counting movie sets.

I don't really understand why it is necessary, but this is the origin of the requests.

I commented out his part (I don't use movie sets, so I don't think there will be a big impact for me) and the requests are gone. The NAS still does not go to sleep though, so I think there is another process that keeps it awake. I'll try to find it, but I think it will be more difficult now that I don't have a clear event to track down...

Thanks for your help, narrowing down the source of the requests to skin helper addon was the hint I needed to identify the issue.