MeGUI: bug reports and feature requests

[TCmullet]

Originally Posted by hello_hello

Try the r768 32 bit version from here: https://www.dropbox.com/sh/3i81ttxf0...VhYLasmwa?dl=0

It DID work! But I'd hate to use the 8 week old version. I can't find the changelog to see if using the old one will affect me.

Apparently the XP switch was on in the 768 version. Any chance a new release can be made, this time with the XP switch on? How soon? Thank you so much!

[Groucho2004]

Originally Posted by TCmullet

It DID work! But I'd hate to use the 8 week old version. I can't find the changelog to see if using the old one will affect me.

Apparently the XP switch was on in the 768 version. Any chance a new release can be made, this time with the XP switch on? How soon? Thank you so much!

I checked both r768 and r783 with PE Explorer. They are both built with the same compiler but for r783, the "XP compatibility option" is not active meaning that for r783, the minimum OS version is NT6.0 (Vista/Server2K8).

[Poutnik]

Stable MeGUI 2507 sometime holds open d2v/m2v files of previously processed demuxed TS/MPEG2 DVB-T recordings.
They stay open, blocked against deletion, even if succeeded in the queue by several next AVS preparations and video encodings.
There is no obvious reason why the files stay blocked but they sometimes do.

Only thing that helps is MeGUI restart.
It seems to happen more frequently ( not confirmed if exclusively ), if video encoding job is aborted by a user, for whatever reason.
Perhaps sanity check and release of open file handlers is not done properly.

Or, can it be fault of the Avisynth ? I use quite older MT 2.6.0.3 from Aug 28, 2012.

Edit:Note that there is no hanging avs4x264mod process in such cases

Edit2: Note that System Explorer is reporting these open files
Currently processed M2V opened by avs2x264mod
Currently processed M2V opened by x264_64
Blocked M2V opened by avs2x264mod
Blocked M2V opened by x264_64
Blocked M2V opened by MeGUI

Note that there is just 1 instance of avs2x264mod and x264_64.

[hello_hello]

Poutnik,
I've sometimes wondered why a file is locked by x264 after opening it with MeGUI and/or creating a script even though it hasn't been encoded (I'm pretty sure). It's happened for quite a while for me (not just the latest version of MeGUI) but not regularly. Just now and then. And of course when I opened some files just now to test it..... I couldn't get MeGUI to lock a file at all. The folder containing the source file yes, but nothing else. Not even the script it was using for encoding.

Anyway, because restarting a program to unlock a file isn't always convenient (and sometimes it even requires a reboot), one of the first utilities I install after a fresh Windows installation is Unlocker.
(I think the installer includes some OpenCandy type annoyance, but you can choose not to install whatever it's offering)

[LigH]

The video source is probably kept open while AviSynth displays the preview.

[Poutnik]

Originally Posted by LigH

The video source is probably kept open while AviSynth displays the preview.

this I would understand.

But there is no video preview open,
and there was no activity done over the file for long time.

The procedure AVS cutting - Script generation - Autoencode was done since then for several other videos, and their D2v/m2v files were able to be deleted.

Perhaps, there could be difference, if the preview is manually closed before launching other preview. I will test.

[hello_hello]

Originally Posted by hello_hello

Just reporting the latest L-Smash version via MeGUI's auto update (r783) doesn't seem to work with XP.

Version r784 doesn't play with XP either. For those XP users who let MeGUI update L-Smash, you can roll back to a previous version or download r768 from here.

Version r783 doesn't work on XP either. I haven't tested r775 myself. r768 definitely does run on XP.

[Kurtnoise]

ok, the binary is not xp compatible...but tell me why do you use a such old OS these days ?

[hello_hello]

Originally Posted by Kurtnoise

ok, the binary is not xp compatible...but tell me why do you use a such old OS these days ?

That'd be due to Microsoft's inability to release a newer version of Windows I'd prefer to use.
I've not had a reason to upgrade when after doing so, re-installing software and sorting out problems, best case scenario would generally be for everything to work as it did before.

It's slowly happening now..... XP not being supported by newer software..... so I guess eventually that'll necessitate upgrading to a version of Windows more annoying than XP, and if I build a new PC as I've been planning to I won't have a choice there, but I like the idea of going straight from XP to Windows 10. Assuming it doesn't suck.

[hello_hello]

For those of us still running XP, an XP friendly L-Smash r784 build is on offer here (link to doom9 post). I've briefly tested it and so far it's working fine.

Someone also pointed out there's an XP friendly r783 build here, which I guess I missed earlier.

[Kurtnoise]

@Zathor : where msvcr100.dll/msvcr120.dll come from ? why they are still required for x265 ?...as soon as I removed them, they are uploaded. That should not be...

@LigH : MeGUI uses your x265 builds...ok but why they are dynamically compiled and not statically ?

[Zathor]

Originally Posted by Kurtnoise

@Zathor : where msvcr100.dll/msvcr120.dll come from ? why they are still required for x265 ?...as soon as I removed them, they are uploaded. That should not be...

If I remember that correctly (I made a lot of tests in the past but do not have any results written down):
The runtime libraries will be copied to the encoder folders in specific cases. E.g. from AviSynth+ directory when this will be used. Or from lsmash directory when AviSynth+ is not used. Both are compiled dynamically and when the runtimes are not copied (or installed in the system) the encoder will fail.
core\util\fileutil.cs:538 and 609

[kalehrl]

Alos, in xvid_encraw folder, msvcr120.dll is automatically added when erased.

[Zathor]

Yes, as xvid is one of the encoders it will be copied. Is there a problem with that?

[LigH]

@ Kurtnoise (+ Zathor):

All I do is:

• Update the sources via Mercurial;
• Run the build scripts creating libx265.dll and x265.exe provided by Multicoreware in 4 variants;
• archive a package and upload

I have no experience with C compilers, I am helpless when the build process gets stuck. I would not know how to edit such a script to get more or less dependencies to any Windows DLLs.

According to Dependency Walker, the x265 EXEs created by these build scripts only have dependencies to KERNEL32.DLL and MSVCRT.DLL; the EXE is no stub using libx265.dll though: these DLLs are additional, standalone libraries for developers preferring the DLL over the CLI EXE in their own applications. You should not add them in your MeGUI package because you will probably not need them.

[Zathor]

Ok, good to know - I will remove the libx265.dll from the next update on. Thanks for providing them!

[stax76]

L-Smash requires Visual C++ 2013 runtime, why nobody is compiling this statically I don't understand.

[Zathor]

Forgot to mention: I updated the stable server ~2 weeks ago to 2525 and today also the tools (had to wait so that the new download server will be detected).

[LigH]

Not sure if desired: Even though using FDKAAC was not yet enabled in the options of external applications, the updater still insisted in updating it unless I would probably manually disable this package. But I couldn't say whether I would recommend any relation between the updater package enabled and the external programs option enabled.

[kalehrl]

Is there a problem with that?

No, not that I'm aware of.