#dsm7 — Public Fediverse posts

Ugh. Right, after *another* folder annihiliation on the Synology server I have finally figured out which app was causing the issue - I'm posting it here on the random chance someone needs help with this and comes across it.

Server: #Synology #dsm7
Program: #Sonarr 3.0.10.1567 from the main update branch and built in mechanism - as vanilla as it could be.

Evidently during an RSS synch Sonarr has failed to locate any searched items in the recordings list and has deleted my folder contents with the error "Recycling Bin has not been configured, deleting permanently". The recycling bin is available under advanced settings in media management and isn't turned on by default even if you are using the system's recycle bin - so there's no protection for this happening.

I don't know if it's linked but I had a list import error a few days ago related to #Plex authentication that shouldn't have anything to do with this but might - YMMV.

Anyway what is happening seems to be (since the last update) Sonarr has been querying the status of all 24 active shows in my list, finding no details of them somehow and deleting the folders in lieu of sending them to the recycle bin. They're not hidden, they're full on purged (already confirmed via CLI).

The reason I think it was linked to Plex is that it would happen after I had watched something on the LG OS Plex client - I suspect the act of using Plex triggered a watchlist push to the Plex server which then reported back to Sonarr. For some reason despite them not being at all related, Sonarr used that as an excuse to pull the RSS listing, find faults, and take action - there is no setting in Sonarr for deleting things in this way, it's doing it autonomously. Sonarr *can* delete empty folders if that option is enabled, but it wasn't.

Addendum: the logs indicate nothing being wrong before it starts this deletion process:
2023-08-12 07:07:54.9|Debug|Api|[GET] /api/v3/customFilter: 200.OK (13 ms)
2023-08-12 07:07:55.0|Debug|Api|[GET] /api/v3/languageprofile: 200.OK (1 ms)
2023-08-12 07:07:55.0|Debug|Api|[GET] /api/v3/qualityprofile: 200.OK (22 ms)
2023-08-12 07:07:55.0|Debug|Api|[GET] /api/v3/tag: 200.OK (28 ms)
2023-08-12 07:07:55.0|Debug|Api|[GET] /api/v3/series: 200.OK (86 ms)
2023-08-12 07:07:55.3|Debug|Api|[GET] /api/v3/importlist: 200.OK (52 ms)
2023-08-12 07:07:55.3|Debug|Api|[GET] /api/v3/config/ui: 200.OK (1 ms)
2023-08-12 07:07:55.4|Debug|Api|[GET] /api/v3/system/status: 200.OK (1 ms)
2023-08-12 07:07:56.0|Debug|Api|[GET] /api/v3/health: 200.OK (0 ms)
2023-08-12 07:07:56.0|Debug|Api|[GET] /api/v3/queue/status: 200.OK (2 ms)
2023-08-12 07:07:56.0|Debug|Api|[GET] /api/v3/config/indexer: 200.OK (1 ms)
2023-08-12 07:07:56.0|Debug|Api|[GET] /api/v3/indexer: 200.OK (10 ms)
2023-08-12 07:08:13.9|Debug|Api|[POST] /api/v3/indexer/action/newznabCategories: 200.OK (58 ms)
2023-08-12 07:08:19.6|Debug|SeriesService|Updating 0 series
2023-08-12 07:08:19.6|Debug|SeriesService|0 series updated
2023-08-12 07:08:19.6|Debug|Api|[PUT] /api/v3/series/editor: 202.Accepted (11 ms)
2023-08-12 07:08:19.8|Debug|SeriesService|Updating 0 series
2023-08-12 07:08:19.8|Debug|SeriesService|0 series updated
2023-08-12 07:08:19.8|Debug|Api|[PUT] /api/v3/series/editor: 202.Accepted (2 ms)
2023-08-12 07:08:19.9|Debug|RootFolderService|Generating list of unmapped folders
2023-08-12 07:08:19.9|Debug|RootFolderService|0 unmapped folders detected.
2023-08-12 07:08:19.9|Debug|Api|[GET] /api/v3/rootFolder: 200.OK (18 ms)