feat: Adding UnattendedMode setting to enable auto-continue on ErrorView.

[ScottFries]

I'm making some of my family digital photo frames and need them to be as hands-off as possible since most of them are not very tech-savy. This mode allows me to silently handle issues such as the Immich server going down (which causes an exception on 404s) and other spurious exceptions without having to get a call from them :) Figured this will probably be helpful for others as well.

[ScottFries]

I think I get what you are doing, but it seems unnecessarily complicated. If your settings are good, but it is just getting errors trying to load the next image (internet issue, server down, etc), wouldn't something simple like this do it in MainViewModel ShowNextImage() catch block: catch (Exception ex) { attempt++; if (attempt >= 3) { if (Settings.UnattendedMode) { await Task.Delay(30000); } else { this._viewModel.Navigate(new ErrorViewModel(ex)); } } }

Hmm, yes that would work and be much more straightforward so long as the setting also makes it an infinite attempt rather than happening inside of the attempt loop. Added benefit of that is that if something goes wrong then the last displayed image will just stay up indefinitely until the server responds healthy.

[3rob3]

Actually you’d have to disable the next image timer, delay, then re-enable the timer. Then yes it should keep the current image, wait 30 seconds, continue. If it’s successful it keeps on, otherwise it will hit the catch again and repeat.

[ScottFries]

Actually you’d have to disable the next image timer, delay, then re-enable the timer. Then yes it should keep the current image, wait 30 seconds, continue. If it’s successful it keeps on, otherwise it will hit the catch again and repeat.

Good point, though I'm not sure that's a particularly useful/necessary disable/idle/reenable loop in this case. With how I've got it setup now, my understanding is that if the next image fails to load (for whatever reason) we'll silently sit on the previously successful image and wait for the next image attempt naturally. Yes, we end up "missing" any images that would have been displayed between the previously-successful and the newly-successful images, but in an Unattended case where we're just displaying randomized images anyway that doesn't really impact anything.

[JW-CH]

Thank you for your change, just went over your code with one eye. Just wanted to quickly tune in...

Can you also add the new setting to the Settings.example.json? Also, a toggle-switch in the Settings-Page would be great.

[3rob3]

Actually you’d have to disable the next image timer, delay, then re-enable the timer. Then yes it should keep the current image, wait 30 seconds, continue. If it’s successful it keeps on, otherwise it will hit the catch again and repeat.

Good point, though I'm not sure that's a particularly useful/necessary disable/idle/reenable loop in this case. With how I've got it setup now, my understanding is that if the next image fails to load (for whatever reason) we'll silently sit on the previously successful image and wait for the next image attempt naturally. Yes, we end up "missing" any images that would have been displayed between the previously-successful and the newly-successful images, but in an Unattended case where we're just displaying randomized images anyway that doesn't really impact anything.

You originally had a 30 second delay (which I thought made sense), so the timer disable/enable was necessary. How you have it now with just the break also works it just will hit more often but who cares really, it will recover faster :). Also cleaner.

[ScottFries]

Thank you for your change, just went over your code with one eye. Just wanted to quickly tune in...

Can you also add the new setting to the Settings.example.json? Also, a toggle-switch in the Settings-Page would be great.

Good catch! Fill follow up with that shortly.

[ScottFries]

Actually you’d have to disable the next image timer, delay, then re-enable the timer. Then yes it should keep the current image, wait 30 seconds, continue. If it’s successful it keeps on, otherwise it will hit the catch again and repeat.

Good point, though I'm not sure that's a particularly useful/necessary disable/idle/reenable loop in this case. With how I've got it setup now, my understanding is that if the next image fails to load (for whatever reason) we'll silently sit on the previously successful image and wait for the next image attempt naturally. Yes, we end up "missing" any images that would have been displayed between the previously-successful and the newly-successful images, but in an Unattended case where we're just displaying randomized images anyway that doesn't really impact anything.

You originally had a 30 second delay (which I thought made sense), so the timer disable/enable was necessary. How you have it now with just the break also works it just will hit more often but who cares really, it will recover faster :). Also cleaner.

Ya, the original 30s delay was because when handling this in the ErrorView no delay meant we repeatedly transitioned to the ErrorView causing a strobe effect on the screen. The delay meant less invisible spam on the unhealthy server, but more importantly less seizures!

[ScottFries]

Thank you for your change, just went over your code with one eye. Just wanted to quickly tune in... Can you also add the new setting to the Settings.example.json? Also, a toggle-switch in the Settings-Page would be great.

Good catch! Fill follow up with that shortly.

Ah @3rob3 beat me to it! Thanks!

[3rob3]

Yeah, wanted to pull it but also needed those changes. Hope you don't mind! Thanks for contributing.

[3rob3]

Do you think the Settings GUI needs a brief description? I just put "UnattendedMode", but thinking maybe "UnattendedMode (suppress errors/less user input)"

[ScottFries]

Yeah, wanted to pull it but also needed those changes. Hope you don't mind! Thanks for contributing.

Never gonna complain about help!

[ScottFries]

Do you think the Settings GUI needs a brief description? I just put "UnattendedMode", but thinking maybe "UnattendedMode (suppress errors/less user input)"

Ya, that'd make sense. I'm not sure what else this may be expanded to in the future, but it can of course be applied to avoid gating on user input wherever necessary and should probably reflect that in any tooltips/other explanations.