When is %temp% used by FFB / FFMPEG ?

[Dodutils]

Hello,

I did a lot of H.264 to H.265 conversions and also Audio stream removals from a lot of MKV files (about 1TB).

I only used secondary SSD or external USB drive as source and destination in FFB, never used "C:\xxxxx", but I noticed that total amount of GB written on my primary SSD that have only the "C:" parttion increased a lot those last few days according to my S.M.A.R.T monitor, so I tried to understand why and then I noticed that FFB creates a temp folder in %temp% with some temporary files inside that looks like extracted streams that FFB delete once quit or when it move to next file in queue.

Question is when do FFB use %temp% and what do it write in it ? or do FFMPEG use it too ?

The purpose of this question is to minimize the write usage of my primary Windows system SSD to keep it alive as long as possible, so if FFB or FFMPEG use it to temporary extract video or audio streams when they convert a file is there a way to tell FFB / FFMPEG to NOT use %temp% but another drive/folder destination ?

Regards.

[NiezzaYT]

it won't.
By default, this GUI will use the same File Directory where you imported the video from.
Even in "Try On Console" menu, it simulates the encoding on the same Folder where the original video is located.

As for Video downloader, you must specifically tell AND Save the directory path for the video to be written into.

[NiezzaYT]

and to prove this, I simply use Resmon.exe (Resource Monitor) and Transcoding 50GB Video from a physically separated SSD which is Drive : D , with destination of another SSD Drive : E.

And I don't see any write activity on Drive : C other than reading from it.

[Dodutils]

Hello,

Thank you for the answer but you said "Even in "Try On Console" menu, it simulates the encoding on the same Folder where the original video is located.".

I double checked it and here is a screenshot that prove this is not true, at least for me, as you can see the entire MKV file has been copied into FFB %temp% folder during conversion and as you can see on screenshot my source + destination folder was my external USB drive "E:". I also checked the manual that say " try the command to a temporary folder" that should be the FFBatch_test folder.

I noticed also that each time you add a file in the queue, FFB will create 2 files in its temp folder, but those are small, only few KB size, one is a txt file containing a few lines describing the video format and compression and second one is a jpg that show the cover or some picture extracted from the movie.

So back to the big file the log in Try console show it uses the FFB temp folder and according to the manual this is expected behavior and I used Try Console a few times on big files and files that produced errors on conversion to try to better undertsand why, so this is probably the explanation.

Input #0, matroska,webm, from 'E:\Movies\Movie.1080p.H265.mkv':
[...]
Output #0, matroska, to 'C:\Users\dodfr\AppData\Local\Temp\FFBatch_test\Movie.1080p.H265.mkv':

So FFB create the %temp% FFBatch_test folder each time it starts (delete it once quit) and do some "temporary" thing in it including writing a copy of the MKV

Regards.

[NiezzaYT]

@Dodutils of course, here's why. Portable app behaves very differently from full installed app.

[NiezzaYT]

@Dodutils This is the only way for this App to perform optimally, with minimum writes on Drive : C

[Dodutils]

OK i'll try this version, by default I always prefer portable unzip&run apps versions, that's the way I also develop I prefer to do true portable apps you can copy/paste its directory anywhere anytime and work 100% inside it.

I don't know why portable version of FFMPEG works differently about C: drive, on the opposite it should not act like this if truely portable it should work 100% inside its own directory and only use %temp% when it is not portable version because of /Program Files/ write access limitations if app is not started as admin for example.

And about that, little underrated trick (if you have enough RAM depending the context) I use time to time a RAM Drive and work inside it to work faster and also if needed change %temp% to the RAM Drive, not really usefull I guess for FFB but for example if you have a software that do tons of write/rewrite on a file before producing final version it will be much faster, and once finished then write the final file to the destination, and this helps a lot to save your SSD lifetime.

[eibol]

Hi, I had not given this particular scenario a thought, it would make sense to limit writes to current folder for portable versions.
The point of always using %temp% folder was to ensure a valid and writable was used. I'll look into it.

Edit: I believe only "Try preset" feature and videos thumbnail generation use temp folder. FFmpeg located at the same executable path should write only there, or in some cases, ffmpeg writes a temp file on source file path.

If you disable Try preset, thumbnails and mediainfo text files storage usage are somewhat negligible. (it is only generated once a single file is selected).

[Dodutils]

Hi eibol, thanx for your answer, for the tumbnail or small TXT file yes it is negligeable with no impact on SSD lifetime but full video file is not, so may be you could show a parameter "Set temp folder" with 3 radio buttons :

1- Same as FFB exe folder
2- use default %temp% system folder
3- Select your folder : xxxxxxxxx <= here a button to select the temp folder

[eibol]

That should not be really necessary.

I'm trying to reproduce your case, but I can't find a reason for that temp file being generated during encoding. It should not be generated, according to current code, and your current main window settings.

Maybe it is a specific scenario, which I'm not finding out. Could you please include your current settings window?