This gets me every time.
I see this dialog box:
and click on the “Try Now” button because I’m blind and don’t see the giant “Running” and “00:00:00”. Nothing happens and I curse to myself. THEN I realize Recovery Mode is already running.
Can the “Try Now” button be hidden when it doesn’t apply, like when Recovery Mode is running?
It would be really cool if the “00:00:00” was hidden as well when Recovery Mode was running, so it’s super obvious it’s running.
Eric C
This button is weird because it doesn’t cause an explicit action… it just sets a state flag indicating that it is OK to proceed with the next attempt. Clicking multiple times has no undesirable effect.
That said, I agree it is confusing. I hesitate to disable it… due to its nature I fear that without a deeper analysis we could get into a state where the button never becomes re-enabled. As a compromise, it will now show a message indicating that a retry has already been requested.
@Ken,
Thanks for improving it. I agree and understand your concern.
As a fellow software developer (I support the AllskyTeam/allsky: A Raspberry Pi operated allsky camera) software, I’m curious if you’ve ever considered a setting for different “modes”, for example, to limit or increase the amount of logging done, from “minimal” (a subset of what’s currently logged) to “heavy” (a superset).
And/or a mode for “advanced” users that would, for example, hide the “Try Now” button as previously discussed and hide other things an advanced user likely isn’t interested in and show more details that would overwhelm a non-advanced user.
And/or an “experimental” setting that would enable not-fully-tested features, possibly like hiding “Try Now”.
Eric C
We started this and, occasionally you’ll see log level events that are not DEBUG (like ERROR and INFO levels). But after 12+years of SGPro Code snowballing, auditing and classifying the literal thousands of log statements becomes quite the undertaking. Because we’re unlikely to do this all in one fowl swoop, we’re kind of passively classifying them. When we have enough for the log levels to actually produce meaningfully different sets of logs, it would be trivial to add the filter at that point.
The only hesitation I have is that this will likely produce a new scenario where asking for logs has an new extra step in it saying that “the logs you captured are not useful for the kind of troubleshooting we need to do”. This isn’t the first time we’ve grappled with this though and is the big reason that the external notification system contains a file logger. This is much more user friendly in terms of understanding the macro-level sequence of events for a session.
That happens quite often with Allsky but it’s actually not that big of an issue. We often need clarification from the user anyhow so require at least one follow up.
Because Allsky runs on a Raspberry Pi and most have an SD card for a disk, we need to limit writes to the disk so it lasts longer, hence our default log level doesn’t produce much output. That’s not the case with SGP so you could have the default log level be pretty verbose so you wouldn’t need to ask the user to change the log level very often.
There have been several times in my years with SGP where more debugging output would have been useful, and at least a couple of those times you added more. I’d guess there is even more logging you’d like to be able to do but don’t need very often; those cases would be ideal for a “super verbose” log level.
