DaisyVotes — Troubleshooting

Organised by what you’re seeing, not by what’s broken. Start with the doctor either way.

Run the doctor first

/daisyvotes doctor

It checks the receiver, your site aliases, reward commands, storage, file permissions, menu layout, custom-item plugins, and — on a network — whether your servers can actually see each other, and tells you which is wrong and what to do. Most of the problems below are already named in its output.

---

Votes never arrive

By far the most common problem, and almost always one of five things. Work down the list — each step rules something out.

1. Is the receiver listening?

   /daisyvotes receiver status

   It should say listening and name a port. If it says disabled, receiver.yml has mode: Disabled. If it says the port is in use, something else has it — usually NuVotifier, still installed.

2. Is the port reachable from outside?

   The voting site connects in to your server. The port must be open in your firewall and forwarded by your host, and it is not your Minecraft port. Test it from another machine:

   telnet your-server-ip 8192

   A connection that hangs open is correct — the receiver speaks first. Connection refused means the port is closed or nothing is listening.

3. Does the vote site have the right key?

   Votifier v2 sites need the token from receiver.yml (tokens.default). Votifier v1 sites need the public RSA key:

   /daisyvotes receiver publickey

   Paste it into the site exactly, including the header and footer lines if it asks for them. A wrong key produces a vote the receiver rejects rather than one it never sees — check the console.

4. Does the service name match a site?

   This is the one people miss. DaisyVotes matches an incoming vote by comparing the service name the site sends against each site’s id and service-aliases in menus.yml. If nothing matches and sites.require-configured-site is true (the default), the vote is rejected.

   Turn on rejection logging to see exactly what the site called itself:

   receiver.yml

   security:
     log-rejected-votes: true

   Then vote. The console prints the service name. Add that string to the site’s service-aliases and reload.

5. Is the site actually sending?

   Most listings have a “test vote” button in their panel. If nothing reaches you and the port is open, the problem is on their side — some sites queue votes for hours, and some silently disable a listing whose test failed weeks ago.

Still running NuVotifier?

Two plugins cannot listen on one port. Either remove NuVotifier — DaisyVotes imports its port, tokens and RSA keys automatically on first start, so your sites need no changes — or keep it and set mode: NuVotifierBridge in receiver.yml so DaisyVotes takes votes from it instead of binding its own port.

---

Votes arrive but nothing is given out

On Minecraft 1.21.0 – 1.21.4, update to 2.6.0. Every item DaisyVotes built from config threw an error on those versions, so votes were counted and rewards were silently never granted. The console shows NoSuchFieldError. This is fixed in 2.6.0.

Otherwise:

• The player was offline. Rewards queue for /vote claim. Check offline-rewards.enabled in config.yml.
• The player was in a restricted world. If you have configured world-restrictions with queue-rewards: true, items are held deliberately and the player is told so. The vote itself still counts.
• A Command reward is wrong. Reward commands run from console, so they need a player name — /daisyvotes doctor flags commands that reference a plugin you do not have. Test with /daisyvotes testvote <player>.
• Their inventory was full. Items overflow to the ground at the player’s feet.

---

The leaderboard numbers look wrong

A player seems to have lost votes

Most likely they exist twice. Voting sites usually do not send a Minecraft UUID, and before 2.6.0 a vote that arrived while the player was offline was recorded under a UUID derived from their name — not their real one. Votes cast while online and offline landed under two identities and their totals split between them.

2.6.0 stops new splits. It does not merge existing ones. To find them:

SELECT uuid, name, totalVotes FROM vote_players WHERE name = 'PlayerName';

Two rows with the same name is the split. The fabricated UUID is a version-3 UUID — its 15th hex digit is 3.

Daily or weekly totals are stale

Before 2.6.0, scoped counters were only reset when that player next voted, so someone who last voted on Tuesday still showed Tuesday’s daily count on Friday — in game, in PlaceholderAPI, and on any website reading the database. Fixed in 2.6.0.

If you read these columns from a website, they must be filtered on the period key. See Database access.

/vote top and the top-voter awards disagree

They measure different things, and that is intentional. /vote top reads each player’s counters; top-voter awards count rows in the vote log for the period. On a server that ran a version before 2.6.0, simultaneous votes could be credited once while both were still logged — so the log is the higher, and truer, number.

---

I changed the config and nothing happened

