Allow the rescan process to be stopped

[mprachar]

my rescans take over an hour - the fact that the refresh button inside an artist causes a rescan of the entire root folder makes it easy to accidentally kick one off.

[ta264]

You can stop it from the tasks page can't you?

[mprachar]

I just tried it about 20 minutes ago on the current nightly and it didn't appear that clicking anywhere on the running task did anything. There's no Little X off to the right of that particular task. Best Regards, Mike Nobody cares about how this message was sent.

…

________________________________ From: ta264 <notifications@github.com> Sent: Saturday, March 7, 2020 11:26:44 AM To: lidarr/Lidarr <Lidarr@noreply.github.com> Cc: Mike Prachar <mike@prachar.com>; Author <author@noreply.github.com> Subject: Re: [lidarr/Lidarr] Allow the rescan process to be stopped (#1105) You can stop it from the tasks page can't you? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#1105>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFOEDLHKJIPMZZOPYDIS62LRGKNXJANCNFSM4LDSJXMA>.

[ta264]

Hmm I'll investigate that.

Is like to understand the root cause of what the scans are so slow though. Do you have a huge number of unmapped files? Or is there a more serious bug I need to address?

[mprachar]

So, when I do a refresh artist, it scans my entire root folder – not just the artist. I have around 30K tracks in the root and I use a NAS on USB 3.1. I get decent performance, but heavy disk i/o operations are naturally slower. It’s not a problem except in outlying cases like this. [cid:image002.png@01D5F47F.A6AA24D0] Best Regards, Mike From: ta264 <notifications@github.com> Sent: Saturday, March 7, 2020 12:23 PM To: lidarr/Lidarr <Lidarr@noreply.github.com> Cc: Mike Prachar <mike@prachar.com>; Author <author@noreply.github.com> Subject: Re: [lidarr/Lidarr] Allow the rescan process to be stopped (#1105) Hmm I'll investigate that. Is like to understand the root cause of what the scans are so slow though. Do you have a huge number of unmapped files? Or is there a more serious bug I need to address? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#1105>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFOEDLEPWGHKUMXPYNKI2BLRGKUJFANCNFSM4LDSJXMA>.

[ta264]

Scanning the whole root folder is by design - lidarr is now much more flexible about where files can be located.

It should only be scanning files that are "new", or, in the case that the refresh updated some metadata, files that are not matched against tracks already. For reference, my library is 20k tracks and they're all matched. A scan takes 6 seconds.

If the scan if just slow because you have a lot of unmatched files then I should perhaps make lidarr less eager to scan unmatched files again. If that's not the case then I think there might be some other issue I should address. Either way, being able to cancel the task is just a bandaid and I'd like to figure out the "real" solution

[mprachar]

Got it. Is there a sort of more verbose logging that I should turn on where maybe I can identify what it's finding is making us can take 2 hours? I don't mind looking through log files and identifying that type of issue. My unmapped file section does actually show thousands and thousands of files that are unmapped, but they also don't exist. It's actually referencing an old root folder that is no longer in the system, but the unmapped files section still has the files there. Not sure how to get rid of them. Best Regards, Mike Nobody cares about how this message was sent.

…

________________________________ From: ta264 <notifications@github.com> Sent: Saturday, March 7, 2020 1:25:37 PM To: lidarr/Lidarr <Lidarr@noreply.github.com> Cc: Mike Prachar <mike@prachar.com>; Author <author@noreply.github.com> Subject: Re: [lidarr/Lidarr] Allow the rescan process to be stopped (#1105) Scanning the whole root folder is by design - lidarr is now much more flexible about where files can be located. It should only be scanning files that are "new", or, in the case that the refresh updated some metadata, files that are not matched against tracks already. For reference, my library is 20k tracks and they're all matched. A scan takes 6 seconds. If the scan if just slow because you have a lot of unmatched files then I should perhaps make lidarr less eager to scan unmatched files again. If that's not the case then I think there might be some other issue I should address. Either way, being able to cancel the task is just a bandaid and I'd like to figure out the "real" solution — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#1105>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFOEDLHAOLDLPQWSZTCHHKLRGK3VDANCNFSM4LDSJXMA>.

[mprachar]

So I added an album after searching it, and that kicked off the full rescan again. I can just restart the Lidarr service, but could that introduce data corruption? Best Regards, Mike From: ta264 <notifications@github.com> Sent: Saturday, March 7, 2020 1:26 PM To: lidarr/Lidarr <Lidarr@noreply.github.com> Cc: Mike Prachar <mike@prachar.com>; Author <author@noreply.github.com> Subject: Re: [lidarr/Lidarr] Allow the rescan process to be stopped (#1105) Scanning the whole root folder is by design - lidarr is now much more flexible about where files can be located. It should only be scanning files that are "new", or, in the case that the refresh updated some metadata, files that are not matched against tracks already. For reference, my library is 20k tracks and they're all matched. A scan takes 6 seconds. If the scan if just slow because you have a lot of unmatched files then I should perhaps make lidarr less eager to scan unmatched files again. If that's not the case then I think there might be some other issue I should address. Either way, being able to cancel the task is just a bandaid and I'd like to figure out the "real" solution — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub<#1105>, or unsubscribe<https://github.com/notifications/unsubscribe-auth/AFOEDLHAOLDLPQWSZTCHHKLRGK3VDANCNFSM4LDSJXMA>.

[CHlLL7]

I'm having the same issue. But my scan takes about 3-4 hours with 8000 files. Also, there in the task queue there is like 50 more rescan folders. I can delete them but they keep reappearing.

[DunklerPhoenix]

Same for me. It needs about 1,5 hours to scan 46k files.
If I manualy edit an album, lidarr will scan the whole root folder.
In this time I can't import anything

[IwishIcanFLighT]

Would greatly appreciate this feature as well. With big music libraries, the scan take literally hours to finish, greatly impacting CPU and disk usage. The perfect way would be to have option to set an interval between scan, only manual scan, and ability to cancel scan. Thanks!

[ta264]

I don't plan to allow the scan to be cancelled, but hopefully #1540 and #1508 means there's no longer a real need for it.