MeGUI: bug reports and feature requests

[StainlessS]

Zathor,
I have been experiencing some problems with both stable and developer for some months (WXP32SP3).
On checking Changelog, see this

- Windows Vista and older is not supported

The only problem I'm having is using MeGUI_AutoEncode_Batcher, which uses AutoIt code to add avs scripts to the Auto Encode queue.
Problem arises when Preview Window is opened (after avs script load) and the batcher clicks close Button (little x close alias ALT/F4).
Seems that the problem arises due to close button being clicked before MeGUI is ready, ie MeGUI is still doing its multiple scanning
of Avs script and has not as yet presented the clip graphic in the preview window, when close button is clicked it crashes MeGUI.
(the Batcher is un-affected).

I have been putting off posting this problem report, in hope of it disappearing, but update earlier today and then saw changelog.
I've tried adding in a 10 second delay after Preview Window appears, and that fixes my problem, and so I have to assume
that problem could also affect systems after VISTA, if user clicks ALT/F4 close button before MeGUI has finished whatever it does
during its multiple script scanning period.

Adding avs scripts by hand is no problem for me with current versions, but I like to use the batcher.
I was not at all aware until a short while ago (checking Changelog) that XP is no longer supported (in theory),

What is the latest version MeGUI that is supported for XP (I see no such dropping of support note in changelog).

Developer MeGUI 2860, stable 2836.

Thanks in advance.

EDIT: Batcher:- https://forum.doom9.org/showthread.php?t=163343

EDIT:
From current Changelog of both Stable and Development.

Known Problems:
- Windows Vista and older is not supported

from Full Changelog

2077 [Progress Window] lower also I/O and memory priority when priority below normal (requires Windows Vista or newer). Feature request #3468249

Is this the first one that does NOT support XP ?

EDIT: Found this on sourceforge

Known Problems: - Windows XP and older is not supported [2624]

So maybe 2525 last supported stable (despite me not knowing that neither development nor stable not supported since March 2015).

[tuanden0]

mkvmerge update version 24.0.0

[LouieChuckyMerry]

Originally Posted by Zathor

LouieChuckyMerry / hello_hello: Could you please try 2860? It should now properly detect that the included portable AviSynth is not used. Please try also if the MeGUI setting "log debug information" changes a thing (with the next restart).

Version 2860 seems to properly detect that the included AviSynth is not used; ticking "Log debug information" does change something: [Information] AviSynth+: false in the log became [Information] AviSynth+: true. However, now I receive an access error for loading ConvertStack.dll, and if I # that line of my script out I receive an access error for the next line, and so on. Here's the script:

# Set DAR in encoder to 16 : 9. The following line is for automatic signalling
global MeGUI_darx = 16
global MeGUI_dary = 9
SetMemoryMax(1024)
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\Tools\Avs\plugins\ConvertStacked.dll")
LoadPlugin("F:\[0]StandAloneApps\MeGUI-2500(core)2443(data)0.3.5(libs)[Portable]\tools\lsmash\LSMASHSource.dll")
LWLibavVideoSource("D:\Temp\[0000]ReEncTemp\[1080p]AlohaBobbyAndRose[S]{1975}[1080p]\OriginalVideo,OriginalAudio.mkv")
SMDegrain(TR=3,ThSAD=700,RefineMotion=True,Plane=0,Chroma=False,Lsb=True,Lsb_Out=True)
F=DitherPost(Mode=-1)
S=F.FastLineDarkenMod()
D=MT_MakeDiff(S,F).Dither_Convert_8_To_16()
Dither_Add16(Last,D,Dif=True,U=2,V=2)
GradFun3(Radius=16,Lsb_In=True,Lsb=True)
Trim(11111,11666)
Dither_Out()
ConvertFromStacked(Bits=16)
Prefetch(7)

My system is Win 7 64 bit, UAC has been disabled since I opened the package, and portable MeGUI is on a RAMDisk, F:\.

[LigH]

Sounds like a misinterpretation of the confusingly bracketed path names... is there any reason to interpret them?

I would guess if you simplified the path and file names as much as possible, there may be no issue?

[Groucho2004]

Originally Posted by LigH

Sounds like a misinterpretation of the confusingly bracketed path names... is there any reason to interpret them?

I would guess if you simplified the path and file names as much as possible, there may be no issue?

Misinterpretation? All the characters in the path names are valid.

[LouieChuckyMerry]

Originally Posted by LigH

Sounds like a misinterpretation of the confusingly bracketed path names... is there any reason to interpret them?

I would guess if you simplified the path and file names as much as possible, there may be no issue?

I've been using those path names with SEt's AviSynth MT for some years without issue. Would AviSynth+ be different that way?

[hello_hello]

Originally Posted by LigH

is probably protected by the UAC: Windows doesn't allow manipulation of files in this directory branch without Administrator access rights.

That's why we keep recommending not to install MeGUI there, over and over ... or you would have to disable the UAC, which is a security risk.

Fortunately, I'm in a UAC free zone (still running XP).

How do people put up with the crap? I plugged a USB hard drive into my ex's laptop the other day, to copy some stuff to the laptop drive, and UAC had to bother me to ask permission to access it. More than once, I think.

[videoh]

It's easy to turn off completely if you don't like it.

[LigH]

Originally Posted by Groucho2004

Misinterpretation? All the characters in the path names are valid.

So, do you see any better reason for

Originally Posted by LouieChuckyMerry

now I receive an access error for loading ConvertStack.dll, and if I # that line of my script out I receive an access error for the next line, and so on

