More > JRiver Media Center 32 for Windows

Volume protection lags when using MCWS/v1/Playback/Volume

(1/3) > >>

mattkhan:
I've noticed irregular volume stepping when volume protection is on, for example if I hit MCWS as fast as I can then it's just totally broken


--- Code: ---curl 'http://localhost:52199/MCWS/v1/Playback/Volume?Level=0' 2>/dev/null|grep Display; for i in {1..8}; do curl 'http://localhost:52199/MCWS/v1/Playback/Volume?Level=0.1&Relative=1' 2>/dev/null |grep Display; done
<Item Name="Display">0%</Item>
<Item Name="Display">5%  (-77.5 dB)</Item>
<Item Name="Display">1%  (-97.6 dB)</Item>
<Item Name="Display">1%  (-95.3 dB)</Item>
<Item Name="Display">1%  (-93.4 dB)</Item>
<Item Name="Display">2%  (-91.6 dB)</Item>
<Item Name="Display">2%  (-89.7 dB)</Item>
<Item Name="Display">3%  (-87.8 dB)</Item>
<Item Name="Display">3%  (-86.0 dB)</Item>

--- End code ---

if I add a delay similar to a human mashing a button on a remote control then it's a bit more sensible but still broken


--- Code: ---DELAY=0.25;curl 'http://localhost:52199/MCWS/v1/Playback/Volume?Level=0' 2>/dev/null|grep Display; sleep $DELAY;for i in {1..8}; do curl 'http://localhost:52199/MCWS/v1/Playback/Volume?Level=0.1&Relative=1' 2>/dev/null |grep Display; sleep $DELAY; done
<Item Name="Display">0%</Item>
<Item Name="Display">5%  (-77.5 dB)</Item>
<Item Name="Display">6%  (-73.2 dB)</Item>
<Item Name="Display">11%  (-53.6 dB)</Item>
<Item Name="Display">16%  (-46.1 dB)</Item>
<Item Name="Display">21%  (-39.5 dB)</Item>
<Item Name="Display">26%  (-37.0 dB)</Item>
<Item Name="Display">31%  (-34.5 dB)</Item>
<Item Name="Display">36%  (-32.0 dB)</Item>

--- End code ---

if I increase the interval to 0.5s then it works reliably

if the intent is to limit the rate of volume change then it's clearly not working because it still mostly honours my requests with 0.25s delay just gets the odd request wrong whereas if you go faster then it's just totally broken.

I'm not sure what the intended behaviour is here but producing arbitrarily incorrect increases is not helpful, simply limiting the max increase to 5% in a single request seems reasonable but it should do that reliably.

mattkhan:
btw, the pattern shown in the 0.25s delay case is repeatable, it always gets that 2nd request wrong and it happens as soon as the requested change approaches the limit

e.g. Level=0.04 produces these steps


--- Code: ---<Item Name="Display">0%</Item>
<Item Name="Display">4%  (-82.0 dB)</Item>
<Item Name="Display">6%  (-74.0 dB)</Item>
<Item Name="Display">10%  (-56.0 dB)</Item>

--- End code ---

whereas Level=0.03 works produces the correct step

Matt:
Limiting won't let you go up more than 5% in a single call and limits you to 20% a second.

mattkhan:
You can see it's not doing that in my log output

It makes 2 requests to go up by 5% each time with a 250ms delay and it applies just 1% increase on 2nd request, another request 250ms is allowed the full 5%. With no delay, it's just completely broken and the subsequent requests even reduce the volume. Based on your description it should allow the first 4 requests till we get to 20% and then do nothing.

mattkhan:
https://yabb.jriver.com/interact/index.php/topic,138200.0.html would also help here so we know when we are clamped

Navigation

[0] Message Index

[#] Next page