issues regarding blacklisting a song

[Anas5258]

since the app doesnt let me let me add or remove songs at will (which would be nice, instead it deletes the song and moves to the trash if i try to organize the songs tab)

also the workaround which is blacklisting a song have some issues

when i try to blacklist a song there is an option saying "do not show again" which doesnt work it still gets shown for every other song i try to blacklist

another problem is when i blacklist i dont want to see the song in the list for that i need to filter them using the filter but when i switch from the songs tab and then again to the tab its back to default being normal...its not ideal to filter out everytime

(another thing that would be nice to have is to have the option to add plugins like "neuclear" app and search for songs when internet is available)

Thanks again for the app and would really appereciate if you fix these options

[Owie6789]

@CodeRabbit break down the users issue research and devops and search very well then give me an actionable plan

[Owie6789]

ty @Anas5258 i'll fix ts asap

[coderabbitai]

Coding Plan

Summary

• Fix the "do not show again" defect by writing to the correct existing doNotShowBlacklistSongConfirm preference key instead of isSongIndexingEnabled.
• Make song blacklist/restore update the DB isBlacklisted column (the source of truth for the Songs list) in addition to the legacy JSON store, so hidden songs disappear immediately without a rescan.
• Persist the Songs page filteringOrder by introducing a filteringStates slice that mirrors the proven sortingStates pattern, so the "hide blacklisted" filter survives tab switches.
• Explicitly defer the folder-prompt/Artists-filter sibling bugs and the online plugin/search feature as out of scope.

Design Choices

Design Choice 1: Should the sibling bugs in the folder blacklist prompt and the Artists page filter be fixed as part of this ticket?

Options Considered:

1. Fix only the song-related paths explicitly named in the ticket.
2. Also fix the folder prompt and Artists filter to make the behavior systemically consistent.

Chosen Option: 1

Rationale: Scope strictly to the reported song blacklist issues to avoid scope creep; the folder/artist gaps can be tracked separately. Exploration found BlacklistFolderConfirmPrompt.tsx also has a non-functional "do not show again" checkbox (no matching preference key), and the Artists page filter has an even worse persistence gap. The ticket, however, only reports the song blacklist flow.

Design Choice 2: How should the requested online plugin/search integration (e.g. Nuclear) be handled?

Options Considered:

1. Exclude it from this plan and treat as a separate feature request.
2. Attempt a minimal scaffold now.

Chosen Option: 1

Rationale: It is out of scope for these bug fixes and warrants its own dedicated design/ticket. This is a large, net-new subsystem (external providers, streaming, network handling) unrelated to the blacklist bug fixes.

💡 User Tips

Regenerate the plan with different choices with @coderabbitai <feedback>.

Implementation Steps

Phase 1: Fix the "do not show again" preference for the song blacklist prompt

This phase repairs the checkbox so that opting out of the confirmation dialog actually persists and is honored on subsequent blacklist actions. The read sites already correctly check doNotShowBlacklistSongConfirm; only the write is broken.

Correct the preference key written by the blacklist confirm dialog

Make the checkbox persist to the intended preference instead of an unrelated one.

• In src/renderer/src/components/SongsPage/BlacklistSongConfirmPrompt.tsx, change the confirm handler's persistence call from storage.preferences.setPreferences('isSongIndexingEnabled', isDoNotShowAgain) to write to doNotShowBlacklistSongConfirm.
• Verify the value written is the checkbox state so that unchecking still records false; no other logic in this component needs to change.
• No new preference key is required — doNotShowBlacklistSongConfirm already exists in Preferences (src/types/app.d.ts) and in LOCAL_STORAGE_DEFAULT_TEMPLATE (appReducer.tsx), and is already consumed by Song.tsx, SongCard.tsx, and CurrentlyPlayingSongInfoContainer.tsx.

🤖 Prompt for AI agents

Implement a fix in the song blacklist confirmation dialog so the "do not show
again" checkbox persists to the correct preference key, resolving the bug where
it currently writes to an unrelated preference and never suppresses the dialog.

- In `src/renderer/src/components/SongsPage/BlacklistSongConfirmPrompt.tsx`,
locate the confirm handler's persistence call which currently calls
`storage.preferences.setPreferences('isSongIndexingEnabled', isDoNotShowAgain)`.
- Change this call to write to the `doNotShowBlacklistSongConfirm` preference
key instead.
- Ensure the value written is the checkbox state (`isDoNotShowAgain`), so that
unchecking the box still records `false`.
- Do not modify any other logic in this component.
- Note: no new preference key needs to be created —
`doNotShowBlacklistSongConfirm` already exists in `Preferences`
(`src/types/app.d.ts`) and in `LOCAL_STORAGE_DEFAULT_TEMPLATE`
(`appReducer.tsx`), and is already consumed by `Song.tsx`, `SongCard.tsx`, and
`CurrentlyPlayingSongInfoContainer.tsx` — those read sites do not need changes.

