Jellyfin - the beast eats GB

[girish]

I think upstream project has a bug report at https://github.com/jellyfin/jellyfin/issues/3929 to limit the transcode cache size. However,

[girish]

Heh, it seems this is a hot topic in that world. Here's a script that does some auto clean up - https://github.com/RTUnit/Jellyfin-Transcodes-cleanup

There's also plenty of reddit threads - https://www.reddit.com/r/jellyfin/comments/wuur1a/how_much_disk_space_for_transcodes/ https://www.reddit.com/r/jellyfin/comments/gm6y6p/is_there_a_way_to_limit_cachebuffer/ https://www.reddit.com/r/jellyfin/comments/11bzgte/cache_of_transcode/ https://www.reddit.com/r/jellyfin/comments/os4k2q/transcoding_and_served_file_sizes/

[necrevistonnezr]

These GBs are not reclaimed automatically per default? Or just not reclaimed in a short time span?

[luckow]

@necrevistonnezr Good question. I've decided not to delete the app from my Zimaboard. Let's see if the hard drive is full again in a few days/weeks. I'll monitor Jellyfin's hard drive usage a few hours and days after watching movies.

[necrevistonnezr]

Just checked mine:

• 1.57 GB app size before watching a movie
• 3.0 GB app size after starting a movie (the difference to the 1.57 GB is roughly the movie's file size)
• 1.57 GB app size after stopping the movie

--> I looks like the cache is cleared automatically?!

[luckow]

@necrevistonnezr Okay. Ideal conditions. At home, I noticed that the play button was a bit lame. That's why I pressed it twice or more. Sometimes when I'm watching as an alien from outside my network, the stream suddenly cuts out. No idea if this leads to dead GB that are not automatically deleted.

[necrevistonnezr]

Just for clarity, it runs on a server at home but a tad more powerful than the Zimaboard, I guess (Beelink EQ12 with Intel N100, 16 GB RAM and SSD drives)

[msbt]

@luckow is it possible that you transferred files via the web file manager on your mounted volume? Because the same thing just happened to me, I sent a few GB of files via the gui and the space was used on the mounted volume and also in the sftp container. The files weren't removed even after the transfer was complete. When I was uploading directly to the volume (not via cloudron) only the volume space was used. So maybe there's a bug in the file manager/sftp? I restarted the service and the space is still in use.

I did a quick search for bigger files on the server and the volumes look like this:

...
/var/lib/docker/volumes/1231239813136462c2985ef9fb95997d3bf3c0ade478161c9ab78897fabd9df4/_data/1234nhpQSR7FGRmviYn3o-uJ.mkv
/var/lib/docker/volumes/1231239813136462c2985ef9fb95997d3bf3c0ade478161c9ab78897fabd9df4/_data/1234cYkcj_5Jf1VChyqBW8pY.mkv
/var/lib/docker/volumes/1231239813136462c2985ef9fb95997d3bf3c0ade478161c9ab78897fabd9df4/_data/1234Tv6qx56UmX2BD2vDKMmD.mkv
...

When querying for that specific volume, this shows up:

volume 1231239813136462c2985ef9fb95997d3bf3c0ade478161c9ab78897fabd9df4 is used by sftp,

Will the sftp volume eventually be cleaned up or what's going on there?

cc @girish @nebulon

Edit: I was drag & dropping whole directories

[girish]

@msbt great catch, can confirm the bug.

[hexbin]

Folks, your private vacation videos are just too large