Orphaned media after removing provider during initial sync

Issue description:

After deleting the (Dropbox) provider during an initial sync, the sync continued anyway, then afterwards I am stuck with orphaned / inaccessible songs all showing the message

[Unknown] media provider is currently offline.

This is because I deleted the media provider; it’s not really “offline” - it’s been completely deleted!

Unfortunately I did not record logs, and the process took hours of waiting for the background sync to complete. It’s not a huge issue (and the workaround is simply to clear all app data) but I wanted to report the issue in case it’s an easy / obvious edge case that could be resolved.

Sorry for lack of logs, and thanks very much for the great app.

Logs:

Upload description: no-logs-uploaded-sorry

Additional information:

 

 

Reproduction steps:

Steps to reproduce;
Add new Dropbox provider
Select a folder (eg. “Music”)
Save the new provider.
Wait a few moments and the sync will begin.
Delete the provider (while the sync is still ongoing)

Expected outcome:
The sync would stop and the provider would be removed

Actual outcome:
The provider is deleted as expected, but the sync appears to continue (a banner displays that content is being synced) and there is no way to cancel the sync (since the provider is now deleted). After the sync completes, the imported media cannot be removed or excluded via filters, because the provider is not there to de-select. The tracks show the “[Unknown] media provider is currently offline.” error.

Media provider:

Dropbox

Screenshots:

 

    

Yes there’s some very rare case it can happen.

For performance reasons since sync are the pain point for most, everything is optimized to the max leaving some checks during the sync.

You can recover by pressing Cleanup internal state in Advanced settings.

You should not clear all data, as there’s quite a few things cached like the artists data that should be kept.

I understand, thanks. That optimisation trade-off makes complete sense and it’s a rare edge case.

Thanks for the more efficient workaround and (weekend) reply!