Sooner or later, almost every long-time BetterJoy user meets the same console message: Duplicate timestamp enqueued. It is the program’s most recognisable recurring log line — dozens of issue reports quote it word for word — and it ranges from harmless background noise to a flood that makes the controller unusable. This page explains what the message means, what the project’s author identified as the main cause, and the fixes that actually map to each scenario.
What the message means
BetterJoy streams motion data from your controller to emulators through its built-in Cemuhook/DSU server. Each motion sample carries a timestamp, and samples are queued in order. When a sample arrives whose timestamp is already in the queue, BetterJoy drops it and logs Duplicate timestamp enqueued. An occasional dropped sample is invisible in gameplay. The problem is the flood: when something downstream keeps requesting or reading data in a way that generates duplicates continuously, the log scrolls non-stop and, in the worst reports, real input stops getting through.
The author’s root cause: the emulator is reading the wrong input API
The clearest explanation on record comes from issue #336, where the message spammed the log after launching an emulator and the controller stopped working. The author (Davidobot) replied that the root cause was the emulator reading the controller through DirectInput instead of XInput — the emulator was seeing the raw controller alongside BetterJoy’s virtual one, and the fix in that thread was to install the HIDGuardian driver layer and enable it, so only the XInput device remained visible.
Translated into steps for your setup:
- In your emulator’s input settings, set the controller API to XInput (not DirectInput) for the virtual controller BetterJoy creates.
- Make sure the game is not also reading the physical controller directly. If it can see both devices, you have the classic double-exposure setup — our double input fix explains how to hide the physical controller properly with HidHide.
- Restart both the emulator and BetterJoy after changing the API; the queue state does not reset mid-session.
Scenario 2: It starts after about 20 minutes, with rumble on
Issue #616 describes a different pattern: the message appears after roughly 20 minutes of play with rumble enabled, while turning rumble off lets the same user play for hours. If your flood is time-delayed rather than instant, treat rumble as the trigger: lower the rumble intensity in your emulator (the long-standing community guidance for Cemu is around 70–80%), or disable rumble for a session to confirm the pattern before changing anything else. Rumble traffic shares the same Bluetooth link as the motion stream, which is also why rumble shows up in several of our Bluetooth lag checks.
Scenario 3: It floods when a streaming or capture tool joins
The earliest detailed report, issue #292, involved Parsec: the log flooded and the user had to disconnect the Pro Controller to stop it. Streaming and remote-play tools hook controllers in their own way and can recreate the same “two readers” conflict as the DirectInput case. If your flood starts exactly when a streaming, capture, or remapping tool launches, close that tool, confirm the log goes quiet, then reintroduce it — and make sure it is not also exposing the physical controller as a second device.
One honest boundary: in issue #387 the message recurred on v6.3 even with the config’s legacy PurgeWhitelist option changed, alongside stray Windows shortcut presses. Not every instance has a clean user-side fix, and the later stages of that thread are workarounds rather than a patch. If you have eliminated the wrong-API cause and the rumble pattern, say so plainly in a new issue report — you are past what configuration can solve.
When you can safely ignore it
If the line appears occasionally in the console while your controller responds normally — in a menu, during a loading screen, once in a while mid-game — it is the queue doing its job and dropping a redundant sample. It needs no action. Act only when it is continuous, when it coincides with input loss, or when it arrives with a pattern (a specific emulator, rumble, a streaming tool) you can match to the scenarios above.
New to the program itself? Start with the first-run guide and the package on the download page so your baseline setup is known-good, then come back here if the message appears. More fixes live on the troubleshooting hub.
If you end up reporting it
Should you take this to the issue tracker, report it the way the useful threads in the archive do: quote the exact message, name the emulator and which input API it was set to (XInput or DirectInput), state whether rumble was on, and note when in the session the flood starts — immediately, or after a delay like the ~20 minutes in #616. Those four facts are what separate your report from the dozens of unactionable ones, and they are the same four facts the fixes on this page are organised around.
FAQ
Is “Duplicate timestamp enqueued” an error that damages anything?
No. It is a log message about a dropped motion sample. It does not corrupt your controller, your config, or your saves. Only its continuous form matters, because of the input problems that travel with it.
The fix mentions HIDGuardian. Should I install it?
HIDGuardian is the legacy layer bundled with v7.1, and it was the era-correct answer in the author’s thread. Today the maintained hiding tool is HidHide, and the two must never be installed together. Our double input fix walks through the modern route and the removal order for the old one.
It only happens in one emulator. Is BetterJoy broken?
Almost certainly not — a single-emulator pattern points at that emulator’s input API setting (DirectInput vs XInput) or its DSU client configuration, which is exactly the author’s diagnosis in #336.