Version: 1.30.0. Source reviewed at 4171265227d8ea584bca359ba40b09d3ac0c8c6a on 2026-10-09.
Status: Complete written guide; source-reviewed behavior. No new v1.30 screenshots, screen recording, native tests, or live phone/network tests were performed for this guide. Existing v1.29 captures use simulated requests and remain historical. The companion narration is an untimed draft pending recording and timing.
Inbox opens the Singer Request Inbox. It is where you approve or reject song requests, choose a file version, assign a request to an existing singer, and decide account claims or departure alerts. The header's speech-bubble button opens a separate DJ Inbox for singer conversations, tips, replies, and song-buy messages. Clearing or answering a conversation does not approve a song request. [1][3]
Before testing incoming requests, select the correct show/gig and connection mode, confirm a reachable host connection, and have a singer phone or kiosk connected to that same show. Use a disposable show for practice. A card generated by a browser fixture proves only the staged interface flow, not delivery from a real phone.
For example, a fictional Mira request can be reassigned to Bob. Read “Add to Bob's queue” before accepting, then verify Bob's queue. Reassignment changes who receives the song; it does not change the requested title. On a group request, assigning another target replaces the requester in the lineup while preserving the other resolved performers. Ordinary group approvals can send consent invitations; band requests follow the separate band behavior. [1]
The Inbox Version selection supplies the chosen file to this approval. It does not call the global default-version override used by Rotation and Library. Do not use a global default change as a substitute for this request-specific choice. [1]
Reject sends a host-declined response for the requester and settles the card. Confirm the rejection status and that the intended request is no longer pending. It should not create a new queued song. If rejection fails, read the error and inspect the still-pending card before trying again.
Approval can encounter several different outcomes:
These paths attempt singer notifications. A host-side success message alone does not prove delivery to an offline phone. Verify with the singer if the distinction matters. [1][2]
You may drag song cards to organize your review order. This is local triage. The rotation rules decide approval placement; dragging an Inbox card to the top does not reserve the next turn. [1]
Auto-Approve applies to newly arriving eligible song requests. Switching it on does not run through every card already pending. Existing cards still need review, and an unattended failure can leave a card that needs a decision. Duplicate, blocked-song, and reserved-name rules continue to apply. Turn it off again when you want manual review of future arrivals. [1][2]
Accept Requests Online controls the request-acceptance setting sent to the backend. Turn it off when you are closing online submissions for the night; this does not clear the queue or settle cards already present. The checkbox is optimistic but rolls back if the backend rejects the change. Read the status message and verify its final checked state. For a real show, test what a connected singer sees rather than assuming a checked box establishes connectivity. [1]
Both settings are saved locally. Review them at the start of the next session instead of assuming they returned to your preferred state.
An account-claim card says that an account wants to claim an unclaimed singer name. Approval transfers the existing singer's songs and spot in line to that account. This is an identity decision, so verify that the person requesting the claim is the correct singer before choosing Approve.
Deny refuses that claim. Song Auto-Approve does not make this decision automatically: claims remain explicit cards. A failed approval leaves the claim with an error status. In this source version, a failed Deny backend call is logged but the local card is still removed, so do not infer a confirmed server-side denial from disappearance alone after a connection problem. [1]
A departure alert reports that the phone said it was more than 200 metres from the venue and left the area at least 45 minutes earlier. Treat it as a signal to check with the singer, not conclusive proof that they have abandoned the show.
The No pending requests empty message counts song requests and claims; a departure alert can still be visible above it. Read all card types before treating the Inbox as finished. [1]
Open the header speech-bubble button. Choose a singer conversation on the left and read its message history on the right. Selecting an unread conversation marks that conversation read. The v1.30 source uses per-conversation unread state; do not rely on older wording that opening the panel clears every unread conversation.
Type in Reply to [name] and choose Send reply. Check the recipient heading before sending. A successful send adds your outgoing message and clears that conversation's draft; a failure shows an error. Drafts are kept per conversation by the host app. The message area can label a Song buy request or show a Tip amount supplied with a message. Those messages are separate from song approval and do not themselves perform a purchase or establish a payment audit. [1][3]
Clear history immediately clears the host mailbox items for the current mailbox context. It is not a close button, and the source does not show a confirmation step here. Use ✕, Escape, or the backdrop to close the panel when you only want to return to the show. Do not describe Clear history as deleting messages from a singer's phone or as a server-wide deletion. [1][3]
A reviewed request is finished when its outcome is clear: the correct destination queue contains the approved song, or rejection is shown without adding it. Claims and departure alerts require their own decisions. For an end-to-end acceptance test, check one manual approval, one reassignment, a request-specific alternate version, a rejection, and the phone's observed response on a disposable show. This guide establishes source behavior; it does not claim those native/network tests passed.
All links are pinned to the reviewed v1.30 source and require access to the private repository.