Poker hand history imports 400 hands; the session graph loses 3 days

Poker hand history imports 400 hands; the session graph loses 3 days. That's the specific failure: the tracker ingests the hands, the HUD populates, the session list shows a new entry, and then the graph jumps from Tuesday to Friday with nothing in between. The hands exist. The timeline doesn't. This is one of the more confusing bugs in poker tracking software because the data import and the visualization are two separate pipelines, and only one of them broke.

If you've hit this, you've probably already tried the obvious things — restarting the client, re-importing, checking the database folder size. None of it helps, because the hands aren't missing. The graph is.

What actually happens during an import

Most trackers (Holdem Manager, PokerTracker, Hand2Note, DriveHUD, and the various newer web-based tools) run imports through a queue. The client writes hand history files to disk — usually to a folder like C:\Users\[name]\AppData\Local\[PokerRoom]\HandHistory or the equivalent on Mac — and the tracker polls that folder, parses each file, and inserts rows into a database.

The session graph is a separate query against a different set of fields: timestamps, table IDs, and session boundaries. A hand can import perfectly into the hands table and still fail to register on the graph if its timestamp is malformed, if the timezone offset is wrong, or if the session-grouping logic decides the hand belongs to a session that doesn't exist yet.

That's the gap. 400 hands imported. Three days of timeline missing. Two different code paths disagreeing about what happened.

The timestamp problem

The most common culprit is timezone handling. Poker clients write hand histories in local server time, and trackers try to normalize to your local time. When a room changes its server timezone — or when daylight saving shifts mid-session — the tracker can end up with timestamps that fall outside the range it considers "current." Those hands get imported but flagged or bucketed incorrectly, and the graph's date axis skips them.

A related issue: some rooms write dates in DD/MM/YYYY and others in MM/DD/YYYY. If your tracker guesses wrong on a handful of files, you get hands dated to a month that hasn't happened yet, or to three days ago when they were played today. The graph renders what the timestamps say, so if the timestamps lie, the graph lies.

Why 400 hands and not 40,000

The number matters less than the pattern. A 400-hand import that loses three days usually points to a batch problem rather than a per-hand problem. If the tracker were misparsing individual hands, you'd lose a scattered few, not a contiguous block.

Three days is roughly the window you'd expect if:

• A session was played across a room's weekly maintenance window
• The client was updated mid-week and changed its hand history format
• The tracker's background import service was paused (Windows sleep, Mac App Nap, antivirus interference) and then resumed with a stale cache

In each case, the import catches up on the hands but the session indexer — which runs less frequently, sometimes only on tracker startup — doesn't rebuild. You get hands without sessions. The graph shows sessions, so it shows nothing.

There's a quick diagnostic: open the hands tab, sort by date, and look at the timestamps of the 400 imported hands. If they cluster in a three-day window that the graph skips, it's an indexing problem. If they're scattered across weeks, it's a parsing problem. Different fix.

The fixes, in order of how often they work

1. Force a database rebuild of the session index. In PokerTracker 4, that's Database → Database Management → Rebuild Cache. In Holdem Manager 3, it's Tools → Rebuild Cache. This re-runs the session-grouping logic over every hand in the database. It takes a while on large databases — expect 20 minutes for 500k hands, longer for millions — but it's the single most effective fix for graph gaps.

2. Check the timezone setting against the room's actual server time. If your tracker is set to your local timezone but the room writes in server time, every hand is offset. The graph will look mostly right and then drift. Set the tracker to match the room's server timezone, re-import the affected files, and rebuild.

3. Verify the hand history folder is the one the client is actually writing to. Room updates sometimes change the default path. The tracker keeps polling the old folder, finds nothing new, and reports "0 hands imported" — except when a stale file gets picked up and parsed with an old timestamp. This produces exactly the 400-hands-no-graph symptom.

4. Disable the import service's sleep behavior. On Windows, set the tracker's background service to "High Performance" power plan and exclude the hand history folder and database directory from real-time antivirus scanning. On Mac, disable App Nap for the tracker. Background imports that get suspended mid-batch are a known cause of partial session data.

5. Re-import from the raw files, not from the database. Most trackers let you point at a folder of .txt hand histories and import them fresh. If the database rows are corrupted, this bypasses the corruption. It also lets you watch the import log in real time, which usually surfaces the actual error — a parse failure on a specific hand format, a duplicate-key conflict, or a file-encoding issue.

What doesn't work

Deleting and recreating the database. This is the advice you'll find on forums, and it's almost always wrong for this specific symptom. The hands are fine; the index is stale. Rebuilding the database from scratch takes hours, loses any manual notes or color codes, and lands you in the same place if the underlying timezone or folder-path issue isn't fixed first.

The bigger issue: trackers treat import and display as separate concerns

The 400-hands-three-days bug is a symptom of an architectural choice. Trackers optimize for import speed — parsing thousands of hands per second — and run the session indexer as an afterthought. When the two disagree, the import wins and the display loses, silently.

That's a problem for anyone using a tracker to review sessions rather than just for HUD stats. If the graph is the primary tool you use to find leaks, a three-day gap isn't a cosmetic bug; it's missing data in the exact place you're looking. The hands are there, but the review workflow isn't.

The open question is whether trackers will ever surface this disagreement to the user. Right now the only signal is a graph that looks wrong. A better design would flag it: "400 hands imported, 0 sessions created — rebuild index?" That's a one-line change to the import summary, and it would save players hours of forum-searching. Until then, the diagnostic is manual: check the hands tab, compare timestamps, rebuild the cache, and set your timezone correctly before you import anything else.