Upgrading in Yunohost with a custom library location

[zecamigo]

Hey there!

I have Navidrome installed in Yunohost on a local machine.
Currently running 0.49.3 (yunohost version).
The Music library is located in an external drive which is always mounted.

After I upgrade version, because the config file is respawn, Navidrome searches for files in the default location, which is empty, and deletes orphaned files, along with playlists and favorites. Even after I change the config back to my custom path, these are not restored.

Something similar seems to happen to other people, in slightly different situations.
I've described this here: #1916

A log of a previous attempt can be found here:
https://paste.yunohost.org/vatofuboba.vbs

Any idea of why this might happen?
Thanks in advance.

[metalheim]

You mentioned:

because the config file is respawn

If the config file is changed, navidrome acts accordingly.
Dont change your config file then. I upgraded navidrome many times without ever loosing data (although a backup of config file and database is always advised).
I think the main point of solving this issue is figuring out why your config file was changed.
You should have your config file in a persistent state (so that its not overwritten/changed during a navidrome upgrade).

Please ask the Maintainer of the Yunohost Navidrome package how it works and why this happens:
https://github.com/YunoHost-Apps/navidrome_ynh

EDIT: I see that you already commented on the Yunohost package issue regarding this:
YunoHost-Apps/navidrome_ynh#75
Anyways - Yunohost should not overwrite your config file on an upgrade (deleting data that you as a user has put in.

Anyways, maybe navidrome can be improved so that it aborts any scan+cleanup if the musicdir is empty

[metalheim]

@deluan It seems the "if folder is empty -> abort scan" check is only done when doing a quick scan.

navidrome/scanner/tag_scanner.go

Line 89 in cdccdc5

if empty && !fullScan {

But on a Navidrome version upgrade, navidrome will launch a full scan automatically after startup, right?
So this check is basically not used for the issue described by @zecamigo

[deluan]

@deluan It seems the "if folder is empty -> abort scan" check is only done when doing a quick scan.

Yeah, don't remember why I did it like that. I'll check it out.

[zecamigo]

Thanks @deluan, I would appreciate it.

[zecamigo]

The issue seems to be fixed in version 0.51.1
Thanks @deluan @metalheim