MeGUI Feature Request Thread

[The Link]

Originally Posted by Doom9

... accept / reject configured streams based on the container selected ...

That would be great and all I want in the end.

Originally Posted by Doom9

... but it's not an option to bring it up now because the audio code is all over the place and all but pretty.

I'll wait.

[berrinam]

Originally Posted by Richard Berg

I can provide webhosting for auto-update. I can also register megui.org if nobody has yet...

Sounds good, but it takes me no effort to say that. It's up to you, as far as I'm concerned.

Originally Posted by Richard Berg

How about create a webfolder http://megui.org/meguirequirements that ~5 people have write access to, and occasionally upload new working builds there? It's not the "coolest" solution, but it's better than what we have now.

Since it's us doing the updating, that also means we can create our own naming convention. Something like
x264-2006-xx-xx.rar
mp4box-2006-xx-xx.rar
etc.
Then it's very easy for the MeGUI client to see what the latest version of everything is.

Yes, that is the most reliable/easiest method.

[Mutant_Fruit]

I'm just planning my way through the AutoUpdate section of the program, and here's what i have in mind.

1. The program starts up as per normal, and does a background check for newer versions of the files.
2. If new versions are found, a dialog pops up telling the user newer versions of the files have been found and asks if they want to upgrade.
3. If they click "Yes" a new window pops up showing what files have new versions, and allowing the user to select one/all of them to upgrade.
4. They click "Upgrade" and the new files are downloaded and installed. Update progress is displayed on the window.
5. The AutoUpgrade will be set to check at 3-7 day intervals (user selectable) with a Check Now button in order to reduce bandwidth usage on server side by the program checking every time it starts up.

Also, do you want the AutoUpgrade to check for newer versions of MeGUI stored on the server? Or will we just check for new versions of the utility programs that it uses?

I was thinking on the serverside, we store the files like this:
AppName-incrementing_integer.zip. C# has a Gzip library built in, so we could zip the files up to save a bit of bandwidth. Basically, every time we put a new version on the server, just increase that integer by 1. This makes it easy for me to tell a new version is there, rather than trying to parse out a version number from something like this: Besweet3.2_Beta263.

How does that sound? If anyone else has any ideas, gimme a shout.

[Doom9]

he program starts up as per normal, and does a background check for newer versions of the files.

Make that optional please.. I don't want to hear the phone home litany and I personally never want to use that feature.

[stax76]

C# has a Gzip library built in

IIRC zip != gzip so unless somebody implements zip we are forced to use #ziplib.

[Mutant_Fruit]

Originally Posted by stax

IIRC zip != gzip so unless somebody implements zip we are forced to use #ziplib.

Thats a very good point. I'll look into that.

[foxyshadis]

It'd probably be best to set it to only update with more stable versions, when known bugs are few and not much code reworking is going on. Maybe an option for bleeding edge builds. I know it's going to be a while before the codebase is stable, and if people autoupdate and the new one breaks things people are going to be unhappy.

[Richard Berg]

It's up to you, as far as I'm concerned.

It would be kinda rude for me to go register megui.org without asking Doom9 -- it's his name, and his program. He seemed ok with it in the other thread, though, so I'll start the process. We can figure out exactly what to do with it as time goes on. Hopefully you guys trust me not to turn it into a pr0n site or anything

[JarrettH]

Do you think you could have MeGUI rename the output file if it is about to overwrite it? So often I'll forget to rename the output file when I'm experimenting with settings and I end up losing my previous files. Just stick a sequential number after the name or something.

[Mutant_Fruit]

Yup, i'll definately be backing up the previous versions before i replace em. There'll be a "rollback" button to restore a previous version if something does go wrong.

[Doom9]

Yup, i'll definately be backing up the previous versions before i replace em. There'll be a "rollback" button to restore a previous version if something does go wrong.

I think he was refering to video/audio output.. and I don't like the idea.. it definitely doesn't make the 80/20 cut.

[Mutant_Fruit]

Originally Posted by Doom9

I think he was refering to video/audio output

Oh right, never mind then

[Doom9]

