Total network upload/download values over 4 GB not displayed correctly.

[ppgrainbow]

I'm new to reporting issues involving the latest release of LCD Smartie. :)

I've been using LCDSmartie for more than 6 years now and I have never experienced too much a problem with the system monitoring utility.

I have a issue with the total download and upload values being calculated on my Realtek PCIe GBE network adapter...the total download and upload wrap around 4 GB when LCD Smartie is closed. However, it doesn't happen when LCD Smartie is running.

Here's a screenshot of the issue:

I'm currently running LCD Smartie 5.6.0.1 on Windows 10 22H2.

Here is the screencap of the code that was used to generate the information:

And lastly, here is the correct stats of how much data is being uploaded or downloaded after startup from the Network Meter widget as a part of the Gadgets Rainmeter skin:

(The internet and external IP addresses are blacked out for privacy reasons.)

Looking at the UDataNetwork.pas starting on line 187 the total network upload and download values have a limit of 4 GB - 1 byte to prevent overflows. I'm wondering if MAXDWORD has anything to do with the 2 ^ 32 - 1 limit to store total download and upload values after reboot.

Let's hope that this bug gets looked into and fixed. I'm suggesting to either find a way to (A) use 64-bit values to store total network downloads and uploads since reboot or (b) reset the total network upload and download counters to zero when LCDSmartie is restarted.

[stokie-ant]

I'm not sure if I'm reading you right. Are you saying that the counter is failing to count properly during runtime or, is it because it's discarding the total and starting again from the current value when the program is re-started?

The 4Gb roll over is an os limit. If MS had made the field larger we wouldn't have this issue. I think rainmeter stores the count across program restarts but I can see how this may cause additional headache on how it should be handled. I think your option (b) might be the best here. Although I'd have to figure out how to implement that while also tracking the OS roll over

[ppgrainbow]

I'm not sure if I'm reading you right. Are you saying that the counter is failing to count properly during runtime or, is it because it's discarding the total and starting again from the current value when the program is re-started?

The 4Gb roll over is an os limit. If MS had made the field larger we wouldn't have this issue. I think rainmeter stores the count across program restarts but I can see how this may cause additional headache on how it should be handled. I think your option (b) might be the best here. Although I'd have to figure out how to implement that while also tracking the OS roll over

The counter is failing to count beyond the 4 GB OS rollover which is indeed the OS limit. More specifically, if more than 4 GB of upload and/or download data is registered and if you close and restart LCDSMartie, the total counters during runtime rollsover within the 4 GB limit.

As shown in the screenshot, the total download counter was supposed to read 8,976.9 MB, but because of the rollover, it reads 784.9 MB instead.

As for option B, I agree that resetting the total network upload/download counters would be the best option. Would resetting the upload/download counters to zero also affect upload and download counters for unicast and non-unicast packets well?

[ChlorideCull]

On Vista and later LCDSmartie can use the GetIfTable2 function instead of GetIfTable, which returns essentially the same information except using ULONG64 for counters. That version rolls around at 18446 petabyte.

If loaded dynamically when available, it should work even without dropping support for XP :)

[stokie-ant]

On Vista and later LCDSmartie can use the GetIfTable2 function instead of GetIfTable, which returns essentially the same information except using ULONG64 for counters. That version rolls around at 18446 petabyte.

If loaded dynamically when available, it should work even without dropping support for XP :)

I've just done this. Needs testing but looks good

[ppgrainbow]

On Vista and later LCDSmartie can use the GetIfTable2 function instead of GetIfTable, which returns essentially the same information except using ULONG64 for counters. That version rolls around at 18446 petabyte. If loaded dynamically when available, it should work even without dropping support for XP :)

I've just done this. Needs testing but looks good

It looks good! With the GetIfTable2 function and counters rolling over at 16 exabytes, I won't have to worry about this issue. :)

Let me know if you have the updated build of LCD Smartie that corrects this issue. ^_^