HandBrake

Conner wrote:another alternative would be to be able to save the queue, or 'batch' (what Sorenson Squeeze calls it). That way, if a crash happens, you can open up the saved queue, delete the items that are done, and set it off and running again.

jbrjake wrote:This will come when it's possible. I've suggested it to travistex several times, but he doesn't want it re-scanning the discs when the queue is loaded to set up the job struct, and I don't want the gui messing with the library's private code.

It's not coming in the immediate future.

HandBrakeCLI -i source1 -o destination1
HandBrakeCLI -i source1 -o destination2
HandBrakeCLI -i source2 -o destination3
HandBrakeCLI -i source2 -o destination4

jbrjake wrote:Considering that the MacGui doesn't interact with the CLI in any way shape or form...

listrophy wrote: I just assumed the Gui was a front-end.

bdfortin wrote:I have a request similar to this, so I'll ask it here:

If we can pause encodes, and maybe eventually get crash recovery, would it be possible to save the progress of an encode in case we have to restart or shut down for some reason?

Metasyntactic wrote:As a developer, the answer seems fairly simple to me. Just take your in memory data structure and use any of the existing serialization mechanisms ot write it out to a file.

I wrote:Output the user-set parts of the job struct in the key-value form used by the presets.plist

sr55 wrote:The MacGUI is not written in a .NET langauge

jbrjake wrote:

Metasyntactic wrote:As a developer, the answer seems fairly simple to me. Just take your in memory data structure and use any of the existing serialization mechanisms ot write it out to a file.

Yes...that's the idea.

I wrote:Output the user-set parts of the job struct in the key-value form used by the presets.plist

But it's not "fairly simple," because of how the job struct works. Thus all the issues with queuing. Part of the struct is publicly accessible by the MacGui, but parts are private to libhb, and so when importing the exported job list, it'll have to rescan the sources, creating a proper job struct for that title in libhb, before filling in the details of the job from the stuff exported to disk. It'll happen, but, again, it's not going to happen soon since afaik the only person who's shown the slightest interest in pursuing it is travistex, and he seems to be busy with other things.

It's not anywhere near as easy as glomming on a "simple save/load button" -- there are structural changes required to write the data to disk, some tedius philosophical debates about how segmented the lib should be from its interfaces have to occur (again *groan*), and new Obj-C methods (and maybe C functions) are needed to reconstruct the job from the partial data in the exported queue. And if history is any marker, there will be plenty of bugs to work through in this process. Not to mention the usability issues of all of this (when does the rescan take place, all at once when the queue is loaded, or just as the job is called? Both differ from what people are used to in HB.)....

Metasyntactic wrote:The Q (even if it does have parts that sit outside the reach of your GUI) is populated by data provided from teh GUI.

i.e. when you click 'add to Q' there is code that captures teh state of the GUI and passes that to someone else to process. It is that state that should be saved and restored. The act of loading would in essence take the data from disc, load it into the gui and the perform teh 'add to Q' action. (of course, in practice, you would bypass the actual GUI since it would be irrelevant)

Yes that's what I've been saying: "when importing the exported job list, it'll have to rescan the sources, creating a proper job struct for that title in libhb, before filling in the details of the job from the stuff exported to disk."