Is the livetiming client slower than the livetiming dashboard on race day?

[ArionMiles]

This may or may not be specific to FastF1's implementation of the livetiming client. But I have written a small script to change my room's light colors based on which driver is leading the race during a GP.

I've monkey-patched the code to process the live events as they're received from the SignalR websocket rather than write them to a file. I'm using this mechanism to process in real time (or at least attempt to) every DriverList event that comes and based on whether it contains "Line 1" info, I change my room lights via an API of their own.

The problem is, this works well during Qualifying, as I'm able to receive position change events with same speed as I see it change on livetiming dashboard (formula1.com/en/timing/f1-live).

However, on race day, I am curious why the DriverList events are so slow. I haven't subscribed to any other events except Heartbeat and DriverList so cannot speak for other events but the DriverList is for sure very very delayed on Sundays to the point that it's well behind the video livestream too. And when I have the livetiming dashboard open, I see it updates well ahead of when I receive the message on my script.

Another thing that has happened is that while FastF1 recommends starting livetiming client at least 5mins before the event, I've had my script crash (due to timeouts as my machine accidentally goes to sleep) and I've had to restart the script. I'm curious if that interruption is also to be blamed but not sure how exactly that would work.

Another possible cause I'm suspecting may be that livetiming dashboard uses some kind of authenticated websocket which has a faster datastream compared to the unauthenticated datastream FastF1 uses, however I've not been able to confirm this suspicion.

[theOehrly]

Hi, this is most likely some kind of processing overhead. Either in the live timing client itself or in the code that you have patched in.

Another possible cause I'm suspecting may be that livetiming dashboard uses some kind of authenticated websocket which has a faster datastream compared to the unauthenticated datastream FastF1 uses, however I've not been able to confirm this suspicion.

That is most likely not the case, I'm pretty sure about that. There shouldn't be an intentional artificial delay here.

Another thing that has happened is that while FastF1 recommends starting livetiming client at least 5mins before the event, I've had my script crash (due to timeouts as my machine accidentally goes to sleep) and I've had to restart the script. I'm curious if that interruption is also to be blamed but not sure how exactly that would work.

You can try starting it closer to the start of the race. This suggestion is just from personal experience and to ensure a complete recording including track and session status messages that may come slightly before the start of the session.

[theOehrly]

@ArionMiles do you know MultiViewer (https://multiviewer.app)? It's a thrid-party application for watching F1 TV (if you have an F1 TV subscription). The application itself also has an API where it provides access to the telemetry and timing data, synchronized with the video stream. So you might prefer to use that API if you can use MultiViewer.
You can access the API by opening http://localhost:10101/api/graphql after you have started MultiViewer. You will also find documentation for the API through this endpoint.

[ArionMiles]

That's a neat idea @theOehrly I'll look into MultiViewer!

[ArionMiles]

I have found both the fastf1 livetiming client and the livetiming data on multiviewer's graphql to have equal delay. And surprisingly the MultiViewer livetiming dashboard had the correct driver positions before the DriverList event arrived with the new leader.

I also don't think it's a processing overhead given I saw the DriverList data arrive at the same time in both APIs and also the fact that it works really well during Qualifying.

I think that the logic for determining positions is more involved than just relying on the DriverList event. I will try digging into the multiveiwer's implementation.

[ArionMiles]

I just confirmed on the MultiViewer Discord that the DriverList event actually updates really slow. I need to use DriverList in combination with TimingData to calculate the race leaders.

[theOehrly]

I just confirmed on the MultiViewer Discord that the DriverList event actually updates really slow. I need to use DriverList in combination with TimingData to calculate the race leaders.

Ahh you found a live timing api special then. Can't say I'm surprised. There's a few things that go against any reasonable assumption. For example that I need to keep two separate lap counters in the timing data parser additionally to the lap count that is provided in the data itself 🙄