• Candle name and lore do nothing. A site candle’s name comes from display-name and its lore is generated. Use vote-menu.buttons for text you control.
• {site_votes}, {site_reward_hint} and {cooldown} are not real. Older generated menus.yml files shipped candle lore containing them; they never existed in the plugin. Harmless to leave, safe to delete.
• visuals.banner-style does nothing since 2.5.0. visuals.startup-banner still turns the banner off.
• A button vanished. Its slot is outside the menu’s rows, it has enabled: false, or two buttons share a slot and one is drawn over the other. /daisyvotes doctor reports all three.
• You edited the wrong file. Menus live in menus.yml, rewards in rewards.yml, shop entries in shop.yml. Editing config.yml will not move a button.
• A %papi_placeholder% prints literally instead of resolving. Check /daisyvotes doctor first — PlaceholderAPI has to be installed. If it’s hooked, check where the placeholder is: it resolves in vote-menu item name/lore, action bars, /vote//daisyvotes command replies, and a Message-type reward’s value — but a Command-type reward’s value never resolves one, and neither do broadcasts or a handful of the direct per-vote chat confirmations (vote-received, wheel-reward-won among them). See Other plugins’ placeholders inside DaisyVotes for the full list.

Config files are watched, so edits apply on save — you do not need /daisyvotes reload, though it does no harm.

Your config is never overwritten

New keys are appended to your existing files with their comments on first start after an update. Nothing you wrote is removed or reordered, and no upgrade rewrites a file you edited.

---

Database problems

• Failed to create index on MySQL, on an old build. Earlier versions emitted CREATE INDEX IF NOT EXISTS, which is MariaDB/SQLite/Postgres syntax that stock MySQL rejects — table setup could fail on genuine MySQL. Fixed; update if you still see it.
• Duplicate rows. Schema migration only ever adds columns — it never adds a primary key to a table that already existed without one. If your tables predate DaisyVotes’ own creation of them, check with SHOW CREATE TABLE player_site_votes; and add the primary key by hand.
• Vote totals reset after upgrading to 2.5.0. Expected and documented — 2.5.0 moved to new column names. Your old rows are still there, unread. See Migrating.
• backend: postgres fails on startup, on an old build. The Postgres driver was never actually bundled before 2.6.2 — backend: postgres could only ever fail with a ClassNotFoundException. Fixed; update. Postgres is otherwise the newest of the three supported backends — see Storage & Data.

---

Custom items (Nexo, Oraxen, ItemsAdder) not showing up

• The slot shows a plain material instead of your item. Either the named plugin isn’t installed/enabled, or it has no item with that id — both are typos or a load-order problem, not a DaisyVotes bug. /daisyvotes doctor names the exact configured id and which plugin would resolve it.
• Check the spelling of the prefix. It’s nexo:, oraxen:, or itemsadder:, matched on the text before the first colon — itemsadder:mypack:ruby is correct; DaisyVotes hands mypack:ruby to ItemsAdder itself.
• DaisyVotes has no hard dependency on any of the three. It reaches whichever is installed by reflection, so nothing needs to be added to plugin.yml on your end — DaisyVotes already soft-depends on all three for load order. If the plugin loads after DaisyVotes on a given start, that’s a load-order issue with the other plugin, not a missing dependency.
• New in 2.6.2. If an item looks visually wrong in one menu but not another (name, model, glint), report it — this is the newest of this release’s changes.

---

Multi-server problems

• /daisyvotes doctor reports “Another server is already using server-id ’…’”. Two servers on this Redis network are answering to the same network.yml → server-id. If you left it on auto, this can no longer happen from two servers sharing a machine (fixed in 2.6.2 — auto now derives from hostname and game port, not the server software name); a hand-set id that’s been copied to two network.yml files is the remaining way to hit this. Give each server its own id and reload both.
• Vote counts drifted apart between servers before 2.6.2. That’s the symptom of the id collision above: each server read the other’s cross-server messages as its own echo and silently discarded them — cache invalidations, vote-party broadcasts and reward routing all included. Nothing errored. Updating and giving each server a distinct id stops new drift; it doesn’t reconcile numbers that already diverged.
• A vote on one server and a shop purchase on another, close together, used to be able to lose one of the two. Fixed in 2.6.2 — player-record updates now take a lock across the whole network, not just the one JVM. See Locking a player’s record across servers.

---

Testing without waiting for a real vote

/daisyvotes testvote <player>            # simulates a vote on every site at once
/daisyvotes testvote <player> <site>     # simulates one site
/daisyvotes forceparty                   # triggers a vote party now
/daisyvotes givespin <player> 1          # grants a wheel spin

testvote with no site completes the daily set in one command, so you can test /vote spin immediately. It runs the full pipeline — rewards, points, streak, party, Discord — so what you see is what a real vote does.

---

Getting help

Have this ready and most questions answer themselves:

• The output of /daisyvotes doctor
• Your DaisyVotes and Paper versions, and the exact Minecraft version
• The console from server start, and from the moment a vote should have arrived
• receiver.yml with the tokens and private key removed

Never share these

receiver.yml contains your RSA private key and v2 tokens; network.yml contains your Redis password; config.yml contains your license key. Anyone with the receiver’s secrets can forge votes on your server. Redact before pasting anywhere.

Database access Reading vote data from a website, with queries that are correct.