Skip to content

Fix library items not being deletes after providers have removed them#3154

Open
MarvinSchenkel wants to merge 5 commits intodevfrom
library_sync_improvements
Open

Fix library items not being deletes after providers have removed them#3154
MarvinSchenkel wants to merge 5 commits intodevfrom
library_sync_improvements

Conversation

@MarvinSchenkel
Copy link
Contributor

This PR:

  • Re adds the library changes from this commit: 1b60a3c
  • Adds a migration script that sets all current provider mappings of streaming providers to in_library = True to avoid losing items in the overview pages
  • Adds a new advanced property to music providers 'sync back deletions' (default enabled). When disabled, library deletions are not processed from the music provider. This supports a use case where a user mainly uses MA for library management.
  • Adds tests for library syncing

Comment on lines +454 to +455
if provider and isinstance(provider, MusicProvider) and provider.is_streaming_provider:
extra_entries.append(CONF_ENTRY_LIBRARY_SYNC_DELETIONS)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
if provider and isinstance(provider, MusicProvider) and provider.is_streaming_provider:
extra_entries.append(CONF_ENTRY_LIBRARY_SYNC_DELETIONS)
if provider and isinstance(provider, MusicProvider) and provider.is_streaming_provider:
extra_entries.append(CONF_ENTRY_LIBRARY_SYNC_DELETIONS)

I think you also need that edit check from above ?

Copy link
Contributor Author

@MarvinSchenkel MarvinSchenkel Feb 13, 2026

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why? The former is to sync back additions in MA > Streaming provider. The new toggle prevents deletions in the streaming provider from flowing back into MA.

I think this behaviour does not depend on a music provider supporting writing back library changes from MA > the Streaming provider?

So:

  • Music provider does not support LIBRARY_EDIT_XX
  • User disables sync back deletions
  • User adds Album X in MA
  • User adds Album X in music provider
  • User removes Album X in music provider
  • User syncs the music provider -> Should not delete Album X in MA

ctrl = self.get_controller(media_type)
library_id = media_item.item_id if media_item.provider == "library" else None

# cache in_library state before the provider fetch overwrites media_item
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

can you walk me through why this is needed ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Without it, when you refresh an item, provider mapping's in library status is not maintained. It re-adds them with in_library = None causing them to disappear from the overview pages. This logic basically restores the original statuses after a refresh.

for prov_map in library_item.provider_mappings:
if prov_map.provider_instance == self.instance_id:
prov_map.in_library = False
await controller.set_provider_mappings(
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Now, within set_provider_mappings we can do an additional check (which we may already do, I'm not sure): If the item has no mappings anymore AND it is not referenced in any of the link tables (e.g. track artists etc) we can safely clean it up from db

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we already delete those records from the link tables? Because otherwise this check will never be True if we keep for example track_artist records for tracks without any in_library provider mappings?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there is already some logic to handle that yeah

MarvinSchenkel and others added 2 commits February 13, 2026 10:19
Co-authored-by: Marcel van der Veldt <m.vanderveldt@outlook.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants