It’s extremely time-, storage-, and compute-expensive to generate images for an entire library before-hand. In my case it’s doing all this work for tons of content that I might not even watch again.
I guess the idea is that there’s no delay in the images being available as soon as the programme is started?
I’m not sure the trade-off is worth it.
For anyone else like me that hasn’t updated yet and/or generally unfamiliar with the term “Trickplay”, it’s the handy feature that allows you to hover over the progress bar and see snapshots of the content at various times.
Just commenting as a public service since I had to search around a bit before I found an actual description.
Well, you can enable it per-library, also Storage is not that much, I scalled down to 160p tho for my needs it’s more than enough
But for my library, it took a few weeks, but I limited the number of ffmpeg thread to 3-4.
It took about a week to generate for my library without hardware-accelerated MJPEG generation, at the default resolution in the Trickplay configuration. I let it use 8 threads but CPU use was close to nothing the whole time, even with priority bumped up to above normal.
It wound up consuming about 10GB of storage by the time it was done, for a library of 2.6TB. My library is mostly 1080p stuff, a mix of h.264 and x265.
Well all the same, except for the number of thread. in the end (at around80%) I bumbed the threads to 15, and CPU was still the same in the consumption, however, there were 15 ffmpeg process. so maybe a but in the jellyfin-ffmpeg package ? or maybe I’m missing something here
