Scans so damn slow

[janmemby 5]

unfortunately very similar experience for me.

initial music scan takes forever, the system is flooded with mutliple ffprobe (see screenshot). I tried disabling all meta providers, no change, still flooded with ffprobe. i also tried latest beta, running in docker and directly on linux, but similar experience.

enclosed is log, scrrenshot of linux TOP, and few problematic mp3 files that show ffprobe error in the log.

any idea how to solve it? thanks in advance.

log and files.7z

[Luke 37188]

@janmembyare you able to try the 4.8 beta server and see how that compares?

 

[janmemby 5]

@Lukedid that, similar result.

however, the problem will most probably be that library is scanned from onedrive mounted with rclone. if i do library scan for exactly same content via local share, it finished within 20 minutes. pity, as i prefer onedrive as source.

anyway, thx for prompt feedback.

Edited December 18, 2023 by janmemby

[janmemby 5]

3 hours ago, janmemby said:

@Lukedid that, similar result.

however, the problem will most probably be that library is scanned from onedrive mounted with rclone. if i do library scan for exactly same content via local share, it finished within 20 minutes. pity, as i prefer onedrive as source.

anyway, thx for prompt feedback.

forgot to mention that i am on 1g dwl/upl link speed. so i'd expect it could work

[Luke 37188]

5 hours ago, janmemby said:

@Lukedid that, similar result.

however, the problem will most probably be that library is scanned from onedrive mounted with rclone. if i do library scan for exactly same content via local share, it finished within 20 minutes. pity, as i prefer onedrive as source.

anyway, thx for prompt feedback.

Server log from 4.8? 

But yes scanning rclone will be slower than a local drive, for obvious reasons.

[janmemby 5]

device got frozen and log was not available. 

i am already with local storage and scan works perfectly on beta. if u r interested, can share the log of that one.