Missing watch streaks

[burning-scar]

First of all, mad respect for putting the time and effort into doing a complete rework from scratch of the Twitch-Miner. I was observing the project since it's beginning and was blown away, how quick and consistent it grew to it's current state. Big props.

I was hesitating before creating an issue, because the project is still in an early state and I didn't want to cast a shadow on it. Also I didn't want to jump to any conclusions with the recent Twitch API changes.

This issue is bothering me for a while now, it also did happen with the original Miner, but before summer it was less significant.

I'm running the script on two systems, each is mining for one Twitch account. Both systems are running the same streamer list with around 380 entries. Identical miner settings, predictions off.
When the runtime starts, it follows the intended watch_priority: STREAK -> DROPS -> ORDER. Watch_streaks are grabbed at the begin, then drops are claimed if available and after that it continues with mining the channel points according to the order of the online list. All good.
It works fine for a few hours - streamer comes online and watch_streak gets grabbed, after that it continues mining.
BUT, after an unknown time span of hours an anomaly seems to happen: a streamer comes online, but it's not claiming the 450 points, it seems to ignore the streamer and keeps mining the streamers at the top of the online list. But weirdly only on one miner, not on both. Suddenly, when the top streamer goes offline after 5 to 7 hours, the delayed watch_streak gets claimed, like it got held back. So if live streams don't overlap and new ones end earlier then ongoing ones, the damage is done and a stream is missed.

System 1, account A

System 2, account B

So my thoughts were, if I run both accounts on both systems, then maybe they can back eachother up. But no luck, some streaks still go missing. Now I'm out of ideas.

I'd like to know, if others are experiencing the same behavior or who is getting all streaks.

[0x8fv]

Hey @burning-scar!
Thanks for the detailed report and your support!

Here’s what was going on and what i changed:
The odd behavior you saw (streak not being claimed until a “top” streamer goes offline, sometimes only on one miner) was real and traceable to how I tracked streak state and picked streams to watch.

Streak was treated as “one‑shot per process”, not per stream
Internally each stream has a flag WatchStreakMissing. At startup this is true for every streamer, so the STREAK priority does what you’d expect: it tries to watch channels that still need their streak.

The bug is that this flag was only ever cleared and never reset:
When Twitch sends a PubSub points-earned event with reason WATCH_STREAK, I set WatchStreakMissing = false for that streamer.
But I did not set it back to true when:
The streamer starts a new broadcast (new stream-up event), or
The broadcast ID changes (new stream session on the same channel).
So after the first streak on that channel in the current miner run, the code would permanently think “streak is already done” for that streamer.

As the session runs for hours:
At the beginning, most streamers have WatchStreakMissing = true, so the STREAK phase of the scheduler actively rotates through them.
After each of them gets one WATCH_STREAK payout, their flag flips to false and they drop out of the STREAK candidate pool.
Once most channels have had their first streak, the effective behavior silently collapses to just [DROPS, ORDER], even though STREAK is still in the configured watch_priority.
So the miner was “correct” at the start, but over time it stopped treating new streak opportunities as streaks at all.

In short

The core bug was that I treated WatchStreakMissing as a one‑off flag that was never reset per new broadcast. After each channel’s first streak in a session, the scheduler stopped seeing that channel as needing a streak at all. Over time, with only two watch slots and a large list, this led to:

Some channels never being watched while “top” streams stayed live.
Streak payouts appearing only after a long‑running top stream went offline, giving the impression of a delayed or buffered streak.
Differences between two miners because their watch choices diverged early on.
The fixes I’ve put in since then reset streak state on new broadcasts and adjust the slot selection logic, so each new stream gets a fresh chance to be prioritized for its streak, instead of being silently treated as “already done” for the rest of the run.

Fixes i made:

Reset streak tracking per broadcast: when a stream goes live (stream-up PubSub) or when we detect a broadcast ID change via HTTP, we reset WatchStreakMissing and minute counter so each new stream is treated as needing a streak.
Slot allocation: ensured a streak candidate can take the second slot even if the first slot is a higher-priority pick, and logs show why each slot was chosen.
Config toggle: added watch_queue_logging so you can turn the watch-queue logs on/off.

Of course this needs testing. I would like to ask if you could verify that this is in fact now fixed.
Here is the latest build. Thanks a lot for the report!
https://github.com/0x8fv/Twitch-Channel-Points-Miner/releases/tag/0.0.9

[burning-scar]

Thank you for the fast implementation of new lines of code and trying to improve the Miner even further!

