I'm creating a live scores application for Rugy League. It shows scores in real-time as a match is taking place. In Rugby League the match clock can be paused at any point during the match (similar to Basketball).

I'm having trouble accurately syncing the time representation of a match in my app with the actual match time obtained from a live feed.


When a match is taking place I retrieve data from a live feed every 5 seconds. This feed contains up-to-date information like the match time, scores etc.

In my app, I start an internal match clock during a live match. The reason for this is to show time ticking to the user (00:01....00:02...00:03). This internal match clock keeps ticking but is updated every time I get new information from the live feed. The internal match clock can sometimes be ahead/behind the actual match time and in these cases it is corrected to reflect the actual match time.


The internal match clock jumps back and forth every now and then when in it has to correct itself based on the data from the live feed.

So the internal match clock can be inaccurate by roughly 10 seconds or even more depending on network failure or other factors.

My issue with this implementation is the inaccuracy of the internal match clock (in the app). Ideally it would "jump" less and be in sync with the live event.

So, if you've ever had to do something like this, the question is, how have you synced your app with live sporting events when time accuracy is an important factor?

Open to any techniques/concepts you can share.

  • I don't really see how you can do this unless your program listens out for the whistle and interprets the ref's intentions. Commented Mar 17, 2016 at 2:46
  • @BarryTheHatchet knowing what regions of the image captured from the live feed can cut down the amount of area you would have to scan so you could quickly determine what the score is, time left, etc. Smaller data to scan also means faster results. The downside is when the broadcaster changes where everything is located. Commented Mar 17, 2016 at 4:38

2 Answers 2


The only real solution to this problem is to push the information instead of pulling it.

The only real problem is how much resources it would take on server. To maintain all current clients and sent an update multiple times per second takes lots of CPU and memory and scales much worse with number of clients than pulling the information. You could try utilizing some form of broadcast, but I'm skeptical about such solution existing.

So it comes down to cost/performance : Is it really worth it to invest such big amount of resources into fixing the stuttering of time in your app?

  • Yeah I see where you're coming from. I don't think the stuttering time is a massive deal. I was just curious what people have done when faced with similar issues. Thanks for the suggestions!
    – Zee Zali
    Commented Mar 17, 2016 at 10:13
  • I don't see why you'd have to send updates several times per second. That would be only necessary if the ticking/paused mode changes that often. I'd expect the push solution to be cheaper than the pull solution, since you only need to send a message when something changes. Commented Mar 17, 2016 at 11:29
  • @CodesInChaos True. But still, maintaining a permanent connection to every client is quite expensive.
    – Euphoric
    Commented Mar 17, 2016 at 11:44

If you need more accuracy, shorten the interval between screen captures.

Going from a 5 second refresh to 2 seconds would give 2.5 times more accuracy in the data you are displaying.

Also given the processing speed of most modern machines, you should be able to handle that frequency easily.

  • Thanks for the suggestion. I was thinking that 5 seconds was already too much polling, but the accuracy case you make with shortened intervals makes perfect sense.
    – Zee Zali
    Commented Mar 17, 2016 at 4:40
  • To cut down on the polling of your server, you could send out the scores via UDP instead of TCP. Commented Mar 17, 2016 at 4:44

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.