WebAPI clientcount bug

[majstang]

Found a possible bug in ...../api/status.html

 

When RS is idle and no clients are connected status.html looks like this:

<status>

<recordcount>0</recordcount>

<clientcount>0</clientcount>

......

</status>

For each recording that starts, recordcount increases accordingly precisely as expected. What is unexpected is the clientcount follows the recordcount number. If 3 recordings are going the clientcount gets to 3 with no clients running.

<status>

<recordcount>3</recordcount>

<clientcount>3</clientcount>

......

</status>

Variables must have been mixed up in the WebAPI. Recordcount and clientcount shares the same value, which must be wrong.

Can be reproduced by disable all "Block Standby/Hibernate if DVBViewer is connected to same PC" in RS configure. Disable in two places in Web/UPNP. Disable in DVBServer and in RTSP Server.

bring up status.html. Start a recording. Refresh browser with status.html.

Edited July 7, 2013 by majstang

[Moses]

I'm not sure if this is a bug or a feature. If you add clients that view only, they get counted, too. So with clients the clientcount will be "real clients" + recordings. Maybe internal recordings are clients, too?

 

If you just want to know if rs is active, you can just check the clientcount. So maybe that indeed is a feature.

[majstang]

I did notice my hibernation script began to behave odd when using the value from the clientcount variable. Haven't used that variable for a long while so I'm not sure when this behaviour was introduced. Not that important to trace it back through all past RS versions though.

 

If starting clients for view only, they definitely should add to clientcount. However recordings adding the clientcount value sounds fishy to me. If RS has the control of the DVB-tuners, I imagine the recording engine writes the DVB stream as is without involving the webserver and streaming clients, so it should not add to clientcount. Of course I can be wrong, has happened many times before Only thing I'm sure on is recordings never increased clientcount value before.

[majstang]

I might as well, when we're already on the RS API and status.html topic, take the opportunity to humbly protest against how the most annoying thing RS API/status.html is configured. The variable "recordcount" collects several timers under it and not just recording timers. Autosearch timers, internal task timers and process timers are allowed to trigger/count-up "recordcount". These later named timers should be collected under an another variable and not interfere with "recordcount" which should be reserved to recording timers only. If each and every after recording task (process task timer which launches right after the recording timer ends) counts as a recording timer, how should such a software be abled to be scripted properly?

 

It's not the first time I've raised this question and I didn't have any luck getting it implemented so far. Unfortunately I never got the problems with implementing it explained to me either. The question I'm having is, is it possible in the first place? Are recording timers unique or are they just a slightly modified process task timer? If the latter it gets harder to separate recording timers from the other ones. Can of course be solved programmingwise by using unique markers for each timer type and condition them to be collected under different variables leaving the recording timers for "recordcount" only. And the rest of the timers to be collected under a new variable. In that way we can also get rid of other unfortunate sideeffects the current implementation brings, namely to avoid every autosearch timer, internal task timer and process task timer will flash the RS tray icon red and the balloon tooltip pops up if having show notifications enabled. The current handling seems unnecessary when it's not even a recording that starts or finishes which for a recording software is the only thing of interest.

 

Regards

Majstang