Phase 2: Make song blacklist/restore immediately reflect in the library list

This phase resolves the core symptom that blacklisting a song does not remove it from the visible list. Because the Songs list and its whitelistedSongs/blacklistedSongs filter read the DB isBlacklisted column, the on-demand blacklist/restore actions must update that column (in addition to the existing JSON store) so the change is visible without waiting for a rescan.

Task 1: Add a DB mutation to set the blacklist flag on songs

Introduce a query helper analogous to the existing folder-level approach.

• In src/main/db/queries/songs.ts, add a function that sets songs.isBlacklisted (and isBlacklistedUpdatedAt) for a given set of song IDs to a supplied boolean value, mirroring how addFoldersToBlacklist works in src/main/db/queries/folders.ts.
• Keep it batch-friendly (accept an array of song IDs) to match how blacklist/restore actions operate on multiple songs.

Task 2: Sync blacklist and restore core actions with the DB column

Ensure both mutation paths keep the JSON store and DB column consistent.

• Update src/main/core/blacklistSongs.ts to call the new DB mutation (set flag to true) alongside the existing setBlacklist() JSON write, before firing dataUpdateEvent('blacklist/songBlacklist').
• Update src/main/core/restoreBlacklistedSongs.ts similarly (set flag to false) alongside its JSON write and its dataUpdateEvent call.
• Retain the JSON store writes so the scan-time derivation (isSongBlacklisted in src/main/utils/isBlacklisted.ts) stays authoritative and both systems remain aligned.
• Confirm the renderer's song queries are invalidated/refetched on the existing dataUpdateEvent so the updated isBlacklisted is picked up (verify via the query layer in src/renderer/src/queries/songs.ts); no change expected if event-driven invalidation already exists.

🤖 Prompt for AI agents

Implement DB-level synchronization for song blacklist/restore actions so
blacklisted songs disappear from the Songs list immediately, without waiting for
a rescan.

- In `src/main/db/queries/songs.ts`, add a new function that sets the
`songs.isBlacklisted` column (and `isBlacklistedUpdatedAt`) for a given array of
song IDs to a supplied boolean value. Mirror the pattern used by
`addFoldersToBlacklist` in `src/main/db/queries/folders.ts`. Make the function
batch-friendly, accepting an array of song IDs.
- In `src/main/core/blacklistSongs.ts`, call this new DB mutation with the flag
set to `true`, alongside the existing `setBlacklist()` JSON write, and do this
before the existing `dataUpdateEvent('blacklist/songBlacklist')` call.
- In `src/main/core/restoreBlacklistedSongs.ts`, similarly call the new DB
mutation with the flag set to `false`, alongside its existing JSON write, before
its existing `dataUpdateEvent` call.
- Keep the existing JSON store writes intact in both files so that the scan-time
derivation logic (`isSongBlacklisted` in `src/main/utils/isBlacklisted.ts`)
remains authoritative and both systems (JSON store and DB column) stay aligned.
- Verify that the renderer's song queries (in
`src/renderer/src/queries/songs.ts`) are invalidated/refetched on the existing
`dataUpdateEvent`, so the updated `isBlacklisted` value is picked up by the UI.
No changes should be needed here if event-driven invalidation already exists —
just confirm this behavior.

Phase 3: Persist the Songs page filter selection across tab switches

This phase stops the "hide blacklisted" (whitelistedSongs) filter from resetting when navigating away and back, by introducing a persisted filteringStates concept that mirrors the existing sortingStates pattern.

Task 1: Introduce a persisted filtering-state store slice

Add the type, default template, and storage helpers for per-page filter persistence.

• Add a FilteringStates interface in src/types/app.d.ts (mirroring SortingStates, at minimum songsPage?: SongFilterTypes), and add filteringStates: FilteringStates to the LocalStorage interface.
• Add a filteringStates default block to LOCAL_STORAGE_DEFAULT_TEMPLATE in src/renderer/src/other/appReducer.tsx (e.g. songsPage: 'notSelected'), relying on the existing addMissingPropsToAnObject migration to backfill this key for upgrading users.
• Add getFilteringStates/setFilteringStates helpers in src/renderer/src/utils/localStorage.ts using the existing generic getItem/setItem mechanism (same as sortingStates), exported under storage.filteringStates. No new reducer action type is needed since setItem already dispatches the localStorage update.

