I have a background in network engineering and system troubleshooting.
First off I personally don’t have any problems with the desktop app on Windows 10+11 and MacOS 12.4 (Intel+M1). I don’t have Linux GUI I run cli or docker on real systems but thats an other story… I did my tests on SSD and HDD both internal and external.
Software versions used: v0.6.3, v0.6.5 and v0.6.7
Here is my feedback/complains:
The APP on all OS’s can’t be resized. Really annoying…
Sometimes on first startup after fresh install the app crashes, there is no explenation for it and can’t find anything related to it crashing. happened 2 times on both windows and mac out of 20+ clean installs.
After initial plotting is done the app stops accuratly displaying the sync status and blocknumber. Restarting the app solves this.
Voting rewards are not displayed, I know this is worked on but still… Its annoying.
I don’t get why we can’t specify a seperate path for the node and farmer. You want the node on fast SSD and the farmer on the slower HDD…
Syncing+plotting on a external HDD is not fun and I had a lot of trouble syncing and had to restart app multiple times all due to either farmer or node crashing. I Think my USB HDD bay is at fault here and the controller just can’t keep up… Internal HDD works but is slow, all other test went smooth so system is fine.
Installing app on drive you want to use solves gui not correctly displaying the space you are able to plot during setup…
I think the settings menu could also get a rework, I made a sample for you guys to concider.
#3 has been even worse for me. It was buggy and all over the place. #6 I’m surprised you were able to at all #7 I was able to manually adjust the value in the config file to increase it. I read elsewhere that this should not be possible, but it did plot the size I specified, so I don’t know.
Also, the version number does not update in the config when you upgrade the GUI client. Not sure if this is by design or not.
Hello!
That’s really valuable feedback. Let me address each of them: #1 → I will open an issue about this, and we can keep track of it. I agree, that’s one of the next steps #2 → weird… Never happened to me, or did not heard something like this. When that happens, can you please the LOG file next time? I’m curious about this one #3 → fixed in 0.6.8 and upcoming 0.6.9. Users will be able to see highest block number in the dashboard. I think that will resolve that issue #4 → yes #5 → I agree. However, node will become lighter and lighter with each update. So this problem will get solved on its own. #6 → This applies to monorepo actually. Not really related to Desktop. So we can discuss this in another topic if you like with Nazar also included. #7 → This is fixed in 0.6.8!!! We are testing the version to make it stable at the moment
#1. I think you’ll make a lot of desktop users very happy #2. Happened On 2 (win10 and Mac on intel proc) out of 4 systems and only first startup after initial installation. The app just quits… nothing in the official desktop log, it just stops… also nothing I can find in either win or macos system logs… maybe you could point me as of where to look? #3. The node becoming lighter is a bonus, that does not fix that fact that a more advanced desktop user wants to choose where they keep the data associated with either node or farmer. #6. I personally don’t even want to do this, just tried it to see what other users would experience…
Keep on coding, you guys are actually doing a great job and bug fixing is on point if you ask me…
Sorry, yesterday I crossed the point at which I maxed out the amount of time I was willing to wrangle with this, and deleted everything.
In any event, the logs don’t get rotated by the GUI and are replaced with each run, so the only thing I would have had to share is the config file (with the outdated version number).
The recent versions of the installer in the downloads dir on that machine are 0.6.3, 0.6.6, 0.6.7, if that helps.
A datapoint on app not starting (as opposed to crashing, so won’t help you @ozgun):
The CLI version won’t start on a fresh install of Windows Server 2019 because of missing runtimes (obtainable here Latest supported Visual C++ Redistributable downloads | Microsoft Docs). I can’t remember if that’s also the case with the desktop client.
[IMO] You shouldn’t assume everyone has the necessary runtimes installed. If there is a requirement that’s not part of the OS, it should be noted in the docs and on github, even if most people are likely to have the dependency installed as a result of it being a dep shared by other commonly installed software.
but thats an other story… I did my tests on SSD and HDD both internal and external.
