Long story short, I have managed to trim down the issue to "just drop settings.xml in settings folder, then try to convert whatever video"
For this reason (I wouldn't know anything else) I skipped the usual template.
I'm on 1.0.7, Win7 64bit.
The usual template is not optional. To be frank, I have no idea what you're trying to tell us here.
I tried to encode a video.
Encoding was never starting.
Like, I checked the queue, and it was there, but no matter how many times I tried to pause/resume it, it was always stuck.
I then tried to delete settings folder, and problem solved.
I restored settings.xml and it popped up again.
So, there you have it up there to test directly.
Can you provide the problematic settings.xml?
https://github.com/HandBrake/HandBrake/files/1030284/settings.pdf
First post!
(renamed to pdf, because for some reason, I can't manage to upload archives)
Ah, sorry. GitHub renamed it to .pdf so I was confused.
@sr55 Possible settings corruption, see attached (rename .pdf to .xml).
Creation date says 19 december 2014, if it can help btw.
I see no issues when dropping that settings file in, whether I have anything on the queue before or after doing so, it always operates correctly.
There isn't anything inside of it that i'd expect would cause any problems. The legacy settings that are not used anymore simply won't get used.
As such, unless you have any other ideas I don't really have much choice but to mark this as not reproducible.
So my gut feel is it's not to do with settings but maybe the queue file or whatever else. Either way, it's either settings + something else, or just something else.
Are there other settings than those in %APPDATA%/Handbrake?
EDIT: my log
Just a log of a successful scan
Unfortunately, short of debugging it locally, there is nothing more I can suggest on this one.
Nailed!
It's PauseOnLowDiskspace.
I have 9.5GB free on my ssd (which is indeed under the 10GB threshold for warning, which I get).
Unless I set it on false though, there's like no way I can make the encoding start.
Couple of fixes around the buttons not enabling / disabling correctly and added a log message on the log window to indicate why the encode stopped.
I compiled latest git GUI, but I didn't see any improvement.
All it's doing is logging it. It will not allow you to proceed.
You either have to lower the limit to suit your environment (Don't come crying if you brick your system though) or clear some space.
Don't come crying if you brick your system though
Lol?
My personal case had to do with a 50MB output
I'm still not sure why, even after noticing the user (should he not be aware), conversion still might not start?
Lol?
Yes, it's actually happened before.
I'm working on some UX issues around the pausing at the moment to make it clearer what's going on.
:\
Well, I guess I could already call it a day then.. Even though I still find a certain oddity around that figure of 10GB (I mean, especially given it's not 'exposed' to that very type of users that would need it, and that it seems kind of arbitrary)
I'm not saying to lower it to MS dumb levels.. but might 1GB sounds neater?
Or perhaps, I dunno, something more dynamic like SourceVideoSize>FreeSpace ?
Perhaps the GUIs could warn at a certain threshold and pause at a lower threshold, e.g. 5 GB / 250 MB.
There is nothing odd about 10GB. Most 1080p encodes should be a fair bit below that, leaving plenty of space left for system to operate normally. It's a pre-encode check. I don't monitor during an encode as it's not reliable. It's not perfect but it'll catch the vast majority of cases.
If you want to run a lower limit, just set it in preferences.
I know it's a pre-encode check, so that's why I had suggested the SourceVideo > FreeSpace .
Anyway, assuming the warning now is not fooling the user, I'm good.