[Fixed] WinGUI unexpected behaviours (several)

[Statick]

v0.9.3
XP SP3

not bugs as such, but definitely unexpected behaviour to be looked at... all of these reproducable every time under any circumstances, as far as i can tell

1) presets: when the default preset is loaded on startup, advanced encoding settings are not loaded with it - going to the "advanced" tab shows incorrect settings. the preset must be manually loaded by clicking on it for advanced settings to take effect. expected behaviour: all settings from default preset should be loaded on startup, not just some of them.

2) file types: choosing desired file type (mp4, mkv, etc) from the drop down list on the main interface does not affect the default file type chosen in the "choose destination" file browser. for example if i choose to make an MKV file, then click "browse" to choose the destination, the file's extension will in fact be MP4 unless i change it here also. expected behaviour: the filetype chosen in the file browser should match that in the drop-down box, and indeed vice-versa. any change in one should be be visible in the other, unless the drop-down box on the main interface serves some other purpose. in fact, it's likely that one of these two controls is redundant, two controls to change one setting is unneccessary.

3) queue: objects are removed from the queue when encoding commences, not when completed successfully. if the encoding doesn't complete for whatever reason, say if the user aborts the encode, or the computer crashes, it is already lost from the queue and must be re-created and re-added to the queue before another attempt can be made. expected behaviour: jobs should remain in the queue until successfully completed

4) queue: if the batch process is paused using the "pause" button, then later resumed with the "resume" button, handbrake attempts to begin the next queued encoding immediately, and as per #3 above removes the job from the queue. if a prior encoding process is still taking place (likely, given the duration of high quality encodes) then this new process fails, causing the job to be lost from the queue. expected behaviour: resuming the queue should cause the next queued job to begin upon completion of any running encoding process, and as per #3 a failed job should not be removed from the queue

[s55]

1. Fixed http://trac.handbrake.fr/changeset/2045

2. It will only set the file type, if there is a file already in the destination box, otherwise it defaults. (This is the expected behaviour). The flow is such,that the user selects the file before they touch the format. (saving the file, updates the format)
Yeh, it's kinda a redundent feature but It comes in handy at times.

3. Deliberate. In the event that you have an encode that, for whatever reason, causes the computer to hard crash, you don't want it reloading it back onto the queue on the next launch of HandBrake as it could simply crash again. Most users won't debug and issue and instead just end up confused stuck in a loop and enocde crash encode crash etc. The idea is that they'd go back and re-encoding the single file, then ask for help or whatever.

It's my general preference that it does all the encodes it can do, then anything that's not worked, i can go back and solve any issues. I guess it may seem a bit odd, but folks generally don't complain about it.

4.Fixed http://trac.handbrake.fr/changeset/2046

[BlackWolf]

Got another one ...

5) When you select "none" as the first audio stream the GUI doesn't seem to recognize that. The bitrate etc. fields are not disabled (as they are on the mac) and the audiostream is still added to the video. Even loading presets with -a none will not cause the video to have no audio. The only way is to manually execute HandBrakeCLI.exe with the -a none option. Expected behaviour: Selecting "none" for the first audiostream should cause the video to not have any audio.

[s55]

Small bug. None was only meant to be displayed for tracks 2 3 and 4, not 1.

The WinGUI has never supported having no audio.

[BlackWolf]

Small bug. None was only meant to be displayed for tracks 2 3 and 4, not 1.

The WinGUI has never supported having no audio.

may I ask why not? since the mac gui handles that perfectly ... . It's not a big deal for me, I just use the CLI directly from now on, but it would be nice if the GUI would support this. or if it's not supposed to, if at least "none" is not shown for the first audio track

[s55]

may I ask why not?

To put simply, I've never needed it.

Added as part of: http://trac.handbrake.fr/changeset/2089