Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Resume library scan in event of blackout #1418

Closed
zardini123 opened this issue Oct 19, 2021 · 11 comments
Closed

Resume library scan in event of blackout #1418

zardini123 opened this issue Oct 19, 2021 · 11 comments

Comments

@zardini123
Copy link

zardini123 commented Oct 19, 2021

Is your feature request related to a problem? Please describe.

I recently updated Navidrome from 0.44.0 to 0.46.0. I noticed Navidrome via the output started a library rescan by noticing that old folders that have not been touched since library inception are being rescanned as a "changed folder." I assume this is due to the update, and therefore guessing what Navidrome is doing is a required scan due to the update.

I run Navidrome off of a Raspberry Pi (RPi). I found recently that RPi's have a hardware watchdog that can detect when a system is frozen, it will do a hardware reset (a reboot). I enabled it after updating Navidrome, and found Navidrome was setting off the watchdog consistently after an hour or 2.

After every reboot due to the watchdog, Navidrome restarted scanning the folders from the beginning.

Describe the solution you'd like

If Navidrome was able to resume scanning from where it was instead of restarting, that would be really great. For people like me where stability of their system is not guaranteed, this would help dramatically with large libraries.

@deluan
Copy link
Member

deluan commented Oct 19, 2021

This actually affects me as well. My library is hosted in GDrive, so a full scan takes up to 4 days for me, and I constantly have to interrupt it to test out new features when I'm working on Navidrome. I already spent some time thinking about this and couldn't find a way to do it without making the scan process slower or less reliable. Will have another look.

I assume this is due to the update, and therefore guessing what Navidrome is doing is a required scan due to the update.

Yes, usually when a full rescan is required, you can see in the logs something like this when starting Navidrome after upgrade:

DEBU[0000] Opening DataBase                              dbPath="data/local/navidrome.db?cache=shared&_busy_timeout=15000&_journal_mode=WAL&_foreign_keys=on" driver=sqlite3

*************************************************************************************
NOTICE: A full rescan needs to be performed to import more tags
*************************************************************************************

INFO[0000] OK    20210821212604_add_mediafile_channels.go 
INFO[0000] goose: no migrations to run. current version: 20210821212604 
INFO[0000] Configuring Media Folder                      name="Music Library" path=/Users/deluan/Music/Music/Media

@zardini123
Copy link
Author

zardini123 commented Oct 19, 2021

Hi @deluan! Thank you very much for your reply!

I was thinking, where does Navidrome store information regarding its current scan? I find it odd that everything its scanned is simply lost upon a blackout. Is the information possibly stored somewhere in RAM or /tmp, being lost upon restart? Being you stated you interrupt Navidrome, therefore my guess is its in volatile memory, but that wouldn't make sense for low RAM large library situations.

When thinking about this, I came up with an idea, and I'm curious to see what you think. What if:

  1. Upon start of a library scan (especially a scan upon version upgrade), a clone of the database is created.
  2. The copy database is cleared of all scanned media.
  3. The directory walk starts, but checks against the cloned database to see if the file exists yet. If it does, continue walk. If it doesn't, store tags/information.
  4. In event of Navidrome restarting (due to a blackout, kill, etc), the walk will simply walk through and do the relatively intensive operations of probing once it reaches a new file.
  5. Upon completion, the clone and original databases are swapped. The old database could conveniently be thrown into a backup folder, marked with the Navidrome version number it was created with.

This method would cover the edge case of new files being added between the time of the blackout, and the reboot. The backup folder would also be very advantageous for potential database corruptions due to upgrades. I actually moved from Airsonic to Navidrome because Airsonic would corrupt my database upon every upgrade.

Curious to hear what you think!

Side note: Is there a way currently to temporarily disable the upgrade rescan? Or more preferably, is there a way to disable scan outright? Navidrome is working great even without a full rescan finished yet, and even my Subsonic clients have no problem with it. I'd like to save my hard drive from wear until either I can find the source of why Navidrome is tripping the watchdog, or Navidrome can restart scan from its last point.

@deluan
Copy link
Member

deluan commented Oct 24, 2021

I was thinking, where does Navidrome store information regarding its current scan.

