No QOS graph auto-update since 188?

Hello,

I recently updated 2 different ipfire installations to 188 and since then I noticed that QOS graphs are no longer auto-updating,while othe graphs does (system, network, etc…)

The graph works and can be manually refreshed, but the auto-update feature was nice.

I did not see anything related (or did I miss it ?) in the blog post about 188.

Best regards,
Manu.

Screenshot 188 vs 187 :

I just checked on my system and you are correct. The auto-update feature of the graph has stopped working. I don’t have a solution, but hopefully someone else does.

I also verified two other graphs do still auto-update: gateway and firewallhits. I didn’t check other graphs, so I can’t say for sure that the QoS graphs are the only ones whose behavior has changed.

FYI, I have a system on 188 that is auto-updating the QoS graphs. So it may not be the issue you thought. I don’t know why this system is auto updating and the one I checked earlier today is not, but there you go. :slight_smile:

That’s interresting, I still have another ipfire to update, I’ll check this one after the update and see if it does auto-update. If so i’ll try to compare some files see if there is any differences.

I encountered some errors doing the update (related to packet signature) but after a retry everything the update passed, so I thought it was just a temporary glitch with a mirror.

Anyway that’s just a mild annoyance more than anything else, and probably will start working again after next update.

Hi, I made the original auto-update patch way back when. So I was curious to see what is going wrong.

The div box around the graph must have the class “rrdimage” for the script to find it. So unfortunately this breaks the javascript. And this is unnecessary because it is already done by the JS (if it could find the graph).

This is easy to overlook because the rest of the web interface doesn’t use anything like this. :slight_smile:

2 Likes

Indeed, I edited graph.pl and set div class=“rrdimage” and it started auto-updating again !

But, should’nt it affect all graphs, not only the QOS one ?

3 Likes

For me, all graphs are affected :thinking:

But there is one difference: Apart from QoS, all other graphs have the time period “Day” by default. These graphs are only updated every 5 minutes.

Did you perhaphs manually select “Hour” to get to the faster auto update? If so, the update timer is (re)started at this moment.


Edit: For a better explanation, there are two different event handlers in rrdimage.js.
The first one runs on page load, looks for graphs and starts the auto-update timer. This one relies on the HTML class attribute, but at the same time can’t throw a “missing div box” error as there are also many pages without graphs.

The second one is attached to the “onclick” attribute and directly receives a handle of the graph box via this. So this one always works and has to restart the timer anyway after the user changed the time range.

Yes, I switched to hour to have a quicker update on the other graphs.

So if I understand correctly if you open a page which contains a graph and leave the default scale, it will never update, but if you change the scale then the auto-update will start working, right ? even if you switch back to the default/initial scale ?

1 Like

Correct! I think you can even click directly on the default button. It wasn’t planned but it works :slight_smile:

A fix has been merged into master for CU189.

3 Likes

3 posts were split to a new topic: QOS: speed tests are worse

I tried the patch for rrdimage.js from git. It doesn’t change anything.

Precisely:

  • choose QOS WUI page ( default is hour period, can be best checked )
  • after >15 minutes, no update
  • clicking Hour starts update process.

Don’t have enough experience in HTML et al. to search for the bug, can try only. :frowning:

On my side, it worked for 2x ipfire installation after I edited graphs.pl to have
div class=“rrdimage”
graphs.pl

but I haven’t touched/changed the rrdimage.js, it’s still the one from 188

After the change, I stopped/restarted QOS and refreshed the page.
Not sure it was necessary, but on my side it works

The patch is just

--- a/html/html/include/rrdimage.js
+++ b/html/html/include/rrdimage.js
@@ -35,7 +35,7 @@ function rrdimage_selectRange(buttonObj) {
 
 // Document loaded: Process all graphs, start reload timers
 $(function() {
-       $('div.rrdimage').each(function() {
+       $('div.graph').each(function() {
                let graphBox = $(this);
                _rrdimg_setRange(graphBox, graphBox.data('defaultRange'), true);
        });

which should do your change in rrdimage.js

Hi @bbitsch

Thanks for the feedback. I tested it in CU189 Testing, confirming the change was in rrdimage.js, and confirm the effect you found, that the problem is not solved.

When we manually tested it before submitted the patch, it looked like it had solved it.

I have flagged it to @ms and we will have another look at it.

1 Like

Okay, after discussion with @ms, I cleared the cache on my browser and then the graph is updating.

On the system you have that is not autoupdating, can you clear your browser cache and see what happens after 10 or 15 minutes to test it.

I just completely switched of the IPFire and client vm’s and then switched off the VirtualBox system, then restarted the host computer.

After bringing all the vm’s back on line again, the QOS is auto-updating on hourly, without having had to press anything.

It looks like clearing the cache is the thing to resolve this.

Presumably the cache will have a lifetime on the browser so if it is just left, it will eventually clear the old stuff out.

3 Likes

Bingo!
Clearing the cache did the job.

2 Likes

A patch has also been merged into CU189 Testing that changes the version date of the parameter, forcing the browser to update the cached version.

https://git.ipfire.org/?p=ipfire-2.x.git;a=commit;h=0555434effc70080d8278ca3db38fef51bba1efa

It is in the master branch. The nightly build is running and when it has completed successfully then the patch fix will become available in the Update from CU188 to CU189 Testing.

1 Like

Can confirm the newest CU189 Testing solves the problem.

2 Likes