MeGUI Bug-Report Thread

[berrinam]

@chipzoller: With a short test, I couldn't reproduce your bug. Can you try it again with VC#, but this time, before running it, go to Debug->Exceptions, and set Common Language Runtime Exceptions, Thrown, to checked. When you run it, you will get a few more exceptions, some of which would normally be caught, and one of which will be the right one. Hopefully you can tell the difference (for instance, there will be three exceptions when you start up -- just press continue/play/F5 when you get them, they don't matter).

[chipzoller]

Berrinam:

Did what you said...

Get this: KeyNotFoundException ....the given key was not present in the dictionary.

Actually get 2. Not sure what you're looking for. Let me know what specifics and I'll post them.

[berrinam]

Tell me where you got that exception. It should come up with that exception in a particular line. A screenshot would be good enough, in fact.

[chipzoller]

Berrinam:

here (http://www.arches.uga.edu/~czoller/screen1.jpg)

and

here (http://www.arches.uga.edu/~czoller/screen2.jpg)


It didn't crash when I had this debug option turned on. Maybe these will help anyway.

[berrinam]

Yep, they help. Looking at those exceptions you got, it would have crashed if Debug wasn't turned on. I think I know what is going on, so I'll look into it.

EDIT: Fixed.

[greggerm]

Folks,

Another bug for 'ya...
As seen in builds 2119 and 2123 (haven't used other builds)

Workflow:
Use Megui to create a dgindex job. Run and complete.
Use Megui to create an AVISynth script. Create and copy files to the input screen.
Use Megui to establish end credit location.
Use Megui input screen to define audio and select personalized audio profile. Enter audio config and exit to workaround bug (http://forum.doom9.org/showpost.php?p=795987&postcount=690).
Use MeGui AutoEncode option, and set appropriately.
Use AutoEncode "additional options"
Add chapter file, hit go, crash!

Details:

I experienced the audio/video bug described in this post (http://forum.doom9.org/showpost.php?p=795987&postcount=690), so I used the workaround of opening then closing the audio profile config before sending the job to the AutoEncoder. This got me past any audio/video type incompatable messages. For reference, the audio config is set to use AVISynth with Nero AAC, Force Directshow, and Keep Existing Channels.

I then set my options in the Automatic Encoding dialog (MP4 muxed, no target size/use video profile , add addtional content checkbox) and hit Queue.

I am then brought to the expected "Mux" dialog where I can add in the chapter file I need to. I add the chapter file, and hit "Go".

I am immediately greeted with the following error block:
http://www.greggerm.com/miscpics/error1.jpg

MeGUI then bails to the input screen. No logs to post, as no jobs are run.

Any ideas?
Prior to the .net2 builds, this was my normal workflow for doing an encode. Occasionally, the one-click system doesn't extract the audio stream so I have to do a "manual" encode, which is where this bug was discovered.

Thanks for rooting it out!!!
-Greg Germ

(And thanks to all for continued work on the program - it really is a great utility!)

[greggerm]

Another OneClick error...
(Problem descriptions adjusted as more testing done)

Summary:
The DGIndex process launched by oneclick will miss a 5.1 AC3 audio stream if it is not 0x80.

(*The DGIndex process launched by oneclick will miss an audio stream if the first available stream is not a 0x80. )

Workflow:
Use MeGui One Click Profile Setup to insure everything is as it should be.
Use MeGui One Click, select the desired DVD Decrypter created IFO directory, and click on the vob to work with.
Use MeGui One Click and verify that the desired audio track (Eng 5.1) is selected for use.
Once done queuing movies, launch queue.

Results:
On movies which have the first audio stream at 0x80, DGIndex de-muxes everything properly - even if the first stream is not the desired track. On movies who start audio streams "higher" than 0x80, say at 0x81, there is NO de-muxed .AC3 audio file. The command line seems to look for track 1, but track 1 may be hard coded as 0x80 in DGIndex.

Logfile:
This is the DGIndex log for the movie Almost Famous.

Starting job job1 at 1:46:01 PM
Job is a dgindex job. dgindex commandline:
"C:\x264\DGIndex\DGIndex.exe" -AIF=[C:\x264\- Encoding Only\ALMOST_FAMOUS\VIDEO_TS\VTS_05_1.VOB] -OF=[C:\x264\- Encoding Only\ALMOST_FAMOUS\VIDEO_TS\VTS_05_1] -exit -OM=1 -TN=1
successfully set up dgindex
Processing ended at 1:50:01 PM
----------------------------------------------------------------------------------------------------------



This is the stream info file from DVD Decrypter for the same...

0x20 - Subtitle - English / Normal Captions - [SubPicture 01: Wide] / LBA: 3 / PTS: 00:00:00.206 / Delay: 0ms
0x21 - Subtitle - English / Normal Captions - [SubPicture 01: Letterbox] / LBA: 4 / PTS: 00:00:00.206 / Delay: 0ms
0x81 - Audio - AC3 / 6ch / 48kHz / DRC / English / LBA: 99 / PTS: 00:00:00.206 / Delay: 0ms
0x82 - Audio - AC3 / 2ch / 48kHz / DRC / English / LBA: 100 / PTS: 00:00:00.206 / Delay: 0ms
0x88 - Audio - DTS / 6ch / 48kHz / DRC / English / LBA: 98 / PTS: 00:00:00.206 / Delay: 0ms
0xE0 - Video - MPEG-2 / 720x480 (NTSC) / 16:9 / Letterboxed / LBA: 1 / PTS: 00:00:00.206 / Delay: 0ms


The results of this oneclick job is that there is no demuxed AC3 file for audio encoding.

In studying the command line, looks like DGIndex is being told to only demux track 1 (-TN=1) from the audio stream, even though track 1 (0x80) doesn't exist. Does MeGUI need some intelligence to read the stream .txt file and create the appropriate command line, or is this a DGIndex issue for not knowing that the first available audio track is in fact 0x81?
---------------------------------------------------------
Edit:
Cheap-o workaround:

In an effort to get it to work, I created a new oneclick job based on the above Almost Famous DVD. Before starting the queue, I exited MeGUI in order to save out the .xml files for the job.

I then edited the job's xml file, and adjusted the -TN=1 to a TN=2, signifying I wanted track 2.

Restarted MeGUI and started the job - a moment later, there was a growing .AC3 file in the directory...

Looks like DGIndex uses 0x80 as (1), 0x81 as (2), and on from there. Perhaps there is a way for MeGUI to read the streams file and determine what stream address the desired track is on, so that it can formulate which track to feed to DGIndex.

I'll update if for some reason this workaround fails in the later stages, but it looks like it'll be OK.
-----------------------------------------------------------
At Berrinam below...
Sure - I may not be able to get it to you today or tomorrow, but certainly over the weekend. I'll fire you a private message with where I am placing it. Eagerly awaiting the build with the patches you made!

[berrinam]

@Greg: GREAT bug reports. Thank you very much.

I've fixed your first bug, as well as the 'audio input/output types are not configured' error message: http://forum.doom9.org/showthread.php?p=813236#post813236

Could you give me a small sample of one of the VOB files that causes problems for your second bug please?

[Bathrone]

I think Chronocross' latest built has a corrupt archive.

http://www.chronocrossdev.com/apps/megui/MeGUI-0.2.3.2125-Dev.rar

[greggerm]

FWIW, I was just able to download and unpack the .RAR archive without issue. I also downloaded it yesterday afternoon without any problems too.

Try another download session? If you have any download managers, perhaps try turning it off temporarily? The archive looks good - I think maybe your download got corrupt.

-Greg

[Bathrone]

Hmm thanks for that Greg. Per your suggestion tried it in Regest dlx instead of IE 7 beta and it worked :)

[HOLiC]

I'm trying to encode hybrid video, but I always get an error message if i try to open the script with megui. No problem in Virtualdub though.

http://i2.photobucket.com/albums/y39/meow_chan/megui.jpg

I'm using MeGUI 0.2.3.2123 in x264-r498 install pack.
And output is MKV without audio, and here's the script:



mpeg2source("C:\DVDrip\Zotome07\otome07.d2v")

TFM(d2v="C:\DVDrip\Zotome07\otome07.d2v")
tdecimate(mode=3,hybrid=2,vfrDec=1,mkvOut="mkv-timecodesfile.txt")

crop(2,2,716,476).BicubicResize(704,528)



I wanted to try Tivtc's vfr method, so just copied the method in the TIVTCv1RC2 Readme. Did I do something wrong? Any feedback would be great, Thanks!!

[goldencoin5]

i m a new bie n the prob is that how can i convert my DIGITAL VIDEO to AVI with MEGUI ?
with staxrip i m doing it very easily but wann'a try MEGUI ?
when i open a .ts file it says CHECK YR PIDZZZ
i open it with d2v creator :helpful:

[berrinam]

@Greg: I tried out the sample you gave me, and I do indeed get the same problem. I'm at a bit of a loss to it, though: all I can say is that MeGUI is getting the track numbering wrong, so that what it thinks is track 1 is actually track 2 in DGIndex. I asked neuron2 about this sort of thing a while ago: http://forum.doom9.org/showthread.php?t=106266

He gave me a response that seems perfectly logical, but searching around gave me no indication of the numbering system that he spoke about. Specifically, I don't know the mapping from the stream IDs given in the stream info.txt file and the stream IDs that he talks about. Maybe someone else can help out on this, but until then, you're stuck with having to do it manually. Sorry.

@HOLiC: Well, I would say that's a TIVTC bug. The fact that it doesn't trigger in VirtualDub is probably just because, according to dimzon, MeGUI's AviSynth wrapper is written in C#, which is very specific about memory management, whereas a laxer language like C/C++, which VDub is written in, doesn't pick these errors up. Perhaps you want to report this to tritical?

@goldencoins: Don't doublepost.

Can you upload a small sample somewhere so I can look at it? Thanks.

[stax76]

according to dimzon, MeGUI's AviSynth wrapper is written in C#, which is very specific about memory management, whereas a laxer language like C/C++, which VDub is written in, doesn't pick these errors up. Perhaps you want to report this to tritical?

Memory corruptions happen also with MediaInfo, never happened to me but I've received a couple of bug reports.

[greggerm]

@Berrinam:
Thank you kindly for looking into it, and I'm glad you were able to reproduce it.

Yeah - the first track of audio is usually 0x80, but sometimes it's 0x81. Looks like MeGUI is coded to look for the "first" track available, while DGIndex is coded to look at 0x80 absolute. When they conflict, the wires get crossed and problems arise.

Is it possible for MeGUI to use the hex codes rather than look for the "first available" track? (Is it possible without a huge rewrite of the code!) If the two programs use the same logic in seeking audio, maybe the problem can be averted.

It's not all that hard to do it manually - I'm ripping any oddball audio stream movies to a different directory for "special" processing. Otherwise, things are going nicely.

Thanks again for taking it into consideration!
-Greg

[foxyshadis]

berrinam (@holic), it means it tried to seek, probably by trying to open the preview window (since it seeks to the middle frame) and mode 3 can't support seeking at all. So it's neither megui nor tivtc bug. Turning the auto-preview off should fix it.

[asdfsauce]

ChronoCross-

Bug report for your MeGUI Essentials Package installer:

I installed it to a directory other than the default "C:\Program Files\MeGUI", but it set all my dependency (x264, mp4box, etc.) paths in settings to that location anyway. So, installs to correct directory, but sets program paths in settings to default "C:\Program Files\MeGUI".

Besides that, I really like the installer. Thanks.

[ChronoCross]

not really a bug. it's just a default settings file. I can't generate that using the installer. you have to edit those manually. Even by opening megui it'll generate something that has to be set immediately before use. it's not automatic so if you install it to an alternate location(which I do not recommend if your a newbie) you have to set the settings file.

[asdfsauce]

Ahh, ok, I didn't know if you were trying to do that or not. I don't really know a whole lot about install scripts. Anyway, maybe you could just set up the settings file with relative paths like this:

<MencoderPath>tools\mencoder.exe</MencoderPath>
<FaacPath>audio\faac.exe</FaacPath>
<LamePath>audio\lame.exe</LamePath>
<NerorawPath>audio\neroraw.exe</NerorawPath>
<MkvmergePath>tools\MKVtoolnix\mkvmerge.exe</MkvmergePath>
<BesweetPath>audio\BeSweet.exe</BesweetPath>
<Mp4boxPath>tools\MP4Box.exe</Mp4boxPath>
<X264Path>x264\x264.exe</X264Path>
<DgIndexPath>tools\DGIndex\DGIndex.exe</DgIndexPath>
<XviDEncrawPath>tools\xvid_encraw.exe</XviDEncrawPath>

That way it would be independent of where MeGUI is installed.

Another thing you could do is set the installer not to overwrite an existing settings file so people's settings aren't over-written every time.

Edit: It appears that there is a bug with relative paths in MeGUI. After you queue up an encode and try to start it, it will error with this –

Job is a video job.calling setup failed with error Could not find x264\x264.exe in the path specified: x264\x264.exe Please specify the proper path in the settings

However, if you restart MeGUI and then start the job in the queue again, it will work just fine. Same goes for audio, a restart will fix it.

[Doom9]

@Greg: in fact, MeGUI uses hex codes. Let's presume you have this info file:
0x80 - Audio - AC3 / 6ch / 48kHz / DRC / Deutsch / LBA: 9 / PTS: 00:00:00.060 / Delay: 0ms
0x81 - Audio - AC3 / 6ch / 48kHz / DRC / English / LBA: 8 / PTS: 00:00:00.060 / Delay: 0ms

That means the 0x80 is T01, 0x81 is T02. MeGUI goes through these audio lines, the first one is T01, the second one T02, etc. But that's as far as hex codes go. If you have no info file, and dgindex names your selection differently than named in the GUI.. then you're SOL.. there's no way of telling for megui which is which - or do you know of any way?

@asdfsauce: There's no bug.. you cannot start a process with a relative path.. it's as simple as that. ATM I'm at a loss why a restart helps.. it shouldn't because the setup process is exactly the same and the if File.Exists(x264\x264.exe) will still return false.

I can't generate that using the installer.Isn't quite true though, you can launch arbitrary things from a setup.. you could for instance store the path selected and use a small third party program to adjust the settings file. It's most certainly an inconvenience for you though.

[berrinam]

@Greg: in fact, MeGUI uses hex codes. Let's presume you have this info file:
0x80 - Audio - AC3 / 6ch / 48kHz / DRC / Deutsch / LBA: 9 / PTS: 00:00:00.060 / Delay: 0ms
0x81 - Audio - AC3 / 6ch / 48kHz / DRC / English / LBA: 8 / PTS: 00:00:00.060 / Delay: 0ms

That means the 0x80 is T01, 0x81 is T02. MeGUI goes through these audio lines, the first one is T01, the second one T02, etc. But that's as far as hex codes go.This is in fact what causes the problem. I downloaded his sample, and it turns out that they are listed as he described:
0x81 - Audio - AC3 / 6ch / 48kHz / DRC / English / LBA: 99 / PTS: 00:00:00.206 / Delay: 0ms
0x82 - Audio - AC3 / 2ch / 48kHz / DRC / English / LBA: 100 / PTS: 00:00:00.206 / Delay: 0ms
0x88 - Audio - DTS / 6ch / 48kHz / DRC / English / LBA: 98 / PTS: 00:00:00.206 / Delay: 0ms
However, opening the sample in MeGUI lists them differently:
track 1 -- 0x88 (dts track
track 2 -- 0x81 (ac3 1)
track 3 -- 0x82 (ac3 2)

I have no idea why DGIndex lists them in that order, considering that the stream id 0x81 is clearly before 0x88 and neuron2 said that they are ordered by stream id. A fair bit of googling didn't give me any more info about the sort of stream id that neuron2 was talking about here (http://forum.doom9.org/showthread.php?t=106266), so I simply have no idea what's going on.

... you could for instance store the path selected and use a small third party program to adjust the settings file. It's most certainly an inconvenience for you though.
This is certainly true and something like this should be done if we want a properly-working installer. However, before we get carried away too far with this, I want to raise the issue of auto updating, which Mutant_Fruit has now given his source code for. I'm working on it. I see this system as a way to download all required files for MeGUI and set them up properly. Its integration directly into MeGUI makes it more powerful than an installer, because it can configure MeGUI as it chooses.

The questions:
Should this auto-update system be the method for installing, and installation packages be left simply as binaries of MeGUI?
If yes to the above, do we provide some way of doing an offline install? This could be done relatively easily in auto-update by allowing the user to select a local repository, and it could also be done as an everything-installer, as ChronoCross is doing.

[sp@rrow]

http://forum.doom9.org/showthread.php?p=795987#post795987
(1) :( :( :(

[berrinam]

I've submitted a patch for that, but I am still reluctant to commit it to CVS. I'm not sure if ChronoCross is applying it...

[greggerm]

@berrinam/doom9

Thanks for the continued discussion on that audio hiccup. I'm reripping my (rather massive) collection right now due to a equipment loss in a fire (smoke+soot+always on HTPC = failed electronics). Any movies I rip having a 0x81 starting stream are being separated out so I can adjust the DGIndex command line in the job. All others with a standard 5.1 0x80 channel are being done straight-away.

Thanks again - I'll keep looking into the threads should any new information come around.

[ChronoCross]

I've submitted a patch for that, but I am still reluctant to commit it to CVS. I'm not sure if ChronoCross is applying it...

I have only been doing pure cvs builds for megui. even that has become difficult due to sourceforge's cvs.

[asdfsauce]

@Doom9

Surely an executable can look up its own path and append the relative path to it. Maybe someone could amend the code to deal with that. I actually wanted that as a feature even before this deal with the installer came up, but didn’t think anyone else would see any usefulness in it.

I only assumed it would work in the first place because at one point in time, having an executable in the same folder as MeGUI.exe and the path set to just executable.exe would work just fine.

[berrinam]

MeGUI is manually coded to support paths of the form 'file.exe'. However, it doesn't support relative paths other than that as of yet. I'll have a look into it to see how hard it is to support relative paths.

[berrinam]

Well, I just tested it out, and relative paths already work for me, without any code changes. I tried setting it up as x264\x264.exe, and it encoded just fine. Something's wrong at your end.

[asdfsauce]

My only relative path setting right now:

<X264Path>x264\x264.exe</X264Path>

If I open MeGUI with that setting, queue up an x264 encode and then try to start, it will error with this –

The current job was aborted. Stopping queue mode
Starting job job2-1 at 9:48:46 PM
Job is a video job.calling setup failed with error Could not find x264\x264.exe in the path specified: x264\x264.exe Please specify the proper path in the settings

After a restart, starting the encode works without a hitch. Could you try that sequence? Might just be a setting of mine that is different.

[berrinam]

Fixed. It's because you selected a video file the first time you opened it, which changed the working directoy, and the relative paths got stuffed up. However, you didn't do that the second time.

[asdfsauce]

Thanks berrinam.

There's one other thing that has been bothering me. Ever since the latest completed refactoring (I think), the video encoder settings profiles have been acting a bit weird for me. Not the profiles themselves, but MeGUI's handling of them. For instance, a lot of times they are not saved after editing. Then others, MeGUI won't display the profile that is currently in use even though I had just finished using/editing it. Things get even weirder when I have safe profile alteration activated, but that may not be the case now as I haven't been using that setting for some time.

To me it’s really obvious/annoying and has persisted through multiple configurations, but since it’s been around for a while now with no fix, I’m thinking this problem isn’t experienced by all. The audio profiles seem to be fine though.

[berrinam]

It happens to everyone, and it's on the buglist, but none of us have been bothered to do anything about it.

[yogi_]

MeGUI changes my SAR settings.

I want to do an anmorphic encode with an SAR of 10:11. This is what I see in the xml file when the job files are generated:

<Commandline>--pass 1 --bitrate 1180 --stats "encode.stats" --keyint 240 --min-keyint 24 --bframes 3 --b-pyramid --filter 1,1 --subme 1 --analyse none --direct auto --me dia --sar 10:11 --progress --no-psnr --output NUL "encode.avs" </Commandline>

and this is what I see in the log after starting the job:

Job is a video job. encoder commandline:
--pass 1 --bitrate 1180 --stats "encode.stats" --keyint 240 --min-keyint 24 --bframes 3 --b-pyramid --filter 1,1 --subme 1 --analyse none --direct auto --me dia --sar 75:121 --progress --no-psnr --output NUL "encode.avs"
successfully started encoding

[berrinam]

You can't enter SAR. You can only enter DAR. The labels are wrong.

[yogi_]

OK, thanks. Works fine now. DAR 4:3 in MeGUI gives SAR 10:11 for the encode. The label is kind of misleading ;)

[berrinam]

I will fix it up. These things are easy to fix, which is why no-one can ever be bothered to fix them :P.

EDIT: Done.

[asdfsauce]

berrinam-

Could you update MeGUI to work with relative paths for DGIndex and other MeGUI utilities too? :scared:

[Inc]

I recognised that when changing IN MeGUI the path to the avs plugins that this will modify the general avisynth plugins path registry key string value of the system!
So if a newbie interprets that as an individual MeGui avs plugin directory which can be set specifically for MeGui he will be much surprised when his avs system is messed up afterwards!

If the user wants to load filters outside the common avs plugins directory he could do that via the manual load plugin button.

My >>2cents<<

[gravety]

Hi,

Like the GUI!

I have managed to 1 click fine with NAAC but when I try with LAME MP3 DGIndex does the 1st (analysis) step and MeGUI then performs the second step (where it won't respond to input) after which it exits!

No error and no log.

I installed from the essentials pkg, patched to latest 0.2.3.2129, installed AVISynth 2.5.6a and copied the filters.

I can do the AC3 to MP3 on its own fine. I have tried CBR, VBR different downmix settings. Have tried a couple of VOB files.

FAAC also seems to work fine.

Any ideas?

Regards, Graham

[stax76]

MeGUI puts --direct in the cmdl even with 0 B-Frames. Shouldn't the direct switch only be used if B-Frames > 0. I got a profile converter with code generator that puts a reference to MeGUI and StaxRip and invokes the command line generator of both applications in order to verify if both application generate identical command lines for all of sharktooth's profiles and the CQ-Lossless profiles produces a mismatch because my code look like:

If bframes > 0 Then cmdl += " --direct...

[Sharktooth]

fixed in 0.2.3.2130.

[bob0r]

Bitrate Calculator:

Tools/Bitrate Calculator > In audio track (1 or 2) fill in size (kb or mb does not matter) > go to top, try to increase hours, minutes or seconds, and you get this error:

http://files.x264.nl/megui-2130-bitrate_calculator_bug.jpg

[CruNcher]

Is anything known about a Memory overflow problem with Megui ? I did ten HD 1920x800 encodes in the queue and after that Windows told me that the swapfile needs to be increased hmm then i looked @ the memory usage of Megui and i was shocked 1.8 GB !!!! shouldn't .NET free the used memory instantly again ? "garbage collector" , couldn't start the 11 encode after restarting megui everything was fine again (memory was freed comit charge back on a normal level) build was 0.2.3.2129.


Sorry but Memory Controll seems to be bad with .Net, every application i saw till today is so bad @ it and everything gets slowed down and a memory hog (unless it's a .Net cli app) for Video applications stability is esential, even for a Gui and this doesn't look stable to me. For example ATIs Catalyst Controll Center it's the plain horror but anywaysy Nvidia want's to move to .Net also in the future, were are we heading to if all future developers don't learn how to use the resources of the pc efficiently (and trust some monopol runtime compilers) i fear that in the future people as Picard gonna be very few (working in those monopol firms) and everyone else is blindly trusting Microsoft and .Net geez what for a Future.
Look @ apps like Mediacoder it's gui is not the nicest but it's fast reacting done completly in win32api and has no memory problems, so please all kids reading this don't just trust your runtime compilers, instead learn how to use c(++) and win32api and if you really wana be a freak in the future there is still ASM :)
It doesn't really suprise me that Vista needs so much memory with so much .Net stuff working native inside it :P
Just look http://www.mufflastig.com for example what for wonderfull applications you can do with just win32api :)

[ChronoCross]

I wouldn't think that megui would be sucking up that much in the first place. Since nothing is actually done in megui. Each individual application does the work. With the exception of perhaps audio encoding.

From just a small tes the basic megui app take sup around 17MB of memory. Everytime it does an action it increases by 1-3MB. Running an encode it gains 3MB on initial start but does not gain anything else until the end of the encode.

If you could narrow down under what conditions your system gains the most memory usage and what your trying to do it could help narrow down the search for a solution.

[CruNcher]

Here is the Memory usage after the first encode
http://cruncher.mufflastig.com/meguiencode_1.png

Commit Charge Before was 24% now set @ 44% if i would start another encode it would go higher and higher before swaping and then BOOOM
http://cruncher.mufflastig.com/commit.png

[ChronoCross]

After looking at that I would have to say there is something wrong with your setup. That memory usage looks like that of x264.exe but that is a separate process and would be cleared when the application finished.

I'll run some more tests to see if I can reproduce the memory leakage.

[Carpo]

if you have 512-600 meg of ram that may be an issue - when i have done encodes to either x264 or dvd the mem usage is always high (with cce it has even hit a gig of mem)

[Doom9]

Here's how MeGUI could potentially leak memory:
not cleaning up forms properly. Most forms should be properly closed after dimzon's intervention. Then we have open I/O resources.. the file parts should be okay, but stdout/stderr readers may not be closed. That cannot account for a massive memory usage though but it's something that can be improved to be more resource friendly in the future.

There's no net and db connections.

Which leaves interop, but if there were a problem in that area, it should happen when you play around with the various preview dialogues as they use unsafe code and interop. So if you open a preview, play around it, play the movie for a while, then close it, if there's a leak you should see a significant increase of memory use.

And that's about it. When a .NET app launches a process, initially the memory the new process allocates is counted toward's the managed app's memory but that's not really correct. The two processes should "separate" after a few seconds though.

[CruNcher]

apropo forms yeah some odditiy i encountered also was as i changed something in a profile and clicked on ok it doesn't seem ed to get saved i clicked on config again and it looked like the same as before the setting change and also the profile tab @ the main menu doesn't seem to be correctly linked to the config dialog one, if you set the video profile in the main window and then go to the config it doesn't load that profile but displays a empty listbox (very strange behaviour).