The lost samples is due to full cpu load, my suggestion would be to try lower sample rates. To find which ones are supported check this guide.
The initial concept about failing an observation when audio duration has a “big” difference from the scheduled duration, was that in this way we can spot if something goes wrong with the station and the flowgraph that it runs. To be honest this has revealed some issues and I think it led to some fixes, so station can perform better.
However low duration doesn’t always mean 100% failed observation, so this is why you have the ability to vet the waterfall if there is signal or not. If there is, like in the case of the observation you linked, then the observations status changes to good.
If there isn’t then the “no signal” in waterfall, it can be 2 things, either that satellite wasn’t received or that station has issues, so in this case we chose the observation status to remain “failed”. There is a hack to turn the observation to be “bad” by vetting it first as good and then as bad but I don’t suggest it.
By the way to find all the observations that don’t have their waterfall rated you can use the “Rated Artifacts” filter in observations page, for example these are the good and failed observations without rated waterfall.
These vetting changes weren’t complete but it was a first step for moving forward to a better process that will be more useful. Unfortunately other tasks got in the middle and the change hasn’t been completed but it is high in the priority list, so stay tuned.