Task 2: Wire the Songs page filter to the persisted state

Default the filter from persisted state and write changes back, matching the sortingOrder pattern.

• In src/renderer/src/routes/main-player/songs/index.tsx, read the persisted default via useStore(store, (state) => state.localStorage.filteringStates.songsPage) and use it as the fallback when destructuring filteringOrder from Route.useSearch() (replacing the hardcoded 'notSelected').
• Add a useEffect watching filteringOrder that calls storage.filteringStates.setFilteringStates('songsPage', filteringOrder), mirroring the existing sortingOrder persistence effect.
• This ensures re-entering the tab (even via the sidebar link that carries no search params) restores the last chosen filter.

🤖 Prompt for AI agents

Implement persistence for the Songs page "hide blacklisted" filter
(`filteringOrder`) so it no longer resets to default when the user navigates
away and back to the tab, mirroring the existing `sortingStates` pattern.

- In `src/types/app.d.ts`, add a `FilteringStates` interface mirroring
`SortingStates`, containing at minimum `songsPage?: SongFilterTypes`. Add
`filteringStates: FilteringStates` to the `LocalStorage` interface.
- In `src/renderer/src/other/appReducer.tsx`, add a `filteringStates` default
block to `LOCAL_STORAGE_DEFAULT_TEMPLATE` (e.g. `songsPage: 'notSelected'`).
Rely on the existing `addMissingPropsToAnObject` migration mechanism to backfill
this key for users upgrading from an older version.
- In `src/renderer/src/utils/localStorage.ts`, add
`getFilteringStates`/`setFilteringStates` helper functions using the existing
generic `getItem`/`setItem` mechanism (following the same pattern as
`sortingStates`), and export them under `storage.filteringStates`. No new
reducer action type is needed since `setItem` already dispatches the
localStorage update.
- In `src/renderer/src/routes/main-player/songs/index.tsx`, update the
destructuring of `filteringOrder` from `Route.useSearch()` to fall back to the
persisted value read via `useStore(store, (state) =>
state.localStorage.filteringStates.songsPage)`, replacing the hardcoded
`'notSelected'` default.
- Add a `useEffect` that watches `filteringOrder` and calls
`storage.filteringStates.setFilteringStates('songsPage', filteringOrder)`
whenever it changes, mirroring the existing `sortingOrder` persistence effect.
- This should ensure that re-entering the Songs tab (including via the sidebar
link, which carries no search params) restores the last chosen filter value.

Research

This is an Electron music player with three layers: a React renderer (src/renderer), the Electron main process (src/main), and shared types (src/types). The renderer uses TanStack Router (file-based routes under src/renderer/src/routes), a global TanStack Store synced to window.localStorage (src/renderer/src/store/store.ts, src/renderer/src/other/appReducer.tsx, src/renderer/src/utils/localStorage.ts), and TanStack Query wrappers (src/renderer/src/queries). The main process persists data in a Postgres/Drizzle DB (src/main/db) and exposes functionality through IPC handlers (src/main/ipc.ts).

Blacklist currently exists in two unsynchronized systems: a legacy JSON electron-store (src/main/filesystem.ts, driven by src/main/core/blacklistSongs.ts / restoreBlacklistedSongs.ts) and a DB isBlacklisted column on the songs table (src/main/db/schema.ts, queried in src/main/db/queries/songs.ts). The Songs page list and its filter read exclusively from the DB column, while song-level blacklist actions write only to the JSON store — the DB column is refreshed from the JSON store only at scan time. Filter/sort state on the Songs page lives in URL search params; sortingOrder is persisted to the store via a sortingStates map but filteringOrder has no persistence equivalent.

---

🚀 Next Steps

🤖 All AI agent prompts combined

Task: 1

Implement a fix in the song blacklist confirmation dialog so the "do not show
again" checkbox persists to the correct preference key, resolving the bug where
it currently writes to an unrelated preference and never suppresses the dialog.

