The "new items" notification (`FeedRefreshWorker.notifyNewItems`, triggered from `doWork()` around line 76-79) shows a much higher count than it should, repeatedly on every refresh rather than settling down -- and it should say "episodes", not "items".
Root cause of the inflated count: `notifyNewItems` is passed `results.filterIsInstance<FeedUpdateResult.Success>().sumOf { it.newItemCount }`, and `FeedUpdateResult.newItemCount` (`FeedUpdateResult.kt` line 9) is just `newItemIds.size` -- every item `FeedUpdateEngine.persist` didn't already find by GUID in the DB (`persist`, `FeedUpdateEngine.kt` line ~117-136).
The problem: `FeedRepository.trimToItemsToKeep` (`FeedRepository.kt` line 112-123), called right after `persist` inserts new items, deletes evicted items from the DB outright, not just marks them. If a feed's upstream RSS lists more episodes than `itemsToKeep` (the default is 20, and long-running shows routinely list hundreds), every single refresh re-fetches the same backlog, finds those older episodes no longer in the DB (since they were deleted by the previous refresh's trim), re-inserts them as "new", counts them into `newItemCount`/the notification, and then immediately evicts them again in the same pass. This repeats every refresh indefinitely -- not just once on first subscribe -- which matches "a very high number each time it is displayed."
Requested fix (count): a `FeedUpdateResult.Success` already carries both `newItemIds` and `evictedItemIds` from the same `persist` call for that feed. The notification-facing count should exclude items evicted in the same cycle they were "discovered" -- e.g. `newItemCount` becomes `newItemIds.count { it !in evictedItemIds }` (or an equivalent filter applied where `FeedRefreshWorker` sums it) -- so an old episode that gets reinserted-then-immediately-retrimmed every cycle stops being counted as new. `newItemIds` itself is also used unfiltered by `AutoQueueAndDownloadEnforcer` (`AutoQueueAndDownloadEnforcer.kt` lines 34, 42) for auto-queue/auto-download -- that's a separate, likely related latent bug (an old trimmed-and-rediscovered episode could get auto-queued/auto-downloaded repeatedly too) worth its own look, but changing `newItemIds` itself would touch that behavior; scoping this fix to `newItemCount`/the notification only avoids that.
Requested fix (wording): `notification_new_items_title` ("New items") and `notification_new_items_body` (plural: "%1$d new item(s)") in `strings.xml` (lines 228-234, and the matching `values-de/es/fr/it` translations) should say "episode(s)" instead of "item(s)" -- likely worth renaming the string keys too (`notification_new_episodes_title`/`_body`) for clarity, along with the notification channel name/description just above them, since they're all still "items" wording (`notification_new_items_channel_name`/`_channel_description`).
The "new items" notification (`FeedRefreshWorker.notifyNewItems`, triggered from `doWork()` around line 76-79) shows a much higher count than it should, repeatedly on every refresh rather than settling down -- and it should say "episodes", not "items".
Root cause of the inflated count: `notifyNewItems` is passed `results.filterIsInstance<FeedUpdateResult.Success>().sumOf { it.newItemCount }`, and `FeedUpdateResult.newItemCount` (`FeedUpdateResult.kt` line 9) is just `newItemIds.size` -- every item `FeedUpdateEngine.persist` didn't already find by GUID in the DB (`persist`, `FeedUpdateEngine.kt` line ~117-136).
The problem: `FeedRepository.trimToItemsToKeep` (`FeedRepository.kt` line 112-123), called right after `persist` inserts new items, deletes evicted items from the DB outright, not just marks them. If a feed's upstream RSS lists more episodes than `itemsToKeep` (the default is 20, and long-running shows routinely list hundreds), every single refresh re-fetches the same backlog, finds those older episodes no longer in the DB (since they were deleted by the previous refresh's trim), re-inserts them as "new", counts them into `newItemCount`/the notification, and then immediately evicts them again in the same pass. This repeats every refresh indefinitely -- not just once on first subscribe -- which matches "a very high number each time it is displayed."
Requested fix (count): a `FeedUpdateResult.Success` already carries both `newItemIds` and `evictedItemIds` from the same `persist` call for that feed. The notification-facing count should exclude items evicted in the same cycle they were "discovered" -- e.g. `newItemCount` becomes `newItemIds.count { it !in evictedItemIds }` (or an equivalent filter applied where `FeedRefreshWorker` sums it) -- so an old episode that gets reinserted-then-immediately-retrimmed every cycle stops being counted as new. `newItemIds` itself is also used unfiltered by `AutoQueueAndDownloadEnforcer` (`AutoQueueAndDownloadEnforcer.kt` lines 34, 42) for auto-queue/auto-download -- that's a separate, likely related latent bug (an old trimmed-and-rediscovered episode could get auto-queued/auto-downloaded repeatedly too) worth its own look, but changing `newItemIds` itself would touch that behavior; scoping this fix to `newItemCount`/the notification only avoids that.
Requested fix (wording): `notification_new_items_title` ("New items") and `notification_new_items_body` (plural: "%1$d new item(s)") in `strings.xml` (lines 228-234, and the matching `values-de/es/fr/it` translations) should say "episode(s)" instead of "item(s)" -- likely worth renaming the string keys too (`notification_new_episodes_title`/`_body`) for clarity, along with the notification channel name/description just above them, since they're all still "items" wording (`notification_new_items_channel_name`/`_channel_description`).