When using the line chart, the setting "amount of history to keep" does not seem to have any effect. I expect this setting to influence the amount of data that is displayed in the plasmoid. Thus the line chart should squeeze more data in the visible area. But this is not the case, the data is rushing through the area (in about 25 seconds) regardless of the history amount. Operating System: Gentoo Linux KDE Plasma Version: 5.21.0 KDE Frameworks Version: 5.79.0 Qt Version: 5.15.2 Kernel Version: 5.10.14-gentoo OS Type: 64-bit Graphics Platform: X11 Processors: 8 × Intel® Core™ i7-4810MQ CPU @ 2.80GHz Memory: 15.5 GiB of RAM Graphics Processor: Mesa DRI Intel® HD Graphics 4600
I have it set to 600 seconds here and it works for me, but I remember when I initially configured it (with 5.19.0 I think), it was a bit of a struggle with x/y scale data ranges to make it take effect. Maybe you could play around with that and see if it changes things?
I can confirm the bug. Whatever settings I use, I never get the chart to hold more than a few seconds' worth of data.
Git commit 10d8d20a3bc4016ee271aee234f7727e5640cedc by Arjen Hiemstra. Committed on 01/03/2021 at 12:18. Pushed by ahiemstra into branch 'master'. Properly fix column count and inserting new columns on metadata load Commit 74db33b1 tried to fix this but did this through always creating an instance of SensorInfo. This means we never end up inserting new data in onMetaDataChanged, which breaks the "ready" state of the model and can lead to an invalid value being produced for the "UpdateInterval" model role, which means we end up with incorrect chart update rates. We now use sensorInfos for determining column count and whether or not the model is ready, which should better reflect the state of the model. M +2 -6 sensors/SensorDataModel.cpp https://invent.kde.org/plasma/libksysguard/commit/10d8d20a3bc4016ee271aee234f7727e5640cedc
Git commit b3f7e503276700cd58b685bc1b46f67aad1407df by Arjen Hiemstra. Committed on 02/03/2021 at 09:26. Pushed by ahiemstra into branch 'Plasma/5.21'. Properly fix column count and inserting new columns on metadata load Commit 74db33b1 tried to fix this but did this through always creating an instance of SensorInfo. This means we never end up inserting new data in onMetaDataChanged, which breaks the "ready" state of the model and can lead to an invalid value being produced for the "UpdateInterval" model role, which means we end up with incorrect chart update rates. We now use sensorInfos for determining column count and whether or not the model is ready, which should better reflect the state of the model. (cherry picked from commit 10d8d20a3bc4016ee271aee234f7727e5640cedc) M +2 -6 sensors/SensorDataModel.cpp https://invent.kde.org/plasma/libksysguard/commit/b3f7e503276700cd58b685bc1b46f67aad1407df
The commit 10d8d20a3bc4016ee271aee234f7727e5640cedc causes a crash in SensorDataModel::onMetaDataChanged during this call beginInsertColumns(QModelIndex{}, column, column); column is calculated using auto column = d->sensors.indexOf(sensorId); but since your commit removed this code for (const auto& sensor : sensors) { sensorInfos[sensor] = KSysGuard::SensorInfo(); } the size of sensors and sensorInfos are not in sync for certain amount of time. This is backtrace: [08:07:24.435] unknown: ASSERT: "first <= columnCount(parent)" in file /var/tmpfs/portage/dev-qt/qtcore-5.15.2-r2/work/qtbase-everywhere-src-5.15.2/src/corelib/itemmodels/qabstractitemmodel.cpp, line 3062 Thread 1 "plasmashell" received signal SIGABRT, Aborted. 0x00007ffff5399a21 in raise () from /lib64/libc.so.6 (gdb) bt #0 0x00007ffff5399a21 in raise () at /lib64/libc.so.6 #1 0x00007ffff5383536 in abort () at /lib64/libc.so.6 #2 0x00007ffff582da8d in qCleanupFuncinfo(QByteArray) [clone .cold] () at /usr/lib64/libQt5Core.so.5 #3 0x00007ffff582c7f7 in unquote(char const*, char const*) [clone .cold] () at /usr/lib64/libQt5Core.so.5 #4 0x00007ffff584a81e in QAbstractItemModel::beginInsertColumns(QModelIndex const&, int, int) [clone .cold] () at /usr/lib64/libQt5Core.so.5 #5 0x00007fffe9950355 in KSysGuard::SensorDataModel::onMetaDataChanged(QString const&, KSysGuard::SensorInfo const&) () at /usr/lib64/libKSysGuardSensors.so.1 #6 0x00007ffff5a83b5e in void doActivate<false>(QObject*, int, void**) () at /usr/lib64/libQt5Core.so.5 #7 0x00007fffe994c297 in KSysGuard::SensorDaemonInterface::metaDataChanged(QString const&, KSysGuard::SensorInfo const&) () at /usr/lib64/libKSysGuardSensors.so.1 #8 0x00007fffe99655d9 in QtPrivate::QFunctorSlotObject<KSysGuard::SensorDaemonInterface::requestMetaData(QStringList const&)::{lambda(QDBusPendingCallWatcher*)#1}, 1, QtPrivate::List<QDBusPendingCallWatcher*>, void>::impl(int, QtPrivate::QSlotObjectBase*, QObject*, void**, bool*) () at /usr/lib64/libKSysGuardSensors.so.1 #9 0x00007ffff5a83b5e in void doActivate<false>(QObject*, int, void**) () at /usr/lib64/libQt5Core.so.5 #10 0x00007ffff6442ccf in QDBusPendingCallWatcher::finished(QDBusPendingCallWatcher*) () at /usr/lib64/libQt5DBus.so.5 #11 0x00007ffff6442ddb in QDBusPendingCallWatcher::qt_static_metacall(QObject*, QMetaObject::Call, int, void**) () at /usr/lib64/libQt5DBus.so.5 #12 0x00007ffff5a7aaea in QObject::event(QEvent*) () at /usr/lib64/libQt5Core.so.5 #13 0x00007ffff6765bbf in QApplicationPrivate::notify_helper(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5 #14 0x00007ffff676e0c0 in QApplication::notify(QObject*, QEvent*) () at /usr/lib64/libQt5Widgets.so.5 #15 0x00007ffff5a4c2c8 in QCoreApplication::notifyInternal2(QObject*, QEvent*) () at /usr/lib64/libQt5Core.so.5 #16 0x00007ffff5a4f17c in QCoreApplicationPrivate::sendPostedEvents(QObject*, int, QThreadData*) () at /usr/lib64/libQt5Core.so.5 #17 0x00007ffff5aa81e3 in postEventSourceDispatch(_GSource*, int (*)(void*), void*) () at /usr/lib64/libQt5Core.so.5 #18 0x00007ffff3e88ead in g_main_context_dispatch () at /usr/lib64/libglib-2.0.so.0 #19 0x00007ffff3e89130 in g_main_context_iterate.isra () at /usr/lib64/libglib-2.0.so.0 #20 0x00007ffff3e891bf in g_main_context_iteration () at /usr/lib64/libglib-2.0.so.0 #21 0x00007ffff5aa7c2e in QEventDispatcherGlib::processEvents(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #22 0x00007ffff5a4ac0b in QEventLoop::exec(QFlags<QEventLoop::ProcessEventsFlag>) () at /usr/lib64/libQt5Core.so.5 #23 0x00007ffff5a53790 in QCoreApplication::exec() () at /usr/lib64/libQt5Core.so.5 #24 0x00005555555757fa in main ()
maybe, this bug is related to Bug 433954 - plasma systemmonitor widgets do not always update after configuration changes (edit)
reopening w.r.t. comment 5
A possibly relevant merge request was started @ https://invent.kde.org/plasma/libksysguard/-/merge_requests/134
Git commit b64edc573faf5936ea75c72a8442ff1f734a5b05 by Arjen Hiemstra. Committed on 08/03/2021 at 12:49. Pushed by ahiemstra into branch 'master'. SensorDataModel: Do not insert columns that are out of range It may happen that the metadata for a later column arrives before an earlier one. In that case, we call beginInsertColumns with an out of range column index. This was verified to fix the the issue (and it still preserves the correct order) by scrambling the metadata requests in `sensorsChanged()` using std::shuffle and having the autotest still pass. M +6 -0 sensors/SensorDataModel.cpp https://invent.kde.org/plasma/libksysguard/commit/b64edc573faf5936ea75c72a8442ff1f734a5b05
Git commit a5db29c6f0ed0dcd1b375b770d6f318f8e9e174c by Arjen Hiemstra. Committed on 08/03/2021 at 13:41. Pushed by ahiemstra into branch 'Plasma/5.21'. SensorDataModel: Do not insert columns that are out of range It may happen that the metadata for a later column arrives before an earlier one. In that case, we call beginInsertColumns with an out of range column index. This was verified to fix the the issue (and it still preserves the correct order) by scrambling the metadata requests in `sensorsChanged()` using std::shuffle and having the autotest still pass. (cherry picked from commit b64edc573faf5936ea75c72a8442ff1f734a5b05) M +6 -0 sensors/SensorDataModel.cpp https://invent.kde.org/plasma/libksysguard/commit/a5db29c6f0ed0dcd1b375b770d6f318f8e9e174c
*** Bug 433970 has been marked as a duplicate of this bug. ***