Ability to SAVE batch encode lists (crash recovery, shouldn't be a big deal?)

[rohan]

I seems like an obvious feature to be able to save your list of projects/batch encodes.

If you plug in 15 different movies to encode, and for some reason your PC crashes 3 movies into the job list, AutoGK opens with an empty job list after restart. It would be a GREAT idea to give AutoGK the ability to save your batch list.

Peace,
-Rohan-

[len0x]

If it wasn't a big deal then it would have been implemented already. It will come at some point in the future (not nearest though).

[rohan]

wouldn't it be as simple as adding a "save" button that would output the project settings to a simple txt file that could be loaded later?

[len0x]

Unfortunately buttons cannot write files automatically :) (I know, big bummer...) There are quite a few settings to be written/read manually plus the whole infrastructure for keeping jobs upto date with check list box that you see as a job list.

[Doom9]

lol.. it might not be a big leap of mind, but trust me, I implemented job queuing and persistence in my own software and it was a big deal from a coding point of view. The human mind is a lot more flexible than codelines... and .NET even made my job really easy with XML persistence - that's not available in other programming environments.

[len0x]

I wish it was as easy as in Java - just serialize the object and that's it! :)

[Doom9]

you mean implements serializable? it's just as easy in .NET, just add a [Serializable] statement at the top of a class. Though, with the XML serializer you don't even need that.. but the drawback is that you are limited in the ways you can use polymorphism.

[len0x]

hm... what does polymorphism has to do with serialization?

[Doom9]

well, I never got into details, but for MeGUI, each codec has its own class for the settings and they all derive from the same super-class. Now I meant to have the jobs just contain that superclass, and then figure out which codec I'm dealing with using the "is" operator on the superclass, and while that worked just fine, serializing a job using the XML serializer would no longer work (using the standard binary serializer still did), so I ended up with a job having 4 codecsetting classes, one for each codec, and I find that kinda ugly. Perhaps I'll find out more when I get into refactoring the code.