Open MaverickLoneshark opened 1 year ago
I could not repro this on my version (latest release 2.39 and build from source), but this line of ffmpeg
output looks interesting
[concat @ 00000228ddb53840] Impossible to open 'file:temp\ScreenToGif\Recording\2023-09-30 23-48-03\Encode 2023-10-01 07-06-00-89\temp\ScreenToGif\Recording\2023-09-30 23-48-03\Encode 2023-10-01 07-06-00-89\0.png'
For some reason it looks like the path is duplicated. Also, when I test this, I have a full path to a file and here it's only a relative one.
Neither full path nor relative path seem to work for me.
I could not repro this on my version (latest release 2.39 and build from source)
at ScreenToGif.Util.EncodingManager.EncodeWithFfmpeg(ExportPreset preset, List`1 listFrames, Int32 id, CancellationTokenSource tokenSource, String processing) in C:\Users\[redacted]\source\ScreenToGif\ScreenToGif\Util\EncodingManager.cs:line 1774 at ScreenToGif.Util.EncodingManager.Encode(ExportProject project, ExportPreset preset, Int32 id, CancellationTokenSource tokenSource) in C:\Users\[redacted]\source\ScreenToGif\ScreenToGif\Util\EncodingManager.cs:line 1038
So I'm pretty sure I shouldn't have those first lines in my error messages (after all, my username isn't [redacted]
)...
Have you tried installing on a different machine?
So I'm pretty sure I shouldn't have those first lines in my error messages (after all, my username isn't
nicke
)... Have you tried installing on a different machine?
That's just the path saved along with debug symbols. It's from my setup.
What's in your cache path? The default should be %temp%
or to be safe %UserProfile%\AppData\Local\Temp
.
If your environment variable %temp% is set to anything other than the default value, it may result what you are experiencing now.
Interesting, it was using a relative temp
folder.
I was able to properly encode a mpeg-4 after switching to %temp%
.
Problem solved! (though it would probably be best to hide your personal build configuration paths from the error output for security reasons...)
Accidentally closed instead of just commented, my bad. Up to you to decide, after all.
By the way, is there any chance of working in a feature request for a dark mode skin for ScreenToGif? The bright white contrast is kind of hard on my primarily dark theme accustomed eyes.
Thank you for your swift response! (I was expecting to hear back from you after another two weeks or something)
Relative path does the trick of producing an error. Maybe the fix could be that if the relative path is entered, it could be resolved to a full one on Save
? I can see some code that might does do that (AdjustPath
calls) so maybe it's not covering all cases in this scenario (manually entered path)?
Well, that's certainly an idea, but couldn't the relative paths work by invoking the encoder from the ScreenToGif directory as the working directory or something?
Actually this might be a bit more convoluted than I first thought... https://superuser.com/a/943258
Well, that's certainly an idea, but couldn't the relative paths work by invoking the encoder from the ScreenToGif directory as the working directory or something?
Actually this might be a bit more convoluted than I first thought... https://superuser.com/a/943258
I'll check that one. Thanks for the link.
yeah, setting the relative paths, even with the working directory is set doesn't seems to be helping ffmpeg
:(
Interesting, it was using a relative
temp
folder. I was able to properly encode a mpeg-4 after switching to%temp%
.Problem solved! (though it would probably be best to hide your personal build configuration paths from the error output for security reasons...)
thanks! You are genius !
Description Saving project as Mp4 with default encoder fails due to intermediary 'no such file or directory' issues (missing correct path to
temp
).To Reproduce Steps to reproduce the behavior:
ffmpeg.exe
location if prompted to locateExpected behavior ScreenToGif should produce a valid MP4 video.
Screenshots
Desktop:
Additional context Can successfully encode other formats without any known problems, so this issue seems specific to feeding ffmpeg correct path parameters