Wrong x-scale on disc-related statistics about rpi-monitor HOT 15 CLOSED

I checked all my stats and x-scale look good. I don't really understand your issue maybe, pasting a screenshot will help to understand.

from rpi-monitor.

With Temp everything is ok:

With alls Disks and Mem at the same time the x-scale is static like this:

Something has to be undefined and this could cause this.
With the error on last issue (rrd not found) I have seen, that missing information may be filled with other information. Has to be something to do with internal enumeration I think.
or I'm completely on the wrong way.
I don't know, where to start with to find the reason for this timescale problem.

from rpi-monitor.

I'm suspecting the graph update to be hang.
It can be checked by using the 2 weeks view and check the date displayed is correct.
If it looks ok, does the data still updated and reflecting the disk usage?
You can create a file with the command 'dd' and see if the graph is updated.
If it is hang, removing the rrd files and restarting should fix the issue.

from rpi-monitor.

No, the graphs are written well.
Changing the views shows that, because there you can see the start of logging and its length fits to the correct graphs.
But even this Weeks/Month view is with fixed scale!
Here's a zoomed view:

I will make more tests tomorrow ...

from rpi-monitor.

It's weired.
Now after reload the scale has jumped to another range (don't know why)
It's not the correct scale, but later as before. O_o

Edit: Exactly on the right border time I made a reboot of the raspberry!
There has to be a relation with this..

from rpi-monitor.

Did you try to delete the RRD and let RPi-Monitor recreate them?
Also, on the current RRD, I feel that rrdtool command can return some interresting info but I don't know what and how, this is just an idea to follow.

from rpi-monitor.

Had no time for systematic checks, yet.
I will have a look at it later this weekend or next week.
The empty.rrd is newly generated with your last fix.
But there has to be some other reason for this behaviour because I had this problem before with 2.4.
But I don't know when and why it firstly occurs.
I've seen some weired beaviour of the graphs when there were the rrd-missing-messages and I want to understand this.
I would like to find the reason for this to avoid it in future and if I don't find where this comes from, I will completely remove rpimonitor and install it new - I think, this should fix it.
Because noone else seems to have this problem, there has to be a special thing with my installation.

Let's leave this issue open until I made some more investigations.

from rpi-monitor.

Hello all. I just signed up to git, to confirm the issue which deMattin discovered. I'm using RPi-Monitor for several weeks but didn't notice that some ticklabels showed the wrong time.

As an example the graph for swap is using the lastupdate time from empty.rrd not from swap_used.rrd:

the graph for cpu is using the correct lastupdate timestamp from load1.rrd:

I used following command on my rpi to see xml-dumps of rrds:
rrdtool dump swap_used.rrd | less

There may be some wrong calculation on the client side in js-code for some reason?

from rpi-monitor.

I think i found an easy way to fix this for me. After being created, empty.rrd is never updated again, so the timestamp remains always the one of the creation. What would happen, if it would be updated like all other rrds after every delay?

So I tried the following:

1. stop rpimonitor
2. deleted all rrds in /usr/share/rpimonitor/web/stat
3. added the following lines to /etc/rpimonitord.conf.d/default.conf:

dynamic.16.name=empty
dynamic.16.source=false
dynamic.16.regexp=(.*)
dynamic.16.postprocess=
dynamic.16.rrd=GAUGE

1. restart rpimonitor

Now empty.rrd will be updated after every delay as all other rrds. The value doesn't matter and will always be the same (NaN) but the timestamp is updated. This is a workaround I can live with. 👍

Any comments on this?

from rpi-monitor.

I made some changes and tests but couldn't find another way to fix it.
I think, eagle-1's solution is a save and good way to define the scale.
It's also more logical this way (y-values of static and dynamic have both same max. x-value).

I made this changes too and you don't need to delete the rrds.
You just need to:

1. sudo service rpimonitor start
2. make the changes in /etc/rpimonitord.conf.d/default.conf as described by eagle-1
3. sudo service rpimonitor start

Thanks!

from rpi-monitor.

empty.rrd needs to be generated each time a static data need to be drawn into a graph.
The embedded server does that. Bug is then fixed.
With external server, it is not possible. Restarting RPI-Monitor periodically will improve the accuracy.

from rpi-monitor.

With the newest Version 2.6 of RPi-Monitor I have the bug again and the fix as described from eagle-1 didn't work anymore. It only occurs on graphs which also has a static line. How can that be fixed?

from rpi-monitor.

I do reopen this bug since it looks not fixed...
When I tested the fix I made (regenerating empty.rrd each time it is requested by browser). I didn't notice that it was in reality generated at start :-(.
empty.rrd is owned by root so it can't be regenerated by pi user.
To fix the issue and make my fix work, you should change the ownership of empty.rrd with the command:
sudo chown pi:pi /usr/share/rpimonitor/web/stat/empty.rrd

I'll update rpimonitord to generate empty.rrd with the correct ownership.
Until now, you can add the command described upper into /etc/init.d/rpimonitord. You may have to add a sleep before this command to let rpimonitor the time to generate the file.

from rpi-monitor.

Change ownership of empty.rrd to activate on demand regeneration.
This fix has been done into RPi-Monitor-deb.

from rpi-monitor.

Got bit by this because running with systemd two processes are started as root:root, but a third one as pi:pi. Hence empty.rrd ends up owned by pi:pi, but installing from Git the /var/lib/rpimonitor path is owned by root:root and user pi can't actually update the file, hence the skewed time for some stats.

The fix (in my case at least): chown -R pi:pi /var/lib/rpimonitor
And add this to systemd:

...
[Unit]
...
User=pi
Group=pi
...

/PS: if running as user pi the CPU freq is null, edit the line in templates/cpu.conf like this: dynamic.1.source=sudo cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq

from rpi-monitor.