Plasma-nm applet does not show connection speed neither in the "Speed" tab nor in the applet itself. If I activate the applet right after Plasma startup, in the connection item in the "Active connections" part of the applet shows zeroes for speed value, but if I then hide the applet and activate it again, no numbers are shown. If I activate when plasmashell seems to be loaded completely, no numbers are shown at all. The "Speed" tab is always empty, all tick marks are equal to "0 B" always. Reproducible: Always Steps to Reproduce: 1. Put plasma-nm apllet in the system tray. 2. Activate it. 3. Make some network activity. Actual Results: The applet does not show connection speed. Expected Results: Connection speed is shown in the applet.
If I remove panel or applet from system tray and add it back, on first applet activation the speed is shown and ticks in the "Speed" tab are initialized. However, no plot is shown. Next applet activations brings up the applet without speed numbers.
Cannot reproduce here, I know I had this problem once like a month ago and ignored it, but since then it is working fine. Try to update to latest Plasma and Frameworks.
I have this problem, once I login I can see the speeds, but after seeing it for the first time it disappears. I am using Fedora 23 with the latest 5.5.1 packages, I have tried on my machine and in a virtual machine I have (for clean environment) and it happens on both. Also on my machine I have deleted .kde and .config recently to have a clean refresh.
Could you please try to add "Network Monitor" applet to your desktop to check whether this one is working? We use same dataengine for getting information so I would like to be sure that the problem is in plasma-nm, altough I haven't changed anything related to our traffic monitor recently.
(In reply to Jan Grulich from comment #4) > Could you please try to add "Network Monitor" applet to your desktop to > check whether this one is working? We use same dataengine for getting > information so I would like to be sure that the problem is in plasma-nm, > altough I haven't changed anything related to our traffic monitor recently. So the problem is on data engine, because Network monitor always stays in 0/0.
When I added a Network Monitor applet to desktop, not only that applet showed me connection speed, but plasma-nm started to do so as well.
After Fedora updates to the qt 5.5.1 and the new KDE Frameworks 5.18.0 the issue disappeared.
*** Bug 357851 has been marked as a duplicate of this bug. ***
I have this problem on all computers (>4) in my company. They are installed fedora 23 and have been updated to plasma 5.5.3. The problem is as Eugene Shalygin and Paulo Fidalgo. If I add the "Network Monitor" applet, the problem disappears. I remember the problem begins from plasma 5.5.0. (In reply to Jan Grulich from comment #4) > Could you please try to add "Network Monitor" applet to your desktop to > check whether this one is working? We use same dataengine for getting > information so I would like to be sure that the problem is in plasma-nm, > altough I haven't changed anything related to our traffic monitor recently.
Still an issue on Archlinux, with KF5 5.18... (cf https://bugs.kde.org/show_bug.cgi?id=357851)
Same here. openSUSE tumbleweed KF5 5.21.
(In reply to Pablo from comment #11) > Same here. openSUSE tumbleweed KF5 5.21. And kubuntu 16.06 live image. KF5 5.18
Created attachment 98731 [details] Kubuntu 16.04, plasma 5.5.5, Qt 5.5.1, KDE Frameworks 5.18 Just to picture the behavior. This happens both with wired or wifi conection. It just dissapears for the active conection.
*** Bug 362824 has been marked as a duplicate of this bug. ***
*** Bug 363097 has been marked as a duplicate of this bug. ***
Same here. openSUSE Leap 42.1 Plasma Framework 5.21 LAN: Realtek 8111C Please, set status to CONFIRMED
I set it to confirmed, but I think nm devs new it already
*** Bug 365605 has been marked as a duplicate of this bug. ***
I'm not seeing this anymore, at least on openSUSE Tumbleweed (plasma 5.7.3, Qt 5.6.1, KDE Frameworks 5.24). Neither on cable nor on wifi (two different PCs).
I just checked on my system (Arch Linux, Plasma 5.7.3). When I opened it for the first time, it showed 0B for about 1-2 seconds and then started showing the traffic graph. However, when I closed the applet and reopened it, it was gone and the graph only showed 0B. So apparently, the issue is not resolved in 5.7.3.
Maybe it's another thing. What version of KDE Frameworks and Qt are installed on your system? and what about NetworkManager version? In mine, for instance, are 5.24; 5.6.1 and 1.0.12, respectively.
KDE Frameworks 5.24, Qt 5.7.0, NetworkManager 1.2.4. As I said, I'm using Arch, so all packages are up to date.
*** Bug 370017 has been marked as a duplicate of this bug. ***
In Mint KDE 18, Plasma 5.6.5 I can confirm when adding Network Monitor nm applet works fine too. After removing Network Manager widget, np applet continues to work fine.
I just tested in 5.8.0 and it always shows 0B.
I too am having the same issue while receiving a streamed movie from a server. Plasma 5.8.0 KF5 5.27 Apps 16.8.1 Gentoo stable amd64
Doesn't work in Plasma 5.8.0 on KDE Neon Dev. Edition (stable). Open the widget for the first time and it shows traffic. Close and reopen and traffic info disappears, and clicking on active network shows "0 B" under speed.
I migrated kubuntu from 14.04 to 16.04 and since then I have the same problem with the network traffic graph. Just now I have uninstalled some packages related with qt4, probably remaining from my previous version. I assume several of them have nothing to do with the problem because they are development packages, but others perhaps are related, I don't know. The last ones are: libibus-qt1, python3-pyqt4, ibus-qt4, python-qt4-dbus
Sorry, I didn't finished my comment: Since the last changes uninstalling the packages the graph is showing correctly.
Im on 17.04 and somethimes still I don't see speed graph in network-manager 1.4.4
Was this bug fixed as stated in this other one: https://bugs.kde.org/show_bug.cgi?id=380209?
*** This bug has been marked as a duplicate of bug 380209 ***