Trickplay and Chapter Images storage location.

[ggfool]

A solution to your problem would be to exclude the folders from the backup process. If you're on Linux, you can use rsync and tell it to ignore all folders and files under folders named "trickplay".

my backup solution does not support wildcard folder exclusions so this is not possible, on top of that i'd rather not use up a significant portion of my SSD to store trickplay data when it could just as easily be stored on my array where it is an insignificant amount of data.

i've gone back to using jellyfin 10.8 for now.

[dkadavarath]

Is there an existing feature request for this? I'm already quite annoyed with the subtitle extraction keeping the data in the metadata folders with no human readable way to extract it, now jellyscrub - which was working fine perfectly is ruined too.

[Efficient_Good_5784]

https://features.jellyfin.org/posts/2668...lay-images

I'm assuming the reason trickplay files are stored in the config folder now is because they get cleaned out if their respective media doesn't exist anymore.

With the old method of storing it with the media files, if you deleted or renamed a video, the old bif file would be left behind.
Eventually, if you delete/rename a lot of videos on your server, you'd have a lot of useless bif files taking up some space for no reason.
I even wrote a script that would periodically go through my libraries to find and delete left-over bif files (I also stored them with my media files) since Jellyfin couldn't do this.

With the way it is now, you don't have to worry about that. The trickplay files now get deleted by Jellyfin when it detects they're not needed anymore.

[Nariagari]

[...]
With the way it is now, you don't have to worry about that. The trickplay files now get deleted by Jellyfin when it detects they're not needed anymore.

This would also be possible if the trickplay is not stored in the config folder.
Jellyfin knows when a file chances, so it can delete the trickplay on rescan and generate a new one afterward. This probably is the current behavior anyway.

Also, if you delete a movie, you'd normally delete the folder and not just the movie file, especially if you store pictures and nfo files in the media location.

[ionceturnedintoanewt]

Yeah...my small LXC container went from about 8GB in the last 4 years to nearly 35GB in a couple of days. This is not a good change. It would need serious warnings and it really needs to allow for a location change. Normal metadata is not so storage intensive, and I agree SSD storage should be ok for it, but trickplay data...holy cow, it needs to go with the media folder. At the very least you NEED to provide an option to the user.

[Efficient_Good_5784]

This would also be possible if the trickplay is not stored in the config folder.
Jellyfin knows when a file chances, so it can delete the trickplay on rescan and generate a new one afterward. This probably is the current behavior anyway.

Also, if you delete a movie, you'd normally delete the folder and not just the movie file, especially if you store pictures and nfo files in the media location.

For movies yeah, since you generally store a single video file per movie folder (except for those with multiple versions of the same movie).

What I was referring to were situations where you simply edited a single episode in a season/show, or replaced a movie without clearing out the folder it's in.

To explain the previous Jellyscrub behavior, take this folder structure for example:

- Show name
     - Season 1
          - trickplay
               - ep1 [12345678]-320.bif
               - ep2 [12345678]-320.bif
          - ep1 [12345678].mkv
          - ep1 [12345678].nfo
          - ep2 [12345678].mkv
          - ep2 [12345678].nfo

Deleting ep1 and replacing it with a new version (thus giving it a new crc32 checksum in the filename) results with the following:

- Show name
     - Season 1
          - trickplay
               - ep1 [12345678]-320.bif
               - ep1 [24136857]-320.bif
               - ep2 [12345678]-320.bif
          - ep1 [24136857].mkv
          - ep1 [24136875].nfo
          - ep2 [12345678].mkv
          - ep2 [12345678].nfo

The Jellyscrub plugin would not delete the leftover bif file meant for the old ep1 version.
The creator of the plugin mentioned in a github issue about this that it wasn't a big concern to handle left-over bif files since each bif file was generally small in size, so having a few left-over bif files here and there wouldn't be much of a problem.

[Nariagari]

This would also be possible if the trickplay is not stored in the config folder.
Jellyfin knows when a file chances, so it can delete the trickplay on rescan and generate a new one afterward. This probably is the current behavior anyway.

Also, if you delete a movie, you'd normally delete the folder and not just the movie file, especially if you store pictures and nfo files in the media location.

For movies yeah, since you generally store a single video file per movie folder (except for those with multiple versions of the same movie).

What I was referring to were situations where you simply edited a single episode in a season/show, or replaced a movie without clearing out the folder it's in.

I got what you mean.
True, Jellyscrub didn't delete those "leftovers". But I guess (depends on the code) that Jellyfin could delete these "leftovers" since it knew the checksum of the file and noticed that it changed. So it could delete the old .bif and create new a new one.

Or (in my opinion the better solution) the trick play has the same name as the media file, the same way .nfo files work.
It could be that the current naming is some naming standard, but it would make the relationship between files more obvious.
Also, if you replace a film/show, she files would be replaced.

[pcm]

While I do understand the advantage of keeping the trickplay files locally (they can be "pruned" if the media is removed) if there is more than one jellyfin server, they cannot be "shared", and if one wants to do a clean install, then they need to be recreated from scratch, which even with hardware acceleration is a fairly slow process.

Any options for saving with media in the future?

Well you can create a shared volume between all your jellyfin-server instances and mount the shared volume to /var/lib/library ... that way you are sharing all your media metadata including trickplay amongst all your server instances.

I would really love an option that allows trickplay file storage within the media folder again.

One solution would be to create a softlink for library metadata directory to the media directory. Something like,

Code:

ln -s /path/to/your/media/metadata/folder /var/lib/jellyfin/metadata/library

would do the trick. Ofcourse you'd need to first move the current library metadata first before creating the softlink.

[BaltasarOnRails]

I'd like to chime in with my use case: I do not let the Jellyfin instance that serves the video transcode anything. It's low power. So far I used a second jellyfin instance on a fast computer in the network to create the trickdata in Jellyscrub on a GTX 3070, the trickdata was then stored next to the media files. In other words, I'd offload trickdata generation to a different machine in the local network.

[Efficient_Good_5784]

For those still asking for this, the ability to change the location of trickplay files is coming in the future:

https://features.jellyfin.org/posts/2668...lay-images

https://github.com/jellyfin/jellyfin/pull/11883

https://github.com/jellyfin/jellyfin-web/pull/5635