- In `src/renderer/src/components/SongsPage/BlacklistSongConfirmPrompt.tsx`,
locate the confirm handler's persistence call which currently calls
`storage.preferences.setPreferences('isSongIndexingEnabled', isDoNotShowAgain)`.
- Change this call to write to the `doNotShowBlacklistSongConfirm` preference
key instead.
- Ensure the value written is the checkbox state (`isDoNotShowAgain`), so that
unchecking the box still records `false`.
- Do not modify any other logic in this component.
- Note: no new preference key needs to be created —
`doNotShowBlacklistSongConfirm` already exists in `Preferences`
(`src/types/app.d.ts`) and in `LOCAL_STORAGE_DEFAULT_TEMPLATE`
(`appReducer.tsx`), and is already consumed by `Song.tsx`, `SongCard.tsx`, and
`CurrentlyPlayingSongInfoContainer.tsx` — those read sites do not need changes.
===============================================================================

Task: 2

Implement DB-level synchronization for song blacklist/restore actions so
blacklisted songs disappear from the Songs list immediately, without waiting for
a rescan.

- In `src/main/db/queries/songs.ts`, add a new function that sets the
`songs.isBlacklisted` column (and `isBlacklistedUpdatedAt`) for a given array of
song IDs to a supplied boolean value. Mirror the pattern used by
`addFoldersToBlacklist` in `src/main/db/queries/folders.ts`. Make the function
batch-friendly, accepting an array of song IDs.
- In `src/main/core/blacklistSongs.ts`, call this new DB mutation with the flag
set to `true`, alongside the existing `setBlacklist()` JSON write, and do this
before the existing `dataUpdateEvent('blacklist/songBlacklist')` call.
- In `src/main/core/restoreBlacklistedSongs.ts`, similarly call the new DB
mutation with the flag set to `false`, alongside its existing JSON write, before
its existing `dataUpdateEvent` call.
- Keep the existing JSON store writes intact in both files so that the scan-time
derivation logic (`isSongBlacklisted` in `src/main/utils/isBlacklisted.ts`)
remains authoritative and both systems (JSON store and DB column) stay aligned.
- Verify that the renderer's song queries (in
`src/renderer/src/queries/songs.ts`) are invalidated/refetched on the existing
`dataUpdateEvent`, so the updated `isBlacklisted` value is picked up by the UI.
No changes should be needed here if event-driven invalidation already exists —
just confirm this behavior.
===============================================================================

Task: 3

Implement persistence for the Songs page "hide blacklisted" filter
(`filteringOrder`) so it no longer resets to default when the user navigates
away and back to the tab, mirroring the existing `sortingStates` pattern.

- In `src/types/app.d.ts`, add a `FilteringStates` interface mirroring
`SortingStates`, containing at minimum `songsPage?: SongFilterTypes`. Add
`filteringStates: FilteringStates` to the `LocalStorage` interface.
- In `src/renderer/src/other/appReducer.tsx`, add a `filteringStates` default
block to `LOCAL_STORAGE_DEFAULT_TEMPLATE` (e.g. `songsPage: 'notSelected'`).
Rely on the existing `addMissingPropsToAnObject` migration mechanism to backfill
this key for users upgrading from an older version.
- In `src/renderer/src/utils/localStorage.ts`, add
`getFilteringStates`/`setFilteringStates` helper functions using the existing
generic `getItem`/`setItem` mechanism (following the same pattern as
`sortingStates`), and export them under `storage.filteringStates`. No new
reducer action type is needed since `setItem` already dispatches the
localStorage update.
- In `src/renderer/src/routes/main-player/songs/index.tsx`, update the
destructuring of `filteringOrder` from `Route.useSearch()` to fall back to the
persisted value read via `useStore(store, (state) =>
state.localStorage.filteringStates.songsPage)`, replacing the hardcoded
`'notSelected'` default.
- Add a `useEffect` that watches `filteringOrder` and calls
`storage.filteringStates.setFilteringStates('songsPage', filteringOrder)`
whenever it changes, mirroring the existing `sortingOrder` persistence effect.
- This should ensure that re-entering the Songs tab (including via the sidebar
link, which carries no search params) restores the last chosen filter value.

💡 Iterate on the plan with: `@coderabbitai` <feedback>

Example Feedback
- `@coderabbitai` You can skip phase 3. Add a simple unit test case for phase 2.
- `@coderabbitai` For design choice 1 go ahead with option 3 and replan.

---

💬 Have feedback or questions? Drop into our discord!

[Owie6789]

fixed both issues

1. the 'do not show again' checkbox was writing to the wrong preference key so it never actually suppressed the dialog
2. the songs page filter resets on tab switch now persists via localStorage like sorting does

pr is #521

[coderabbitai]

@Owie6789, I'm not able to delete comments directly. You (or another maintainer/admin) can remove it manually via the GitHub UI using the "..." menu on the comment and selecting "Delete".

(°ㅅ°)