A couple of random ideas based on my today's experience at AutoX:
1) I tried to use "Resolve" while still recording a session (by reviewing my latest run), and I don't think it worked
2) I left the session, opened the summary, tried "Resolve"ing again, and the app crashed
3) I reopened the app, tried "Resolve"ing again, and it took a few seconds. The app felt frozen. Might be useful to show a progress UI.
4) I realized that every time I sync my CAN data to my GPS data, it calculates the exact same offset.
(It's actually pretty impressive that it's so stable.)
I think it would be super useful to be able to add a button like "apply this offset to this device for this session, and all future sessions". Then I won't need to re-sync every session or resume.
Comments
Just want to bring your attention to the feature request #4 here, it's different from the bug.
Another option would be to add an option (on by default?) to not only apply the offset to all the recorded data in a session, but also apply the same offset to all future resumes.
Basically, if I record some data in the first track session of the morning, and fix the timing of my CAN data, I want all the other track sessions (i.e. "session resumes" in RC) to inherit the same offset. Whether that offset is per day (RC session) or global is secondary.
When using the delay adjustment UI, I'm confused by the top selector.
For example, now when I'm trying to sync my data, it's asking me to choose between "Session resume 4" and "Whole session". Intuitively, the first choice will let me sync only the data after Session resume 4 and until the next time I stopped recording; while the second choice means it will adjust all the data in the whole session (across multiple stops/resumes).
I *always* choose the "whole session" option, and it always works as if it only adjusted one segment between a resume and a stop.
Either the UI is so confusing that I don't understand what it means, or there is some bug in the code.
I easily reproduce this on every single session from my last few track days, and just ran into the same issue on my girlfriend's phone with her track data.
Assuming you use some correlation-based analysis, I'm pretty sure there's a way to correlate the spectrum of sound of an internal combustion engine with the RPM data channel. You don't even need to analyze the whole video, probably just a 1 minute snippet will be unique enough, assuming the car is being driven, rather that just sits idle.
The audio/RPM sync is something I've already thought about.
Do you have crash reporting and analytics set up for the app in Play Store? Any chance this is a native crash?
For C++ code, have you tried AddressSanitizer? (shameless plug: I was on the team that built ASan )
If that's your's, it doesn't tell me too much, other than it's an ANR (application not responding) not a true crash. Probably caused by an mutex issue and the UI thread is blocking. I will investigate.
Anyhow, did the crash report reveal what the problem is?
That particular ANR doesn't give any clue why it got stuck.
It is now fixed for the next beta.
I'm pretty sure there's still some ANR problem left with larger sessions, but let's see if this helps at all. It should, but the one I fixed may not be the only problem.
I still have the usability issues, "whole session" and "make default for this device" on my TO-DO, but those have to wait little bit longer.
Yay, glad to hear you found and fixed at least one problem!