starlink-grpc-tools: IndexError: list index (nnn) out of range (3155b85a fw)
Just started seeing this this morning … not sure what’s going on yet, might’ve started with a fw update, since it started ~3:51am, local time.
starlink-grpc-tools | current counter: 23098
starlink-grpc-tools | All samples: 900
starlink-grpc-tools | Valid samples: 900
starlink-grpc-tools | Traceback (most recent call last):
starlink-grpc-tools | File "/app/dish_grpc_influx.py", line 330, in <module>
starlink-grpc-tools | main()
starlink-grpc-tools | File "/app/dish_grpc_influx.py", line 311, in main
starlink-grpc-tools | rc = loop_body(opts, gstate)
starlink-grpc-tools | File "/app/dish_grpc_influx.py", line 254, in loop_body
starlink-grpc-tools | rc = dish_common.get_data(opts, gstate, cb_add_item, cb_add_sequence, add_bulk=cb_add_bulk)
starlink-grpc-tools | File "/app/dish_common.py", line 200, in get_data
starlink-grpc-tools | rc = get_history_stats(opts, gstate, add_item, add_sequence)
starlink-grpc-tools | File "/app/dish_common.py", line 296, in get_history_stats
starlink-grpc-tools | groups = starlink_grpc.history_stats(parse_samples,
starlink-grpc-tools | File "/app/starlink_grpc.py", line 968, in history_stats
starlink-grpc-tools | if not history.scheduled[i]:
starlink-grpc-tools | IndexError: list index (598) out of range
Using the latest docker image.
Looking back at the data captured before the update, and I see it was on a different fw (ee5aa15c). What kind of diagnostics should I provide to help?
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 19 (8 by maintainers)
Anyway, now that the docker image that the README file references has been updated, I’m going to close this issue out.
If we want to revise how the docker image gets updated or where it gets hosted in the future, we can discus that elsewhere.
Regarding the currently_obstructed item in the status mode group: It does appear to be reported in the grpc service when there are obstructions.
I had expected it to either not work at all or correlate very closely with state being set to “OBSTRUCTED”, but the actual behavior is a bit more complex than that. There is some heavy overlap, especially for longer runs of outages blamed on obstruction, but I see shorter runs where only one or the other is the case, but not both. I’m not really sure which is more indicative of actual obstructions, so I guess it makes sense to keep them both reporting as-is.
I believe the range is 0.0 to 1.0, so your 0.00009809 would be about 0.01%, which is really good! Mine’s usually a bit higher than that at around 0.1% after it learns where the obstructions are.
I re-added state yesterday in change 3dddd95ff30e13fd45b8f8fde44925786a261ddb because I found a substitute source for that information. It’s not exactly the same as it was before, as there are a few additional possible state values. See the doc string at the top of starlink_grpc.py for the full list.
Yes, those should be in the status mode group as fraction_obstructed and seconds_obstructed. However, now that I’m looking at it, I see that the last_24h_obstructed_s field of the status response message (from which seconds_obstructed is taken) is marked deprecated, too, and I don’t see it populated in the message. I’m not surprised, as this field was always a bit dubious. It’s possible I just don’t have any obstructions reported recently, but I doubt it.
There is also currently_obstructed in the status mode group, but I’m not sure the field in the grpc message that uses is being populated, either. It’s not marked deprecated, but it used to be just the current value of the corresponding history field, which is no longer present, and I only ever see it reported as default value (False). I don’t have obstructions very often these days, though, so it may just be that I never have them when I pull status. There’s actually a different way this could be computed, though, so I will probably cook up a polling test to verify.
Finally, there are obstruction_duration and obstruction_interval in the status mode group, which were added somewhat recently to convey the “prolonged outage” estimates that appear in the mobile app. However, the scripts only output them if they are marked “valid” in the grpc message (otherwise they are emitted as an empty field). I’ve never seen it marked valid on my dish, so I don’t know if I made that logic too strict, or I just don’t have enough obstructions on my dish these days for the dish to judge them “prolonged”.
As I mentioned in issue #32, the history data does include data in a different form that could be used to re-add some of the ping_drop items, specifically total_obstructed_ping_drop and total_unscheduled_ping_drop, but I will probably only do that if there is sufficient interest.
Kind of a mess, I know, but as you said, the joys of undocumented APIs…
For all items, see the documentation at the top of starlink_grpc.py for the description of what each means (to the best of my knowledge).
Just checked in, I will update the container build within 24 hrs. Cheers!
EDIT: Bumped it, hub should rebuild it soon. @sparky8512 added you to my fork as collaborator.