Suggestion for a temporary beta-crash relief/"workaround"
Hi. Here on the forum, I saw a user say that when they flew their Mini 3/Mini 3 Pro, they would pause the flight often, in order to more easily continue the mission after app crashes. Today I tried that, and it definitely helped the overall experience, because the drone will start from the latest pause point as opposed to from the beginning of e.g. the last waypoint sequence.
My suggestion: since there's clearly some sort of "checkpoint" that takes place when the user pauses a mission, is there anything that prevents this checkpoint from taking place e.g. even every second? It usually only takes me a few seconds to get back into the app, so if the Dronelink was constantly saving the current progress during the mission, then it wouldn't be as frustrating as it can currently be. This would obviously only be a temporary "solution" until the bug hunting work with DJI bears fruit.
So to summarize: my suggestion is to save mission progress constantly (at least when flying with the Mini 3/Mini 3 Pro) — maybe simply using the progress saving that occurs when the users pauses. That way it would be a much less frustrating experience while the app crash bug exists.
Additionally, this would lead more beta testers to increase their flight time, and thus create more beta testing data points for the development team.
Comments
8 comments
The current save rate of 60s was chosen for performance considerations (serializing the entire mission state is a heavy operation, especially for older / slower devices).
Any chance of making that 60s a user changeable variable in Jim mode?
Even with the occasional app crashes Dronelink is very useful to me professionally. But I've taken to using the hacky method of pressing the pause button frequently to get the resume point to update. The unintended consequence of using the pause button is that the drone gimbals up, has to fly back a few meters, etc.
Having a more frequent save rate would be a lot less hacky than using the pause button.
its beta software its going to be buggy, the idea of being on a beta program is help find the bugs, not try to get round them with hacks
I'm saying I don't want to use hacks but have resorted to it. Having a more frequent save rate would eliminate the hack.
what I'm saying is if you are going to resort to hacks you shouldn't be using beta software, as it doesn't actually help solve any problems
I gotta say, I'm tired of this. From the beta test webpage:
I think this describes me well. An advanced user that's interested in testing and providing feedback. And then every time I do provide feedback I get told some variation of "maybe you shouldn't be in the beta test" as a response.
I have zero demands of the beta, no entitlement to performance guarantees. I'm even paying to be a tester! So maybe the response to feedback should simply be "thank you for the feedback, we will consider your suggestion" or "thank you for the feedback, we aren't going to consider your suggestion because..."
@Martin Reading
It's interesting, in every beta program I've ever been in, there's always one or two of what we could call "Beta Stans". The Beta Stan feels the need to invite themselves into every single discussion, in order to argue the opposite of whatever is being said. If the poster says "blue", the Beta Stan will — without hesitation — say "yellow". Yet, if the poster says "yellow", the Beta Stan will immediately say "blue".
We can do a meta-recreation of a Beta Stan interaction:
Regular beta tester:
"[Literally provides beta feedback]"
Beta Stan: "It's a beta! The developer is doing their best"
Regular beta tester:
"I know it's a beta; that's why I'm providing my feedback and suggestions. That's my job as a beta tester. And I know that the devs are doing their best. That's why I'm even offering my limited free time providing beta feedback — because I believe in the product and want it to be the best it can be."
Beta Stan: "[Doesn't actually listen to the point but basically says] well you're wrong, and you shouldn't attack the devs like this!".
As we see in this recreation, the Beta Stan suffers from a White Knight complex, where they feel an imagined need to "protect " the devs from what they perceive as attacks against the devs, i.e. literally everything any other beta tester says.
As a sidenote, the devs never ask the Beta Stans to be this White Knight, and it's always interesting to see what the devs do about it, because it's pretty awkward.
Anyways, I would kindly ask you to skip the feedback threads that I post in the future, as I'm not interested in "discussing" it with an unrelated person who always shows up just to be Mr Opposite. Please. I'm doing my job as beta tester by providing my feedback, and I put time and effort into ensuring that I have given it a proper thought, whereas the Beta Stan provides their protector-counterargument with very little effort or due diligence. For example in this case, my original suggestion is literally about potentially increasing overall beta testing use, and thus could increase net beta feedback, but you skip completely past that and, without even realizing it, argue that increasing beta use would somehow be detrimental to the beta program — which obviously makes no sense! You can't beta test something if you can even use it at least a little bit!
Anyway, I said that I didn't want to "discuss" it with you, so I'll stop it there, and I hope you will respect my wish for you to skip my thread, and hangout somewhere else.
________________
Back to the feedback itself:
I will definitely join Matt T in wishing that the save rate might become user adjustable (at least for the beta), because it really really does improve the experience, and thus increase usage, when you can immediately resume the mission after an app crash. In fact, even the production version of any software can crash.
So it might be worth investigating. But then again, as always, I know I might be wrong, and that it might have other negative consequences. Or maybe it won't?
I think the idea has merit, but in general we do prefer to spend our time on actually fixing the bugs as opposed to working around them. In this case, given the duration of this beta and how difficult this bug is proving to be, we might actually consider doing this but if we do, it probably won’t be right away.
As for Martin’s comments, I think the most charitible interpretation is he is pretty sensitive because of the volume of posts in other threads from other “beta” users that aren’t really beta users at all, but rather “normal” users that are just desperate to get pre-release access to functionality for the Mini 3 and have no idea what they are getting themselves into, ignore all the warnings, and then complain about it. And trust me, there are quite a few of these people, sadly.
Regardless, we appreciate all of your feedback and are grateful for your efforts in helping.
Please sign in to leave a comment.