The pending counter desynced from the actual approval list (state.queue
holds approved items as history, so the count never decreased after a
host approve). The host-pushed pendingApprovalCount workaround didn't
hold up under live testing either, so we're rolling the whole cap
feature back rather than ship something flaky.
What's gone:
- OrbitSettings.maxPending + state.pendingApprovalCount
- cap branch in applyOutboxSnapshotsToState (now back to mute-only)
- maxPending number input in settings popover
- pending counter chip in OrbitQueueHead
- 'cap-reached' branch in evaluateOrbitSuggestGate / OrbitSuggestGateReason
- cap-related toasts in ContextMenu / useOrbitSongRowBehavior
- cap-related i18n keys (suggestBlockedCap, settingMaxPending*, pendingCounter*)
- cap CSS (.orbit-queue-head__pending, .orbit-settings-pop__number)
What stays: per-guest suggestion mute (works correctly) and everything
that fed into both features (OrbitState.suggestionBlocked,
setOrbitSuggestionBlocked, evaluateOrbitSuggestGate, the participants
popover Mic/MicOff toggle, the suggestBlockedMuted toast).
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The "X / Y pending" counter in the queue head and the guest-side
gate-check both used `state.queue.filter(non-host).length`, which is the
*history* count — items the host has already approved or declined still
sit in `state.queue` for attribution lookup, so the counter never
decreased. Reported as "3 / 4 pending" with no actual rows in the
approval list.
The merged / declined sets only exist in the host's local store, so the
guest can't filter them out itself. Solution: the host writes an
authoritative `pendingApprovalCount` into the state blob each tick;
guests (and the host's own UI) read it directly, with a fallback to the
old over-counting behaviour for any older client that doesn't write the
field.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Two anti-spam knobs the host can dial during a live session:
1. Per-guest suggestion mute — Mic / MicOff toggle next to the
kick/ban buttons in the participants popover. Symmetric (re-enable
later). State lives in OrbitState.suggestionBlocked: string[]; the
guest reads it and disables its own Suggest controls so the user
sees a clear "muted" state instead of silent failures. Host-side
sweep also drops their outbox entries as a safety net.
2. Max pending approvals cap — number input in the session-settings
popover, default 0 (= unlimited so existing sessions are unaffected).
When set, the host sweep stops folding new outbox entries into the
approval list once the cap is reached. The OrbitQueueHead surfaces
"X / Y pending" so guests can see when they're getting close.
State changes are additive on the wire — both fields are optional, with
parseOrbitState defaulting them, so older clients keep working.
evaluateOrbitSuggestGate() centralises the guest-side allow/block check
shared between useOrbitSongRowBehavior and the ContextMenu Add-to-Session
items, plus suggestOrbitTrack as a defensive last line.
i18n: en + de + fr + nl + zh + nb + ru + es.
Also fixes an earlier dedupe-key collision: the (user, trackId) cache
keys were missing their separator (NULL byte slipped in during the
previous patch), so two tracks could share a key and one of them
silently overwrite the other. Restored the space separator.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Album and playlist enqueues go through usePlayerStore.enqueue() directly,
never through hostEnqueueToOrbit, so the tracks never land in
state.queue. Our attribution map only covered state.queue entries, so
bulk-added rows rendered with no label at all.
Fall back to "Added by you" when a track is in the host's player queue
but has no state.queue entry — the host added it themselves by
definition (pre-session or bulk-add). The guest-side view already had
this fallback via base.host in useOrbitHost.ts.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Before: the guest queue already labelled guest-suggested tracks with
"Suggested by {user}", but host picks had no label — and the host's own
queue had no attribution at all. The host couldn't tell which upcoming
rows came from guests without checking the pending-approvals list.
- Guest queue: host-pick rows now show "Added by host" instead of hiding
the attribution line.
- Host queue: each row (and the current track) shows "Added by you" or
"Added by {user}" while an Orbit session is active. Lookup uses the
existing OrbitState.queue / currentTrack addedBy field, so no new
protocol fields.
New i18n keys (en+de+fr+nl+zh+nb+ru+es):
orbit.queueAddedByHost · queueAddedByYou · queueAddedByUser
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Guest outboxes are append-only from the host's POV — every sweep reads
the same playlist. `applyOutboxSnapshotsToState` was unconditionally
pushing every trackId in every snapshot into `state.queue`, so the
pending-approval list grew by one duplicate per tick for every unhandled
suggestion (visible as 4+ identical rows after ~10 s).
Dedupe against `(user, trackId)` already present in `state.queue` or
`state.currentTrack` before appending. A guest re-suggesting the same
track after it lands/plays is a rare enough case to live with for now.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Aligns orbit invites with the existing magic-string family (psysonic1- for
server invites, psysonic2- for library shares) by folding orbit into the
psysonic2- payload as a new k:'orbit' variant. The JSON body is
intentionally extendable so future layers (passwords, permissions,
invite expiry) can be added without a format migration.
- SharePayloadV1 split into EntitySharePayloadV1 + OrbitSharePayloadV1
- decodeSharePayloadFromText filters orbit out; orbit has its own decoder
- applySharePastePayload param narrowed to EntitySharePayloadV1
- buildOrbitShareLink / parseOrbitShareLink kept as thin wrappers
- slug parameter dropped (magic string is opaque, so the slug was
cosmetic-only in the old URL form); slugifyOrbitName removed as dead code
- joinModalLinkPlaceholder updated in all 8 locales
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Reverts #271, #292, #293, #294, #295, #296.
The flatpak CI pipeline itself works end-to-end, but the installed bundle
surfaced three separate manifest issues during smoke-test on Wayland+NVIDIA:
1. GDK_BACKEND is not set, so without an X11 display in the sandbox GTK
aborts with "Failed to initialize GTK".
2. libayatana-appindicator3 is not bundled in the GNOME 47 runtime, so
libappindicator-sys panics the main thread.
3. The release binary is compiled via \`cargo build --release\` rather than
\`cargo tauri build\`, so the \`custom-protocol\` feature is off and
Tauri falls back to devUrl — the window opens but shows
"Could not connect to localhost".
Rolling back so main stays on 1.43.0. A follow-up on the original PR
tracks the fixes needed before re-attempting.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The flatpak-github-actions container runs as root, but the actions/checkout
workspace is owned by the runner user. Without a global safe.directory entry
git aborts later steps (notably gh release upload, which probes git
internally) with "fatal: detected dubious ownership".
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
The \`app-v*\` tag referenced by the manifest only becomes a real git ref
when the Draft release is published, so the previous \`git ls-remote\`
lookup during CI always returned empty and flatpak-builder failed with
"unknown revision app-v<version>". Use \`github.ref_name\` and
\`github.sha\` directly — both exist when the workflow fires.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Adds full Flatpak support for Psysonic including:
- Flatpak manifest (org.gnome.Platform 47 + rust-stable + node20)
with proper finish-args for MPRIS, Discord RPC, PulseAudio, Wayland/X11
- AppStream metainfo XML and .desktop entry
- In-app updater disabled at build time via VITE_PSYSONIC_FLATPAK=1
- CI job \`build-flatpak\` in release.yml: generates cargo/npm offline
sources, patches manifest with release tag/commit, builds bundle via
flatpak/flatpak-github-actions@v6, uploads .flatpak to GitHub release
- Release docs updated in CLAUDE.md (Flatpak bump and Flathub mirror flow)
Adds activeServerId to the Home useEffect dependencies so a server
switch triggered while the user is already on the Mainstage refetches
albums/artists instead of leaving stale covers (which broke against the
new server's cover URLs).
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Selecting playlists via the header toggle only exposed the delete action
through the right-click context menu. Add a visible Delete-selected button
next to Cancel that kicks off the same handleDeleteSelected flow, with a
tooltip hint when some of the selected playlists aren't deletable (foreign
owner). Button is only rendered when selection mode is on and at least one
playlist is selected.
Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Ensure playlist card Play action uses tracks filtered by the active library and show filtered song count and duration in the list, so card metadata matches actual playback scope.
Open smart playlist editing from playlist cards, load rules via Navidrome single-playlist API with safer fallbacks, and keep edit visibility aligned with ownership rules.
Also add/clean smart playlist locale keys across all supported languages and preserve smarter autogenerated naming behavior.
Show edit/delete actions on hover in playlist cards, support opening metadata edit directly from the grid, and render smart playlist covers from active-library tracks. Playlist detail now filters displayed songs to the selected library instead of hiding whole playlists.
Move smart playlist creation and management into Playlists, including Navidrome-only gating, smart-name/icon presentation, and smarter refresh handling while server-side smart rules are being applied.
Psychotoxical
kilyabin
cucadmuh
Maxim Isaev