Initial media scan taking a very long time

[Greyson Parrelli]

Hi there, I'm performing the initial media scan, and it's taking an incredibly long time. Like, 12+ hours. I have a low-thousands number of videos (~1k movies, probably another 1k files of tv shows).

Here's my machine details:

Code:

OS: Ubuntu 25.04 x86_64
Kernel: 6.14.0-15-generic
CPU: Intel N150 (4) @ 3.600GHz
RAM: 16 GiB

Here's a snippet of the end of my log:
https://pastebin.com/1A33Asyc

Here's my docker compose file:

Code:

services:
  jellyfin:
    image: jellyfin/jellyfin
    container_name: jellyfin
    network_mode: 'host'
    volumes:
      - ./config:/config
      - ./cache:/cache
      - type: bind
        source: <redacted>
        target: /movies
        read_only: true
      - type: bind
        source: <redacted>
        target: /tv
        read_only: true
    restart: 'unless-stopped'
    environment:
      - JELLYFIN_PublishedServerUrl=<redacted>
    devices:
    - /dev/dri:/dev/dri

Looking at my logs, it seems like the ffprobe stuff may be taking an inconsistent amount of time? But if I docker exec -it jellyfin /bin/bash into it, then run the command myself, it completes essentially instantaneously.

What might be the reason that there's large swaths of seeming-inactivity in-between commands?

I will say that the annoying bit is that while this scan is happening, the rest of jellyfin is basically unusable. Like, the home screen and media viewer in general won't load. I can only see the admin screens and such.

And no, I do not have the chapter extraction or anything enabled : ) From my research, I know that's a common cause of issues, but I don't believe it's the cause here.

Thanks!

[bitmap]

Did you enable chapter image extraction and trickplay right off the bat? Both of these will SIGNIFICANTLY slow down the initial scan.

Derp. Should've read all the way to the end. Gimme a sec to go back and re-read.

Okay -- could still be trickplay. Double check on this one. Also, any extra plugins enabled?

What might be the reason that there's large swaths of seeming-inactivity in-between commands?

Well, you have IO errors that are causing this. Any idea what else could be using the files in question? There are quite a few of them:

Code:

[20:53:34] [ERR] [18] MediaBrowser.Providers.Manager.ProviderManager: IOException saving to /config/metadata/People/J/John Sanford/folder.jpg. Will retry saving to /config/metadata/library/14/1407e979a5adc9209791c1d8b06914ab/folder.jpg
System.IO.IOException: The process cannot access the file '/config/metadata/People/J/John Sanford/folder.jpg' because it is being used by another process.

[Greyson Parrelli]

Thank you for the response!

No trickplay enabled either (I left pretty much everything at the default, and trickplay + chapter stuff all default to off).

Well, you have IO errors that are causing this. Any idea what else could be using the files in question? There are quite a few of them:

I agree, those did look suspicious. But looking through my latest logs, I'm seeing far less of them, and while things started progressing faster (I made about 40% progress in the last 3 hours, which while still very long, is much faster than before), there are still gaps where a bunch of ffprobe commands take no time, followed by one that takes a full minute, halting progress, with no IOExceptions involved. Quite odd.

I also have no idea what other processes could be touching that folder. It's a folder I created just for this image, and I confirmed I didn't accidentally start multiple copies of the image or anything. When I was researching it, I did find this issue that's still open where other people are having a similar problem:
https://github.com/jellyfin/jellyfin/issues/13728

I imagine I'll get through this first scan eventually, just a bummer that it's taking so long. But more so, it's a bummer that jellyfin is basically unusable during the scan. I'm hoping subsequent scans are faster and less disruptive