#Popscore - Twitch 24h watched not updating

6 messages · Page 1 of 1 (latest)

radiant knot
#

Hi team — I think there's a stuck data pipeline for popularity_primitives.

Every row with popularity_type=34 ("24hr Hours Watched", Twitch) shares the same calculated_at across the entire endpoint: 1775681980 (2026-04-08 20:59:40 UTC), i.e. ~11 days stale at the time of posting.

All other popularity_type values are refreshed with today's timestamps (1776557071–1776575295, which is 2026-04-19). So it looks like the Twitch ingest job for type 34 hasn't run for ~11 days while the other feeds keep updating.

Repro (IGDB v4 API, 2026-04-19):

POST /v4/popularity_primitives
fields calculated_at; sort calculated_at desc; limit 3;
where popularity_type=<N>;

Result per type (newest calculated_at across the whole table):

type 1 (Visits) → 1776557071 2026-04-19 00:04:31 UTC ✅
type 3 (Playing) → 1776560609 2026-04-19 01:03:29 UTC ✅
type 5 (24hr Peak Players) → 1776575295 2026-04-19 05:08:15 UTC ✅
type 9 (Global Top Sellers) → 1776570314 2026-04-19 03:45:14 UTC ✅
type 34 (24hr Hours Watched) → 1775681980 2026-04-08 20:59:40 UTC ❌

Is that a bug on your side or am I doing something wrong? Brand-new releases (e.g. Pragmata, id 134612, released 2026-04-17) end up with a pre-launch Twitch value because the type 34 snapshot is older than the game's release date. It also skews rankings for every game that leans on streaming, not just new titles. The same result appear on both the API and the partner CSV dumps. Could someone check whether the Twitch ingest cron is stuck? Happy to provide more data if helpful. Thanks!

#

Extra evidence (IGDB v4 API, 2026-04-19):

POST /v4/popularity_primitives/count
where popularity_type=34;
→ { "count": 17800 }

POST /v4/popularity_primitives/count
where popularity_type=34 & calculated_at=1775681980;
→ { "count": 17800 }

POST /v4/popularity_primitives
fields calculated_at; where popularity_type=34;
sort calculated_at asc; limit 1;
→ [{ "calculated_at": 1775681980 }]

POST /v4/popularity_primitives
fields calculated_at; where popularity_type=34;
sort calculated_at desc; limit 1;
→ [{ "calculated_at": 1775681980 }]

100% of type 34 rows (17,800 / 17,800) share the exact same calculated_at = 1775681980 (2026-04-08 20:59:40 UTC), so the endpoint isn't partially updated — it's a complete frozen snapshot. For contrast, popularity_type=5 (Steam 24hr Peak Players) returned today's timestamp 1776575295 (2026-04-19 05:08:15 UTC) on the same request window.

#

I previously asked about it here #api message but without any response

spring sun
#

Hello thank you for reporting this. Sorry we missed this in the api channel.

I'll investigate the pipeline, and see if there is something that we have missed on our side.
But looking at the data today, it seems to be correct.

Are you still experiencing issues with this popularity_type?

radiant knot
#

The results today seem to be working fine. However on the 19.4 it was not and what worries me is the very long window (11 days) when it wasn't working. How reliable is this new api? Is it in beta? Because it was a lucky coincidence that I found out about it (I was looking for Pragmata, which just released and could not figure out why it's not showing in my app) and I can't afford for my service to have such a big down window

spring sun
#

We have been investigating and I have found the issue and patched it.
This should not happen again.
The PopScore syncs have been consistent though the week.
Than you for reporting this 👍