So I startet version 0.0.9 mining on 03.12.25 at 06:30 AM CET with "watch_queue_logging" set to "true".

Everything was working as intended. But to be fair, Twitch wasn't really busy that day and the Miner had plenty of time to watch between each streamer, when they came online. At this point I was curious, how it will be on the weekend, when many streamers will come online.

But unfortunately, after 22 hours when streamers who were online on the previous day came online again, it's somehow not watching them nor grabbing the watch streak. They show up once in the watch queue log, but get replaced in the next line.

Both Miners on both systems behave the same.

If you need more information, let me know.

[0x8fv]

@burning-scar I tracked this bug down to how I reset the “minutes watched” counter when a streamer starts a new stream (e.g. the next day). I was zeroing the counter but not its internal timestamp, so the next “minute watched” event would suddenly add many hours at once, making the miner think the streak was already satisfied and dropping that streamer from the streak queue after a single cycle. I fixed it by introducing a proper reset of the watch progress (counter + timestamp) whenever a new broadcast/session starts, so returning streamers now stay in the streak queue until their new streak is actually completed.

Could you please test it again?
https://github.com/0x8fv/Twitch-Channel-Points-Miner/releases/tag/0.1.0

[burning-scar]

Kept an eye on the Miner version 0.1.0 for 24 hours and an additional 12 hours, to see how it behaves after the 24-hr mark.

At first glance, everything seems to work how it should. On most streamers it works as intended.
There were three occasions that caught my eye. One is positive and two are negative.

Positive one first:

The Miner grabbed a watch streak at 09:36 AM 05.12.25 from a streamer, who went offline later after 06h23m of broadcasting.
At 04:07 PM 05.12.25 when the same streamer came online again on the same day (before the 24-hr mark), the miner knew there's no watch streak to grab (manually checked with browser to make sure there was none) and didn't waste its watch time on this streamer. Nice to see, it continued as planned here.

Now to the first negative event, which only occured on one of two systems/miners:

Streamer142 who came online lined up for watch queue, but somehow got kicked out of waiting line.
While on the second system, it grabbed the watch streak like as planned.

Second negative incident, similar to the first one, but just on system 2 with streamer043, who got ditched from the watch queue.

It feels like back to page one.

[0x8fv]

@burning-scar I did some research.
Twitch sometimes takes 10–15 minutes or more to deliver the WATCH_STREAK.
The miner would stop prioritizing a streak-missing streamer too early and move on (only 7 minutes). I changed the logic so we prioritize streaks for 7 minutes by default, but automatically extend the window to 20 minutes once the miner has been running for 10+ hours to avoid churn in long sessions (i hope).
I also updated the watch-queue logging to show per-slot details and a "streakRemaining" countdown, so we can see how much time is left before a streamer ages out of streak priority.

Also it would be really helpful if you could send the logs in Text format rather than screenshots 🙂

One question i got:
Do use different Twitch account's when running multiple miners?

Could you please test it again?
https://github.com/0x8fv/Twitch-Channel-Points-Miner/releases/tag/0.1.1

[0x8fv]

@burning-scar Any updates to this issue?

[taka93462-ship-it]

@burning-scar I did some research. Twitch sometimes takes 10–15 minutes or more to deliver the WATCH_STREAK. The miner would stop prioritizing a streak-missing streamer too early and move on (only 7 minutes). I changed the logic so we prioritize streaks for 7 minutes by default, but automatically extend the window to 20 minutes once the miner has been running for 10+ hours to avoid churn in long sessions (i hope). I also updated the watch-queue logging to show per-slot details and a "streakRemaining" countdown, so we can see how much time is left before a streamer ages out of streak priority.

Also it would be really helpful if you could send the logs in Text format rather than screenshots 🙂

One question i got: Do use different Twitch account's when running multiple miners?

Could you please test it again? https://github.com/0x8fv/Twitch-Channel-Points-Miner/releases/tag/0.1.1

Hi, regarding the recent streak logic change (7-20 mins wait), I have an observation from my logs:

Observation: The WATCH_STREAK always arrives at the exact same second as the first WATCH point (+10 points) reward. If the first watch point reward doesn't trigger a streak, it won't trigger at all.

Proposal: Instead of a fixed timer, we should trigger a "switch streamer" event immediately after the first WATCH reward is received, regardless of whether a streak was awarded.

To be safe, we can keep a 10-minute fallback timer as a safety net in case Twitch fails to send any point updates, but the first watch point should be the primary trigger. This would drastically speed up the queue rotation.