Zurgling
Radarr and Sonarr can get "bogged down" when working through a big queue, because they are built to "ffprobe" each media file before importing, to determine codec, resolution, channels, and duration (this is how they try to avoid samples).
If the media is local, this is usually not an issue, but in cloud-storage-land, where every probe of a file (and sometimes there are multiple!) represents an API call and an HTTPS download via Zurg, Debridav, etc, this process can slow down importing significantly. Worse, if a queued item stalls on import, this can affect the importing of subsequent items, cause unhelpful retries on the rclone mount, more import delays, and general confusion.
Here in the ElfLab, we've been working on a new project - a way to "fake" ffprobe on the Aars, so that they won't need to read each file on import, but the important details can still be inferred based on the filename. The primary motivation here is to speed up the processing of media from EasyNews using Debridav, which can be slow and error-prone based on the responses from EasyNews themselves.
We've got our project ready to test - it's a "shim", taking the place of the actual ffprobe in the Aars, and returning "good-enough" fake data based on filename parsing.
In tests, we managed to import 780 episodes from a 37-season series in 16 minutes, or an average of 1 file imported every 1.2 seconds!
However.. it's not clear whether there will be any unforseen downsides to this fakery.. so we're making it opt-in for now, so that power-users / bleeding-edgers can experiment and give us feedback, but that we don't break the slow-steady-and-stable Aars for the users who'd prefer stability over speed.
To turn on the shim for your aars, you'd use ElfBot to run (in this example, for radarr):
elfbot env radarr USE_FFPROBE_SHIM=true
You can do this per-arr, and you can set it to false to back out if you change your mind.
Yours in speedy importing! âš¡