Transcoding File Deletion

[EmbyOak 23]

I created a RAMDrive to handle my transcoding to increase performance and reduce wear on the spindles.  I have files that were created a while ago and have not been deleted.  Any reason why the transcoding files would still be in the drive?  Below is the list of directories summing 3.8GB in size.  

Dec 23 22:13 91D4F4

Dec 23 22:13 C13A54

Dec 31 08:11 7567FF

Dec 31 08:10 6A5B78

Dec 31 08:11 EDCCE8

Jan  3 09:54 ED2F5B

 

Jan  3 09:54 9FC3E6

Jan  5 21:16 A08A96

Jan  8 07:37 E826F9

Jan  8 21:05 35564E

 

Jan  9 16:32 B6D858

Jan  9 16:53 BB46D4

Jan 10 04:27 711B37

 

[Happy2Play 9780]

Really hard to say without the context of the corresponding server and ffmpeg logs.

But this does happen when the server does not recieve proper stop commands from clients.

[EmbyOak 23]

Is there a scheduled task that could be created to clear out the folder, if there are no active plays occurring?

[ShadowKindjal 21]

14 hours ago, Happy2Play said:

Really hard to say without the context of the corresponding server and ffmpeg logs.

But this does happen when the server does not recieve proper stop commands from clients.

Could you explain what you mean by not receiving proper stop commands? I have the same issue as the OP all the time and I have to manually clear the folder periodically.

[Happy2Play 9780]

6 hours ago, ShadowKindjal said:

Could you explain what you mean by not receiving proper stop commands? I have the same issue as the OP all the time and I have to manually clear the folder periodically.

Take the Roku for example, users click the Home button while something is still playing will close the app without stopping the media.  So the server did not receive the command so the items remain in the transcode-temp folder.

[Luke 42078]

Right but the server should eventually recognize that and clean them up, it just won't be immediately like it would be if you actually stopped.

[EmbyOak 23]

Anything over 6 hours old is probably safe to delete...

[Scott D 69]

17 hours ago, Happy2Play said:

Take the Roku for example, users click the Home button while something is still playing will close the app without stopping the media.  So the server did not receive the command so the items remain in the transcode-temp folder.

Same problem here, with one exception.  According to the server log file it did in fact receive the "2023-01-11 21:16:16.462 Info SessionManager: Playback stopped reported by app Roku SG 4.0.75 playing Sandie Shaw. Stopped at 3276000 ms"

The temp files remained and consumed a touch over 1 gig in the temp directory.

This session appears to have all the markings of a "clean run".  A start time, and end time and a stop command.  

This problem occurred during the Bruce_Kelly session started at 8:22:08 pm ending at 9:16:16 pm.

 

Side note - After returning from a long weekend (4 days) away from the server, I found over 250 gig of a 450 SSD being occupied by temp files.  There was a live tv stream that had not closed which had run for over 22 hours (most of the data being used in temp folder).  The live stream was not being sent out, just captured into the temp folder.  Had to restart the server to clean things up and close the channel to the HDHR.  No log files for this incident, just wanted to recover the space as quickly as possible.

embyserver-63809078400.txt ffmpeg-transcode-20476791-ebe0-4d79-b978-99c736fef423_1.txt

Edited January 12, 2023 by Scott D

[ShadowKindjal 21]

On 1/11/2023 at 3:40 PM, Luke said:

Right but the server should eventually recognize that and clean them up, it just won't be immediately like it would be if you actually stopped.

Except that isn't happening if i have stuff backdated to November. Is it possible for emby to clear out that folder on startup?

[Scott D 69]

I have been doing a manual restart on a daily basis for a few years now.  It will close any open channels of an HDHR as well as delete any transcode temp files.  Some have even created jobs that will delete leftover files.  I find it easier, while not convenient if left unattended, to simply restart in the morning.  Only takes a few seconds and cleans things up nicely.

[Luke 42078]

On 1/12/2023 at 10:12 PM, Scott D said:

I have been doing a manual restart on a daily basis for a few years now.  It will close any open channels of an HDHR as well as delete any transcode temp files.  Some have even created jobs that will delete leftover files.  I find it easier, while not convenient if left unattended, to simply restart in the morning.  Only takes a few seconds and cleans things up nicely.

Are you sure you still need to?

[Scott D 69]

Yes.  It is necessary to do a restart.  Maybe not every morning, but every morning there are abandoned temp files that remain in the directory.  If left alone, the file count will grow and hard drive space goes down.  See the "Side Note" on the post of January 12th.  I have been doing this for years and it is just become a part of my routine.

[Neminem 1518]

You could try this plugin, using right now.

 

[Scott D 69]

51 minutes ago, jaycedk said:

You could try this plugin, using right now.

 

Going to give it a shot and see how it works out.  Now I'll need a new hobby to occupy the time previously spent restarting the server.

[EmbyOak 23]

From the crontab I run:

*/3 * * * * root /emby-service-check.sh

This script checks if the service is up and running or not and if not, starts it.  Mine would randomly go offline.  I believe I have narrowed it down to the Statistics plugging that is causing issues when it runs.  I cannot remember where I found this script (modified to my needs).  It is simple, it works well and if you recognize it because you wrote it, thank you.

You can modify the script so that it simply restarts the service at a specific time.  This way you are using the system and not relying on a plug in to do something.

 

#!/bin/bash

SERVICENAME="emby-server"

systemctl is-active --quiet $SERVICENAME

STATUS=$? # return value is 0 if running

if [[ "$STATUS" -ne "0" ]]; then

        echo "Service '$SERVICENAME' is not curently running... Starting now..."

        service $SERVICENAME start

fi

[EmbyOak 23]

And the checking every 3 minutes is so that if the server goes down and I am no where near a computer when I get the alert from my monitoring system, it takes care of itself.