And I think it's necessary to point out that megui isn't overwriting.. it's the user that's overwriting by creating a job with the same output name.. and in the end it's up to the encoder/muxer to decide what happens if the output already exists. Most overwrite, some append (mp4creator for instance adds input streams to the target file if it already exists).

[Mutant_Fruit]

Also, could someone take a look at the patch tracker in SF? Theres a few patches there that havn't been commited to CVS.

My "AviSynth script creator patch" has been commited, but hasn't been closed, but theres still 6 others there.

[Mutant_Fruit]

I've been thinking about this auto-update and i've run into a problem.

What happens when someone manually updates one of the files (such as x264.exe)? Once that happens, i can't tell what version an exe file is, so i don't know whether the one on the server is a newer version or not.

How should i handle this case? Will i just flag the file as being an "unrecognised version" and ignore it unless the user wants to force an update?

[foxyshadis]

Consider using the created/modified date on the file? Perhaps run it and grab the tag ("x264 core:44 svn-408M (built by Sharktooth)")? Hashes might be useful if people could be counted on to never use an unregistered version, but...

[ChronoCross]

1) Any chance of of Being able to specify a folder called AUDIO PLUGINS to put files like bsn.dll the bse files, aac.dll and whatnot in rather than having it in the root folder? It would make the program more organized and easy to use.

2) Also is there anyway for the avisynth script creator to be able to load filters individualy. Like it does for the DGdecode.dll? Even by specifying aavisynth filters folder it doesn't seem to load them. So when you make your scripts your forced to have them in the avisynth root filter directory.

Thanks

[berrinam]

Originally Posted by ChronoCross

1) Any chance of of Being able to specify a folder called AUDIO PLUGINS to put files like bsn.dll the bse files, aac.dll and whatnot in rather than having it in the root folder? It would make the program more organized and easy to use.

Actually, those dlls just need to be put in the same directory as neroraw.exe.

2) Also is there anyway for the avisynth script creator to be able to load filters individualy. Like it does for the DGdecode.dll? Even by specifying aavisynth filters folder it doesn't seem to load them. So when you make your scripts your forced to have them in the avisynth root filter directory.

1.Why not use your avisynth plugins directory anyway? The MeGUI avisynth plugins is now unused, as I said in my guide. If you want all your plugins in one folder, use the AviSynth one (which ISN'T the AviSynth root directory, it's aviroot/plugins)
2. There's the 'Load DLL' button in the edit tab of the AviSynth creator.
3. If, for some reason, you want to load all your plugins in every script, try creating a new AviSynth profile with a template like this:

LoadPlugin("Yourplugin0.dll")
LoadPlugin("Yourplugin1.dll")
...
LoadPlugin("Yourplugin100.dll")

<input>
<deinterlace>
<crop>
<resize>
<denoise>

Some experimenting or reading my guide will make clear how that works.

[Mutant_Fruit]

Originally Posted by foxyshadis

Consider using the created/modified date on the file? Perhaps run it and grab the tag ("x264 core:44 svn-408M (built by Sharktooth)")? Hashes might be useful if people could be counted on to never use an unregistered version, but...

Thing is, created/modified date is useless unless i want to download ALL the files on the server each time i run a check so that i can tell what date they were originally created.

I could do it using hashes i suppose. But then i'd need an XML file to contain the hashes of the EXE's from each version we put up there. Only problem with that is that i'd need to get a hash of /every/ version ever released into the XML file otherwise there'd be a lot of "unrecognised versions".

As for running the exe and parsing out the version from the output... that might be doable. But it means each of the files (from besweet to encraw) would have to supply me that info. I wasn't sure if all the files would do that. I'll check it later. But this approach won't work for dll files...

[dimzon]

Originally Posted by ChronoCross

1) Any chance of of Being able to specify a folder called AUDIO PLUGINS to put files like bsn.dll the bse files, aac.dll and whatnot in rather than having it in the root folder? It would make the program more organized and easy to use.

This is not plugins. This files MUST be in same directory with NERORAW.EXE
If You don't like multiple files in MeGUI folder You can create NeroRaw (OR NeroAAC OR as you wish) folder and put neroraw.exe + bsn.dll + ... in it