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.

  • Jimbabwe@lemmy.world
    link
    fedilink
    English
    arrow-up
    9
    ·
    7 months ago

    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.

  • Krafting@lemmy.world
    link
    fedilink
    English
    arrow-up
    4
    arrow-down
    1
    ·
    7 months ago

    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.

    • st3ph3n
      link
      fedilink
      English
      arrow-up
      2
      ·
      7 months ago

      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.

      • Krafting@lemmy.world
        link
        fedilink
        English
        arrow-up
        2
        ·
        7 months ago

        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

  • Ptsf@lemmy.world
    link
    fedilink
    English
    arrow-up
    1
    ·
    5 months ago

    If it’s time, storage, and compute sensitive to generate it beforehand why on this green earth would you want to do it at stream runtime? Do you enjoy the thought of waiting 5-10 minutes for a stream to start or causing continual buffering problems during the stream? Also to my understanding the way it is built requires that the encoding be done for the entire length of the stream before any benefits are shown, so starting the process at stream launch would be less than useful even under the best circumstances. I think what you want to do is to sort your library into two, one you want to watch, and an archive. From there you can enable trickplay on just the “want to watch” library.