Battery percentage differs from Synapse 4

[kristianpennacchia]

Hello,

First, thanks for this app, it's exactly what I was looking for.

I've noticed an issue where the battery percentage displayed by your app is different to what Synapse 4 is displaying. You can see this in the attached screenshot.

I looked at the systray_systrayv2.log and the systray_systrayv21.log and it looks like the latter (v21) is reporting the same battery percentage that Synapse 4 is displaying, while the former (v2) is reporting the incorrect battery percentage that your app is displaying.

So, I assume the fix is to just read the battery percentage from systray_systrayv21.log instead. Or maybe provide a setting to choose which log file to read I guess. I don't know why there are two log files to be honest.

I've made a copy of the log files but I think it has private information in it.

[sanraith]

Hey, Is the battery display still being updated on the app, or is it stuck on 63%? I rolled back to Synapse V3 on my machine so I can only check it later myself.

One thing I noticed in V3 logs is that different Synapse components seemed to be in a disagreement about the exact percentage sometimes. Since they were converging I just picked one of the sources. So if your percentage is still being updated it might be a similar case in V4.

[kristianpennacchia]

Looks like Synapse 4 battery level has updated to 48% but your app still says 63%

[sanraith]

Thanks for checking, time for a patch then

[sanraith]

I tried it, but there was no systray_systrayv21.log file generated for me. Since settings.log has the same data, I updated the watcher to use that for now. Let me know if that works: https://github.com/sanraith/razer-taskbar/releases/tag/v0.10.1

[kristianpennacchia]

Unfortunately the settings.log file doesn't seem to have information about my mouse in it, so your app was saying it couldn't find a device.

I experimented a bit with deleting the log files and restarting Synapse 4, and Synapse automatically recreated systray_systrayv2.log and is now correctly updating that log file, so the previous version of your app (v0.10.0) is now working.

I still worry that the log file naming issue can occur in the future again or for other users, as it looks like Synapse just seems to abandon log files and create newer versions of them for whatever reason. I can see this same issue has also happened with remote-sync-worker.log where Synapse created 3 versions of this file remote-sync-worker.log, remote-sync-worker1.log and remote-sync-worker2.log

The good news is that the naming appears to be consistent, so a solution could be to go back to using systray_systrayv2.log but find the version of this log file that has the largest trailing number. So if systray_systrayv21.log exists where 1 is the largest trailing number, use that instead, or if systray_systrayv299.log exists where 99 is the largest trailing number, use that instead.

[sanraith]

I am not sure if the file with the larger index is (always) the correct one. By looking at my product_*.log files, they look like they are being written simultaneously rather then _3 being a continuation of _2. Even on your screenshot lighting_engine3.log is updated later than lighting_engine4.log according to Windows.

Not that the 'Date Modified' is accurate since Synapse 4 keeps these files open, hence the reason I am using a polling file watcher for V4. I think the 'safest' implementation would be to watch all the systray logs and use the timestamps from inside, but that could open another can of worms parsing regional date formats...

For now, I might just go with the solution you suggested and see it from there.

[sanraith]

Added the suggested fix in v0.10.2

[kristianpennacchia]

Thanks, the latest update has been working great for me!

[sanraith]

In the previous version I somehow ended up reverting back to the incorrect regex, so v0.10.2 did not actually fix this. I found out by getting dupliucate log entries today myself. v0.10.3 fixes it for real.