It does not compare each file to their counterpart in the DB. Instead, it uses a single lastUpdatedTime that is compared with all files modification times. It actually update the DB for each folder processed, but it restart from scratch because it only store the lastUpdatedTime at the end of the whole process. So if you interrupt and start again, it still have the old lastUpdatedTime and consider all changes that were already processed as new changes.

The idea of using a cloned DB has one main drawback: While the scan is not complete the original DB would need to be set to read-only, and would not register plays/scrobbles, stars, ratings, playlist changes, etc... as any change would be lost when the scan is completed. And scan can take up to 4 days (in my case) or more!

Or more preferably, is there a way to disable scan outright?

Yes! Just set ScanSchedule="0" in your config options. This completely disable scans, and you will have to trigger it manually with one of these options:

  1. Use a quick or full scan form the Activity Panel
  2. send a SIGUSR1 to Navidrome's process (does not work on Windows). It will be a quick scan
  3. Use a Subsonic client that supports triggering scan. It will be a quick scan
  4. If you use beets, it ahs a Subsonic Update plugin that triggers a (quick) scan after any library modifications

Quick scan: Take lastUpdatedTime into consideration, only import changed/deleted files
Full scan: Ignore lastUpdateTime import everything

If there is a pending upgrade scan, it will be a full scan even if you trigger quick

@zardini123
Copy link
Author

It actually update the DB for each folder processed, but it restart from scratch because it only store the lastUpdatedTime at the end of the whole process. So if you interrupt and start again, it still have the old lastUpdatedTime and consider all changes that were already processed as new changes.

That is very interesting. I'm rather confused why it doesn't just update the lastUpdatedTime as it updates for a full scan. If the information has been stored and is there, why does it need to redo it?

Yes! Just set ScanSchedule="0" in your config options. This completely disable scans, and you will have to trigger it manually with one of these options:

Thank you, this is very useful information!

I enabled it after updating Navidrome, and found Navidrome was setting off the watchdog consistently after an hour or 2.

Just as a side note, I updated my raspberry pi to the most recent packages and now the watchdog tripping due to Navidrome is non-existent. Must of been an a related or non-related outdated package causing kernel issues.

@deluan
Copy link
Member

deluan commented Oct 24, 2021

Just as a side note, I updated my raspberry pi to the most recent packages and now the watchdog tripping due to Navidrome is non-existent. Must of been an a related or non-related outdated package causing kernel issues.

Great! Should we close this?

@zardini123
Copy link
Author

The enhancement is still of value, no? For example users who are unable to keep their host up running 24/7 and shut them down daily, like in the instance of running Navidrome off of a home, work computer.

@deluan
Copy link
Member

deluan commented Oct 25, 2021

Ok, makes sense... Just don't know how to improve this without incurring in a performance hit. Will keep it open as a reminder.

@deluan deluan added the go Go code label Oct 25, 2021
@zardini123
Copy link
Author

Yeah I'd love to try and help in some way. I'd take me a while to learn the code base, being also I'm juggling other work. Thank you!

@legobuild
Copy link

legobuild commented Apr 15, 2022

I have an issue that I think is related to this:

I had a power failure this week, which resulted in Navidrome wiping my library. My music is stored on a NAS and Navidrome on a server running 24/7 (music folder is mounted on the server via NFS). I wasn't home, but believe we lost power and the NAS shutdown based on command from my UPS. Everything restarted on its own when power came back on, but now my library is empty in Navidrome. Running a full sync brings everything back, but playlists are still blank. Any suggestion on what I should do to avoid that situation?

@github-actions
Copy link

github-actions bot commented Mar 7, 2023

This issue has been automatically marked as stale because it has not had recent activity. The resources of the Navidrome team are limited, and so we are asking for your help.
If this is a bug and you can still reproduce this error on the master branch, please reply with all of the information you have about it in order to keep the issue open.
If this is a feature request, and you feel that it is still relevant and valuable, please tell us why.
This issue will automatically be closed in the near future if no further activity occurs. Thank you for all your contributions.

@github-actions github-actions bot added the stale label Mar 7, 2023
@github-actions github-actions bot closed this as not planned Won't fix, can't repro, duplicate, stale Apr 8, 2023
@github-actions
Copy link

github-actions bot commented Aug 7, 2023

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Aug 7, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

3 participants