or maybe I misunderstood the meaning of the term "access error"?

[Groucho2004]

Originally Posted by LigH

maybe I misunderstood the meaning of the term "access error"?

That's one possibility.

[Groucho2004]

I'm curious about the "portable mode" in Megui.
I suppose this option will load the included avisynth.dll instead of the DLL that was installed in System32/SysWow64.

What about the plugins that were installed with Avisynth which are referenced in the registry? The only way I can see to avoid these being used is to have an explicit "LoadPlugin()" call for each plugin used in the script, right?

[hello_hello]

Originally Posted by Groucho2004

I'm curious about the "portable mode" in Megui.
I suppose this option will load the included avisynth.dll instead of the DLL that was installed in System32/SysWow64.

That's the theory, although it still isn't working correctly for me.

Originally Posted by Groucho2004

What about the plugins that were installed with Avisynth which are referenced in the registry? The only way I can see to avoid these being used is to have an explicit "LoadPlugin()" call for each plugin used in the script, right?

Would it be preferable for MeGUI not to use auto-loading plugins? If it didn't, when Avisynth is installed other programs could open scripts that rely on auto-loading plugins but they'd fail to open in MeGUI.

[LigH]

I believe (strongly, like I read it before) that MeGUI redirects the auto-load directory during its activity. AviSynth may have an API to change the location read from the registry after the initialization of its interface.

[Groucho2004]

Originally Posted by LigH

I believe (strongly, like I read it before) that MeGUI redirects the auto-load directory during its activity. AviSynth may have an API to change the location read from the registry after the initialization of its interface.

There are two ways of which I'm aware to disable auto-loading from directories referenced in the registry:
1. Use ClearAutoloadDirs() (requires AVS+)
2. Remove the registry entries (quite drastic)

Maybe Megui is using one of these methods. I'm too lazy to dig through the code so maybe the developer(s) can shed some light.

[Zathor]

Originally Posted by StainlessS

Zathor,
I have been experiencing some problems with both stable and developer for some months (WXP32SP3).
On checking Changelog, see this

- Windows Vista and older is not supported

The MeGUI core still does work with XP (and Vista), however the external tools may not and most important I will not spend time to test anything with XP/Vista and I will not fix any issues which arise only on those OS. I simply do not have the time.

Originally Posted by StainlessS

The only problem I'm having is using MeGUI_AutoEncode_Batcher, which uses AutoIt code to add avs scripts to the Auto Encode queue.
Problem arises when Preview Window is opened (after avs script load) and the batcher clicks close Button (little x close alias ALT/F4).
Seems that the problem arises due to close button being clicked before MeGUI is ready, ie MeGUI is still doing its multiple scanning
of Avs script and has not as yet presented the clip graphic in the preview window, when close button is clicked it crashes MeGUI.
(the Batcher is un-affected).

I tried to reproduce that but failed. Could you please describe in more detail how do you get it to crash?

[Zathor]

Originally Posted by LouieChuckyMerry

Version 2860 seems to properly detect that the included AviSynth is not used; ticking "Log debug information" does change something: [Information] AviSynth+: false in the log became [Information] AviSynth+: true.

Could you upload please both logs? (versions part is sufficient)

[Zathor]

Originally Posted by Groucho2004

I'm curious about the "portable mode" in Megui.
I suppose this option will load the included avisynth.dll instead of the DLL that was installed in System32/SysWow64.

What about the plugins that were installed with Avisynth which are referenced in the registry? The only way I can see to avoid these being used is to have an explicit "LoadPlugin()" call for each plugin used in the script, right?

MeGUI does copy in portable mode in every needed folder (encoder directories and the MeGUI root) the needed avisynth.dll + others (devil, redist).

Based on the the avs calls in the exe files - as none of them specifies a path - will based on the default dll search order first search in the local directory before the system ones are searched. So e.g. MeGUI.exe does call avisynthwrapper.dll which will call avisynth.dll

I have added in 2860 the information to the log which module path is used to detect potential issues.

And yes, to avoid any issues with then not autoloaded plugin dlls, there will be LoadPlugin calls for each needed function placed / but only for the ones MeGUI is using so e.g. convertstacked.dll is not loaded. I suggest to use the addautoloaddir() command.

As AVS+ will check for the registry keys and load the system installed plugin DLLs, it may potentially try to load dlls which will break AVS+.Not sure if such DLLs exist.

[Zathor]

Originally Posted by hello_hello

Thanks for the effort!
Now you've made me feel bad for being the bearer of bad news.

PS It makes no difference if the "log debug info" option is enabled/disabled.

Thanks, I have only changed the detection method so while the checkbox is not ticked, you should still have the same result. But now it will be detected that not the portable one is used.

When the checkbox is ticked I do have explicit FreeLibrary calls in place to unload avisynth.dll used by avisynthwrapper.dll. This seems to have it changed for LouieChuckyMerry somehow.

[Groucho2004]

Originally Posted by Zathor

As AVS+ will check for the registry keys and load the system installed plugin DLLs, it may potentially try to load dlls which will break AVS+.Not sure if such DLLs exist.

Probably not break but there are plugins that are not supported by AVS+ (CPP 2.0 and C 2.0).

[hello_hello]

Compatibility with auto-loading plugins isn't exactly a new problem. If there's auto-loading plugins then it's really up to the user to make sure they're compatible with MeGUI's portable Avisynth, otherwise you can tell MeGUI to use the installed Avisynth instead. It's not really any different from ensuring auto-loading plugins are compatible with the version of Avisynth you have installed.