Scanning Media Library is incredibly slow #3722
Comments
|
It's likely not stuck, upgrading to 10.6 causes a blurhash to be generated for every image. After the initial scan on 10.6 future scans should be normal speed. |
|
Looks like you might be right, but something is terribly wrong with performance. How it could be this slow... In log look at time gap between entries. I've been running it on 3.4GHz 24-Core CPU with 32GB RAM for 7 hours and the progress haven't increased even by 0.01% |
|
Same issue I am having. I have a fresh installation (first impression of Jellyfin isn't that great). I have only 4 movies in a folder and it has not completed scanning of 1 file. |
|
I have 15K Movies and 800 TV Shows and its taking 5 to 7 days to scan new library, its running on 20 Cores Xeon server with 388 GB RAM with P5000 Graphics Card. Something needs to be done for future release to address this issue... |
@crobibero This unfortunately doesn't appear to be the case. The first library scan after 10.6 took almost 10 hours to complete, but instead of subsequent scans performing at pre-10.6 speeds, a scan of my movie library, for example, with only one new movie added takes several hours to complete where previously it would finish in under a minute. |
|
Is this still an issue in 10.6.2? |
|
@cvium Yes. |
|
Any improvements? Scanning is pretty fast for me, but I only have 400 movies and 5000 episodes. |
|
@cvium I started a new library scan yesterday and unfortunately it still takes several hours to complete each time. |
davispuh
changed the title
|
Well the main issue I submitted was about library scanning being stuck. It didn't advance not even by I don't know if my scanning completed because of update to 10.6.2 or because it's been more than a week of library scanning :D |
|
@davispuh Can you start a new library scan and see how long it takes to complete? |
|
Well after first scan has been completed rescanning isn't that bad. Takes 21mins. So I guess first scan is just super slow or after update from 10.5 to 10.6
|
|
I'm curious if this is related to an issue I found - for those with slow scans, do you have a lot of movie files located within the same directory? (i.e. each movie is not in its own directory)? |
|
I put in 5 movies and tried a fresh install. After 12 hours I cancelled it and deleted the software. |
Not movies, but I've photo library where couple of hundred photos in each folder. |
@bugfixin No, each movie has its own folder. |
@doughnet You did a fresh install and added a library with only 5 movies and it didn't complete the scan within the 12 hours? |
Correct. I've used Plex since it's beta years. But I dislike their limitations on how many sharing users can be done so looking for an alternative. I did a fresh install at home on a fresh OS (Ubuntu 20.04 LXC Proxmox) and am passing through my graphics card being shared by all my LXC. Did a fresh install and made a local (not even Shared network) folder with 5 movies that were x265 codec. I let it run over night and later in the day I killed the VM since it had not progressed any percentage. Try adding a new library with 1 movie and see how long it takes. |
|
@doughnet it sounds like you're running into the same issue found here: #3558 (comment) - are you able/willing to build jellyfin yourself for testing the solution? |
doing a native build right now. i assume that is what you are requesting. EDIT: Finished doing ./build.sh -t native -p ubuntu.amd64 now what to do? |
|
You'll have to install it and run it, e.g. via apt install ./jellyfin-server_10.6.*.deb (after uninstalling the existing jellyfin-server) - though I'm not certain of the details for doing it on ubuntu specifically. |
|
I don't see a .deb rile after the build. There a specific location it's at after building? |
|
It might be somewhere like ~/bin/ubuntu.amd64 |
|
I've been keeping an eye on the time it takes for the periodic library scans to complete for the past few days and have observed that it has stayed completely consistent. The scheduled task runs at midnight every day and always takes 10 hours to complete with zero new media added inbetween scans. I've been using Jellyfin since March 2019 on the same hardware and never experienced library scans this long prior to upgrading to 10.6.0+. |
|
@whalehub How did you install jf and what's the OS etc.? |
|
@cvium I'm running Jellyfin inside Docker on Debian 10 using the linuxserver.io image. Jellyfin is served behind Nginx. |
|
@whalehub I am wondering if you're encountering the same issue as doughnet albeit in a smaller scale. Lsio uses our .deb file, which I suspect is built using an old SDK, where threads can deadlock. |
|
@cvium Should I give the official Jellyfin image a try? Edit: I just tested the official Docker image and it suffers from the same issue. |
|
This bug has been known for a while now, so it would be helpful if you would include version number, size of library, number of users etc. If the slow scanning is related to users, then it should be fixed in 10.7 RC. If any of you would be willing to backup your 10.6 install and try out the RC release, it would be very helpful. Some parts of the scanning has also been parallelized in 10.7 RC. |
|
I had this problem with 10.6.4 and I could not wait any longer so I decided to install 10.7.0~RC3. The scan's and search's duration are back to normal and everything is snappier. I do not have any other issue with this release candidate by the way, it is perfect. |
|
Based on #4364 (comment) I think it's safe to close this issue. Let me know if it's still a problem in the RC. |
|
I'm still experiencing this issue with 10.7.7. I'm running jellyfin on a Raspberry Pi model 3B. It's a fresh setup, and I'm scanning a library of 168 movies. The system does not show high cpu or network load. There are occasional 'bursts' of cpu load with 30%. Most of the time the system is just idling. |
|
|
Same problem with 10.8.0-RC from last week. The media scan takes 2 hours every day on 9:30 o'clock on my setup. During this time the inotify functionality will be disabled and new files won't show up in the library. Two threads of Jellyfin consumes two cores of the CPU for 100%. and the last line in the log during this time is This is all on a AMD Ryzen 5 PRO 4650G 6-Core Processor, not a Raspberry Pi or any other underpowered device. |
|
I have a dedicated Jellyfin server on native Debian 11 (no VM and no docker) with i9 9900K (8 cores 16 thread) 64GB of RAM all is very fast but Jellyfin front-end become unusable slow forever when I add large number of TV Show. I must restart the service AND launch a full scan to repair... There is a bug for sure. Software become slow without any ressources usage ! |
|
Same problem here. I'm new to Jellyfin and installed version 10.7.7. Library Scan took 2 days for 917 Movies, 7000 Songs, 2125 Episodes of Series. That's really frustrating. How can this be "closed"? |
|
Hmm. |
|
Why has this issue been closed? Scanning renders jellyfin completely unusable until it has completed, even on NVME/optane. How is that acceptable? |
|
? It is stated above that users should advise if this is a problem... it is |
|
This issue is over 2 years old. We have made many changes since. It does not mean that all issues are resolved, but the original issue was reported to be solved. Hence, it was closed. |
|
It doesn't make sense to close an issue that is still so severe -- my first scan of a 12TB Kodi library is almost at 2 days, and I see countless mentions across forums about this still being a problem. I'm not an engineer. But perhaps someone could find a way to pinpoint the biggest bottlenecks in the current scan process so that progress can be made. Based on what I've read elsewhere (like this reddit post from 3 months ago), I gather that one contributing factor could be:
Another idea I've seen posted around are that perhaps an await call is hard-blocking the whole server. This would make some sense given that the CPU/RAM usage are low throughout:
As for why that would make the UI slow:
Edit: FYI to anyone reading this, I see there's a duplicate issue here that's still open: #2600 If you combine the comment count from both issues, this is by far the most commented issue outstanding and one that likely sends many first-timers to Plex. |
|
When I opened this issue then it was Also it's that I stopped caring and I think that's the case for most people, we have just accepted that's how it is and how it's been for many years. Basically someone needs to put some serious time into looking into why it's so slow and I don't think anyone has really worked on it. And it's not just about first scan either, even next scans seems to be quite slow and it's making whole Web UI slow whenever it's scanning. |
|
+1 for "And it's not just about first scan either, even next scans seems to be quite slow and it's making whole Web UI slow whenever it's scanning." the webserver process should not be slowed down by another task, especially since the processor load never exceeds a few percent on a core i9. |
|
How can I increase logging to get helpful information about what's going on with the library scan? 10.9.0 daily on Debian Bullseye. From the existing log, I see ffprobe doing bursts of about 20 files every 3-4 hours. Each ffprobe takes approximately 0.09 seconds, and the jellyfin processes are using close to 0% CPU and disk I/O is trivial most of the time. If I strace the processes/threads they're mostly all calling futex() waiting on locks from each other, checking the dotnet CLR pipes in /tmp somewhat often. Once in a while something touches library.db but it's usually something like an hour between writes. Seems like something is deadlocked and something is waking it up on occasion, but certainly I don't know this codebase well enough to guess. At the current rate the music library will be done scanning in about six weeks. As far as the hardware, if I use the same command to probe the music library, it finishes in under ten minutes: |
|
The media scanning and webserver contention is still at issue, and becomes a showstopper on large libraries. This issue really shouldn't be marked as closed. |
|
Slow on scanning / and on dashboard even on a core i9 with a lot unused core !!!!! a process management problem... |
|
I'm digging into the code to see if I can get an idea about where the problem is. It is not: CPU, IO or network bound. There seems to be some sort of contention between the web-server thread that generates the HTML for the browser and the media scanner (thread? async?). it is not yet clear to me if it is a shared database or data structure or where contention is arising. |
|
When I delete a huge music library, when it go to 99.8% and log activity slow down for the same work, I get very slow GUI responses, I tryed (system.xml) : (because it run on a 8 core / 16 threads) |
|
I try also : (to make 4 thread for 1 logical core) Scan mush faster and I get a better CPU usage, and same GUI response... I make more try when my huge music library is not on the jellyfin database anymore. Because delete is very slow. |
|
To remove about 600000 music file on a powerfull i9 server where library.db is on a fast SSD ; I need to temporally re-mount the filesystem with write barrier=0 (unsafe) to get a huge bump in performance. the library.db size is 2.5GB with music and down to 1GB without music. I remove barrier=0 when scan finished. Without this trick the web interface get unusable for few days ! |
This comment was marked as abuse.
This comment was marked as abuse.
|
Are there any maintainers available to reopen this issue? It should not be closed as this remains a major problem (and likely the main showstopper for new users). See also |
|
@felix920506 Is the other issue intended as the place for all discussion about slow scanning problems? My understanding is that #2600 ("Very slow initial Library scan") is specifically about the first/setup scan being extremely slow, but this issue is about usually slow scan operations on existing libraries - e.g. the last few comments just above mention slowdown when items were deleted from a library |
and others
Describe the bug
After update to 10.6.0 library scanning seems to be stuck. It had all scanned previously.
In logs didn't saw anything useful just #3611
And there's thousands of
OnRefreshStart/OnRefreshCompletelines in log.System:
To Reproduce
Expected behavior
Complete library scanning successfully.
Logs
Screenshots
The text was updated successfully, but these errors were encountered: