[scarecrow420]

Hi,

So I implemented the SignalStatus calls into our PVR addon (pvr.wmc) the last couple of days and what I found was that XBMC is asking for signal status every 1 second (when watching a live channel, and when the "Include Signal Quality" option is set in System->PVR).

Infact there appear to actually be 2 places in code that are calling this in a Loop with only 1000ms sleep at the end of the loop (one in PVRClients.cpp:rocess() and one in PVRGUIInfo.cpp Process()). As far as I can tell, the only place where the resulting m_QualityInfo information is used, is when the "O" diagnostic/OSD is being displayed to show the values on screen. I haven't seen anywhere else where this information is used such as popping up a toast notification to user if signal is low or whatever.

Given that it is only used by the diagnostic OSD, it seems surprising that XBMC would be calling this twice every second, when the OSD isnt even displaying. I have seen some of the other addons actually have implemented throttling where they only send every X'th call, to the backend. We could do something similar of course but I was also thinking, ideally XBMC should only ask for it this frequently when it actually wants to do something with the data.

Is it just a simple oversight on the XBMC side, or am I missing something?

Would a pull request be helpful in getting it fixed? I could make XBMC only ask the PVR plugin for SignalStatus when the diagnostic OSD is actually being displayed (of course in addition to all the existing conditions being met as well)

[FernetMenta]

You don't forward GetSignalStatus to the backend, do you? vnsi backend sends this info to the addon every 10 sec where it is buffered.

[scarecrow420]

yes i did implement it to send the message to the backend as that's generally how we handle most PVR functions (the client side is deliverately thin and simple). It was only once i had coded it and was testing, that I found XBMC calls it every second which was a surprise. Considering the only thing that uses it is the OSD diag display I dont see why it should be called so frequently when it isnt being used. Even if we were piggy backing the data into an existing message going back to clients, it seems a bit strange we should have to cache it in the client side and constantly update it on the server side, while XBMC "refreshes" it every second when the only thing it's used for is the OSD display. Even in your example you are getting new data every 10 seconsd but XMC is querying your frontend addon 10 times. Do you agree it's a bit off? I think XBMC should only poll it per 1 second, while the OSD is showing. Other times it shouldn't poll it at all...

[FernetMenta]

The GUI shouldn't poll at all. Lower layers should send events with data which should be made available to the gui without the need for polling and locking. But this a general issue of the entire application.
I have not looked into the code but I think you block the main thread when waiting for the backend to answer this call. Regardless of how often this is called, you should buffer the data in the addon.

[scarecrow420]

the Process() loop are doing the call, and saving the data to local variables. i assume the GUI is then displaying those local variables. So it isnt the GUI directly polling, but the fact still remains that the background process is calling it every second, regardless of whether the data is being used/displayed or not. i would make it so the background thread dont make the call unless a bool (b_SignalStatusReqd) is set. And that bool can be set/unset by the GUI when it displays the diag OSD...

[FernetMenta]

And that bool can be set/unset by the GUI when it displays the diag OSD...

oh no, that would be really ugly.

There are already trigger functions for epg, timer, channel updates. Instead of being polled addons should inform PVR about new values to signal status.

[scarecrow420]

Are you saying how something should be changed if there were to be a change... or are you saying there is already a trigger we are meant to call?

Is there a way for an addon to know when the user has the OSD diag display showing? Why call for signal data when nothing is using it...

[FernetMenta]

This is not necessarily related to OSD. A skin can use this information where ever it thinks it's useful. Requesting the information from the backend at the time it is used for displaying is silly. It has to be buffered somewhere. This is either in the addon or you find a place a level higher in PVR where it could make sense, then trigger an update by a trigger method (which does currently not exist for this purpose)

[scarecrow420]

fair enough. for now I am doing like some other addons do - caching the result in the client and only sending every n'th request to the backend. N is configurable but default to 10 (so roughly 10 seconds, given XBMC calls it every 1 second).