MeGUI: General Questions and Troubleshooting Thread

[AMiR9!WV]

There's an option in MeGUI's settings called "delete intermediate files". Is it checked?

yes , it was checked and i unchecked it , now my problem solved thanks to you :)

[Solon8]

The stable update server is probably updated less frequently as it only gets the releases known to be stable. That'd include the tools MeGUI uses. If you use the development update server you risk the possibility of bugs. MeGUI 2523 was only released in the last day or so.

I don't think MeGUI has been updated in a while as there were issues with update servers. It's been updated now (2523) but any updates to the tools it uses such as MKVMerge are probably yet to follow.

You can always update MKVMerge in MeGUI's Tools folder manually, although it's a pity there's no way for MeGUI to know you've done so (as far as I know) because sooner or later it'll want to update it again.

Okay, thank you! I have another question: whenever I use FileIndexer, it extracts the audio I chose and create the ffindex. Then the AviSynth script creator opens and I can crop, resize, etc. Once the .avs saved, I go to MeGUI's Input tab and only the video encoding part is loaded (with the avisynth script and the video output), NOT the audio part, so I have to go to the my file folder and choose the audio myself.

I remember a time when the extracted audio was "loaded" automatically in the Input tab. So maybe I changed something in the options when I reinstalled it? But I don't know which one. I also noticed it only does that with mkv files. The extracted audios of other formats such as mp4 or avi is properly and automtically "loaded" in the Audio Input.

[hello_hello]

It appears audio extracted from MKVs isn't being auto-loaded for re-encoding as it is when indexing other file types (ie when MeGUI creates a script for encoding the audio or if it's extracted by DGIndex etc). I imagine at some stage it worked the same way, but it appears at the moment it doesn't. I so rarely use MeGUI to extract MKV audio and if I do it'd be even more rare for me to re-encode it, so I hadn't noticed. I'm using MeGUI 2524.

[Solon8]

It appears audio extracted from MKVs isn't being auto-loaded for re-encoding as it is when indexing other file types (ie when MeGUI creates a script for encoding the audio or if it's extracted by DGIndex etc). I imagine at some stage it worked the same way, but it appears at the moment it doesn't. I so rarely use MeGUI to extract MKV audio and if I do it'd be even more rare for me to re-encode it, so I hadn't noticed. I'm using MeGUI 2524.

OK, thank you, so it's not a bug on my end. I'm also using 2524 but it was the same when I was using 2507.

[Farfie]

Hello,
I'm getting
http://pastebin.com/DYmqSb8Z
with 2524.

To fix, I only needed to switch to the stable server and let only MeGUI itself downgrade to 2507, and now it's working fine.
Just thought I'd report it here.

[christopherw]

I have run tests with using builds available x264.nl (http://mirror01.x264.nl/x264/?dir=./32bit/8bit_depth) for playback issues with 2 files being joined together while the files have been created with Automated 2pass profile.

It turns out that somewhere between rev 2216 and 2230 the change was made that altered codec private data just enough for the files not being able to be joined together

Tested revisions:
2200: OK
2216: OK
2230: broken
2245: broken
2273: broken

Test therefore reveled this is not a Megui nor MKVtoolnix issue ;)

Was this issue a problem with the I frame on the append boundary? I'm experiencing this with two-pass bitrate based encodes when I merge files: it's almost like the first I frame of the next segment is ignored when appended, so you get that 'smearing' and what I presume is the codec guessing about what it should start the frame sequence with - usually ends up being full field grey. They all play fine individually. Only using 4 B frame interval, L4.1 (1080i25 TFF interlaced encode) with no CABAC.

CRF equivalents of the same files append without issue, as discussed here a while ago.


I'm using MuldeR's Simple x264 launcher which has the x264 core:144 r2525 40bb568 builds bundled with it (self-updates), 64-bit compiles.

[hello_hello]

I'm using MuldeR's Simple x264 launcher which has the x264 core:144 r2525 40bb568 builds bundled with it (self-updates), 64-bit compiles.

Are you also including --stitchable in the x264 command line? That option was added a few months after the post you quoted.
https://mailman.videolan.org/pipermail/x264-devel/2013-July/010167.html

CRF encodes don't always append for me these days without --stitchable, even though back then when testing I think they did. I think it's been mentioned somewhere files are more likely to append if the encoder is writing a raw AVC stream (as opposed to writing an MKV or MP4) for reasons I don't understand, but that shouldn't matter anyway. --stitchable fixed the problem and as long as it's used you should have no trouble appending encodes using the same encoder settings (different CRF values seem to be fine though). It works for me (encoder usually writing directly to MKV).

[bxyhxyh]

Is http://mewiki.project357.com/ down?

[hello_hello]

Is http://mewiki.project357.com/ down?

It disappeared a while ago. It's pobably related to this:
http://forum.doom9.org/showthread.php?t=171738

Try here:
https://en.wikibooks.org/wiki/MeGUI/x264_Settings

Edit: Assuming that's what you were looking for. Sorry, I just assumed.......

[bxyhxyh]

Yeah. You assumed correct :D
Then this page should be more recent. It seems that wikibooks page isn't updated since 2011.

https://web.archive.org/web/20150207075004/http://mewiki.project357.com/wiki/X264_Settings

[Betsy25]

Anyone can still enlighten us which update server is the preferred one these days ?

I just switched to the dev server after months without any update on the stable server, and I got a bunch of updates presented.

After installing these & a restart, just as a test, I set back the update server to the stable one, checking for updates presented me with 'new' updates which were the months old versions I previously had ? :confused:

Please, which channel is adviced, and if the dev one is, what is the exact url these days ?

[Kurtnoise]

of course...if you use the stable server, you have to use the tools listed from this one. Same idea for the dev server...You can use the dev one w/o issues.

[nkk]

Where to get more topical x264 encoder presets?

[LigH]

You want to upload video to YouTube? Then forget optimal quality. YouTube will re-encode everything.

There are people who upload massively upscaled videos with high bitrates, which wastes a lot of bandwidth, to preserve a bit of chrominance resolution when YouTube will downscale it during its conversions ... for how much fame exactly?

[aegisofrime]

Hi, I'm being driven absolutely crazy by MeGUI crashing when it attempts to decode AAC files.

I have taken a look at the event viewer and found this:

Fault bucket , type 0
Event Name: APPCRASH
Response: Not available
Cab Id: 0

Problem signature:
P1: MeGUI.exe
P2: 1.0.2525.0
P3: 54fc5b03
P4: bass.dll
P5: 2.4.4.0
P6: 4ad476cd
P7: c0000005
P8: 00002241
P9:
P10:

Faulting application name: MeGUI.exe, version: 1.0.2525.0, time stamp: 0x54fc5b03
Faulting module name: bass.dll, version: 2.4.4.0, time stamp: 0x4ad476cd
Exception code: 0xc0000005
Fault offset: 0x00002241
Faulting process id: 0x%9
Faulting application start time: 0x%10
Faulting application path: %11
Faulting module path: %12
Report Id: %13
Faulting package full name: %14
Faulting package-relative application ID: %15

The source of the error is .NET Runtime so I have made sure that my runtime files are not corrupted and up to date. I'm running 4.5.2 which seems to be the latest, but this doesn't stop the crash.

I have also tried replacing the bass.dll files from the ones from the official website to no avail as well.

Does anyone have any ideas?

[tebasuna51]

@aegisofrime
Works fine for me.
Please put your logfile.

Try replacing the bass files from:
http://forum.doom9.org/showthread.php?p=1702473#post1702473

[Taurus]

Just tried bassaudio (build in) and the one tebasuna51 linked to
with fdkaac, quaac and nero on some wav files.
All worked as expected.
Maybe your source files are a little suspicious?!
Could not try all kind of combinations, sources, but I'm using bassaudio quite often without any errors.

[hello_hello]

Is the following warning in MeGUI's log file some sort of x264 oddness, or is there a reason for it? The warning only appears for the first pass of a 2 pass encode, and only when "slow first pass" is not checked. The warning might be perfectly normal for all I know. I rarely use 2 pass encoding.

This is the log for the first pass. I've highlighted the relevant bits. That's probably be easier than explaining the problem.

Thanks.

[Warning] Log for job1 (video, test.avs -> )
-[Information] [25/03/15 4:41:15 PM] Started handling job
-[Information] [25/03/15 4:41:15 PM] Preprocessing
-[Information] [25/03/15 4:41:15 PM] Avisynth input script
--[NoImage] LoadPlugin("C:\Program Files\MeGUI\tools\ffms\ffms2.dll")
--[NoImage] FFVideoSource("E:\test.mkv", cachefile="D:\test.ffindex", fpsnum=25, fpsden=1, threads=1)
--[NoImage] ColorMatrix(mode="Rec.709->Rec.601", clamp=0)
--[NoImage] Spline36Resize(960,540,1,0,-1,0)
--[NoImage] Trim(0,499)
-[Information] [25/03/15 4:41:15 PM] resolution: 960x540
-[Information] [25/03/15 4:41:15 PM] frame rate: 25/1
-[Information] [25/03/15 4:41:15 PM] aspect ratio: 16:9 (1.778)
-[Information] [25/03/15 4:41:15 PM] Job commandline: "C:\Program Files\MeGUI\tools\x264\x264.exe" --level 4.1 --preset slow --tune film --pass 1 --bitrate 2500 --stats "D:\test 2 pass.stats" --vbv-bufsize 78125 --vbv-maxrate 62500 --no-fast-pskip --colormatrix bt470bg --sar 1:1 --output NUL "D:\test.avs"
-[Information] [25/03/15 4:41:15 PM] Process started
-[Information] [25/03/15 4:41:15 PM] Standard output stream
-[Warning] [25/03/15 4:41:15 PM] Standard error stream
--[Information] [25/03/15 4:41:16 PM] avs [info]: 960x540p 1:1 @ 25/1 fps (cfr)
--[Information] [25/03/15 4:41:16 PM] x264 [info]: using SAR=1/1
--[Warning] [25/03/15 4:41:16 PM] x264 [warning]: VBV bitrate (62500) > level limit (50000)
--[Warning] [25/03/15 4:41:16 PM] x264 [warning]: VBV buffer (78125) > level limit (62500)
--[Information] [25/03/15 4:41:16 PM] x264 [info]: using cpu capabilities: MMX2 SSE2Fast SSSE3 SSE4.1 Cache64
--[Information] [25/03/15 4:41:16 PM] x264 [info]: profile Main, level 4.1
--[Information] [25/03/15 4:41:22 PM] x264 [info]: frame I:2 Avg QP:11.29 size: 23715
--[Information] [25/03/15 4:41:22 PM] x264 [info]: frame P:210 Avg QP:19.34 size: 19615
--[Information] [25/03/15 4:41:22 PM] x264 [info]: frame B:288 Avg QP:19.50 size: 8905
--[Information] [25/03/15 4:41:22 PM] x264 [info]: consecutive B-frames: 11.6% 30.4% 13.2% 44.8%
--[Information] [25/03/15 4:41:22 PM] x264 [info]: mb I I16..4: 63.3% 0.0% 36.7%
--[Information] [25/03/15 4:41:22 PM] x264 [info]: mb P I16..4: 25.5% 0.0% 0.0% P16..4: 62.8% 0.0% 0.0% 0.0% 0.0% skip:11.7%
--[Information] [25/03/15 4:41:22 PM] x264 [info]: mb B I16..4: 4.9% 0.0% 0.0% B16..8: 34.9% 0.0% 0.0% direct:14.7% skip:45.5% L0:25.7% L1:41.4% BI:32.9%
--[Information] [25/03/15 4:41:22 PM] x264 [info]: final ratefactor: 17.50
--[Information] [25/03/15 4:41:22 PM] x264 [info]: direct mvs spatial:63.9% temporal:36.1%
--[Information] [25/03/15 4:41:22 PM] x264 [info]: coded y,uvDC,uvAC intra: 46.6% 67.9% 26.9% inter: 20.9% 33.1% 3.7%
--[Information] [25/03/15 4:41:22 PM] x264 [info]: i16 v,h,dc,p: 26% 28% 28% 19%
--[Information] [25/03/15 4:41:22 PM] x264 [info]: i4 v,h,dc,ddl,ddr,vr,hd,vl,hu: 14% 25% 14% 6% 10% 5% 15% 4% 7%
--[Information] [25/03/15 4:41:22 PM] x264 [info]: i8c dc,h,v,p: 53% 24% 17% 7%
--[Information] [25/03/15 4:41:22 PM] x264 [info]: Weighted P-Frames: Y:6.7% UV:1.9%
--[Information] [25/03/15 4:41:22 PM] x264 [info]: kb/s:2692.42
--[Information] [25/03/15 4:41:22 PM] encoded 500 frames, 80.40 fps, 2692.42 kb/s
-[Information] [25/03/15 4:41:22 PM] Postprocessing
-[Information] [25/03/15 4:41:22 PM] Job completed

[LigH]

The explicit VBV limits seem to apply for high AVC profiles only. So this x264 warning might be more or less correct, provided that x264 does not yet assume to need High Profile for a turbo 1st pass.

[hello_hello]

The explicit VBV limits seem to apply for high AVC profiles only. So this x264 warning might be more or less correct, provided that x264 does not yet assume to need High Profile for a turbo 1st pass.

Cheers. Yes I guess x264 is assuming baseline or main profile for the first pass. I wonder why it doesn't when it's a slow first pass? Not that it matters, I was just curious.

Thanks.

[LigH]

I wonder if that warning can be circumvented by explicitly adding "--profile high[10]" to the 1st pass call when these parameters with maximum VBV values are added too.
__

P.S.:

Just discussed briefly in IRC, turbo 1st pass always assumes Main Profile because 8x8dtc is disabled. This warning has a minor relevance, VBV values don't matter much during a 1st pass.

[sneaker_ger]

This warning has a minor relevance, VBV values don't matter much during a 1st pass.
It has no relevance at all because x264 uses the --vbv- parameters instead of enforcing the level limit.

[cengizhan]

my megui suddenly stopped working. upon program start megui says that "Fatal Error. megui encountered a fatal errorr and may not be able to proceed. reason:index was outside the boundaries of the array". if i click ok, program closes immetiately.
Description:
Stopped working

Problem signature:
Problem Event Name: CLR20r3
Problem Signature 01: megui.exe
Problem Signature 02: 1.0.2524.0
Problem Signature 03: 54e3c3f7
Problem Signature 04: MeGUI
Problem Signature 05: 1.0.2524.0
Problem Signature 06: 54e3c3f7
Problem Signature 07: 852
Problem Signature 08: 0
Problem Signature 09: System.IndexOutOfRangeException
OS Version: 6.3.9600.2.0.0.256.48
Locale ID: 1055

[hello_hello]

Just discussed briefly in IRC, turbo 1st pass always assumes Main Profile because 8x8dtc is disabled. This warning has a minor relevance, VBV values don't matter much during a 1st pass.

Thanks for the info. I figured it didn't matter but I was curious as to "why". Now I know.

Thanks.

[Solon8]

Maybe this is a stupid question, but I have to ask it to learn: if I add, say, 8 GB of RAM, will encoding wth MeGUI be any faster? I already have a good CPU (4.0 GHz) and 8 GB of RAM.
Would the improvement from 8 GB of RAM be trivial as maybe MeGUI only uses the CPU? Or would it help a lot and I could grasp a good number of FPS? Thank you.

[sneaker_ger]

No speed increase.

[Solon8]

No speed increase.

OK, thank you for your answer.

[Zathor]

my megui suddenly stopped working. upon program start megui says that "Fatal Error. megui encountered a fatal errorr and may not be able to proceed. reason:index was outside the boundaries of the array". if i click ok, program closes immetiately.

Please download this file and replace your megui.exe:
http://megui.org/auto/megui-core_2525.zip

Does it fix the problem?

[cengizhan]

Please download this file and replace your megui.exe:
http://megui.org/auto/megui-core_2525.zip

Does it fix the problem?

Yes. :thanks:

[salam2009]

Hi everyone,
I get this frustrating mkvmerge error occasionally after encoding videos (without adding their audio tracks) using x264 Encoder (which I need) then muxing the result with the audio from the file source.

"video.720p.mkv: Error in the Matroska file structure at position 4010858. Resyncing to the next level 1 element.
The last timecode processed before the error was encountered was 00:00:19.978000000.
Resyncing successful at position 4782373.
The first cluster timecode after the resync is 00:00:25.025000000."

Now when the video reaches the defective minutes, the picture freezes with continuous audio until the point of the first cluster timecode arrives!
If the error doesn't show up in mkvmerge, the muxed file will probably get the same issue!
I tried the old versions of mkvmerge to be sure but got the same error, so it must has something to do with MeGUI encoding process.
I'm using v2525 of MeGUI with updated components and even tried reinstalling it along with K-Lite Mega Codec Pack but sadly that didn't help either!
Any tip would be greatly appreciated.
Thanks a bunch!

Cheers,
Salaam

[LouieChuckyMerry]

Hello and thanks in advance for any help, and an Extra Big thanks for MeGUI :) . I have a simple question: is there a built in feature--or can anyone think of a way--to make MeGUI "pause" or "rest" for a selectable amount of time between queued jobs? I ask because often I'm away from home for weeks at a time and I'd love to have MeGUI chug away at my collection of sources to be encoded, but with MT AviSynth I'm able to achieve 100% CPU usage and I figure that it's not necessarily a good idea to have my CPU running at 100% for 10+ straight days. I've been queuing enough jobs to keep my computer busy for around 3 days straight without apparent issue, but if I could queue, for example, 2 days worth of jobs, then queue a 12 hour break, then repeat I'd be very pleased. I searched for an answer without success, but probably because I'm using the wrong terms. Any relevant input is much appreciated, thanks for your time.

[LouieChuckyMerry]

Now when the video reaches the defective minutes, the picture freezes with continuous audio until the point of the first cluster timecode arrives!
If the error doesn't show up in mkvmerge, the muxed file will probably get the same issue!


In the past I've occasionally experienced a similar problem, without an error message, and after much effort I've decided that it was some combination of fragmented files (my storage drive's an HDD) and poor mkv muxing. Since then I've kept my storage drive defragmented (defragmenting the sources before muxing) and checked the mkv files (sampling the audio-video sync at the beginning, middle, and end of the mkv) after muxing and before encoding, and I've not experienced this problem since.

[AMED]

Hello and thanks in advance for any help, and an Extra Big thanks for MeGUI :) . I have a simple question: is there a built in feature--or can anyone think of a way--to make MeGUI "pause" or "rest" for a selectable amount of time between queued jobs? I ask because often I'm away from home for weeks at a time and I'd love to have MeGUI chug away at my collection of sources to be encoded, but with MT AviSynth I'm able to achieve 100% CPU usage and I figure that it's not necessarily a good idea to have my CPU running at 100% for 10+ straight days. I've been queuing enough jobs to keep my computer busy for around 3 days straight without apparent issue, but if I could queue, for example, 2 days worth of jobs, then queue a 12 hour break, then repeat I'd be very pleased. I searched for an answer without success, but probably because I'm using the wrong terms. Any relevant input is much appreciated, thanks for your time.As long as your cooling is ok then it will be fine to run your CPU at 100% for weeks\months. I'm sure your computer will be obsolete well before x264 encoding kills it.

[LouieChuckyMerry]

As long as your cooling is ok then it will be fine to run your CPU at 100% for weeks\months. I'm sure your computer will be obsolete well before x264 encoding kills it.

Thanks for your reply, AMED, I appreciate it, and my computer is already obsolete, ha ha, but it's the only one I have. Define "ok"? It's a laptop, elevated on an open aluminum pad. with a small fan blowing down on it from above. I live in the tropics and can't leave the A/C running when I'm not home. I understand where you're coming from, but I'd still prefer to give it a rest every two or three days. Any thought on how to do that with MeGUI? Some kind of dummy file? Anything?

[AMED]

Probably easier to just do smaller batches of encodes.

[salam2009]

In the past I've occasionally experienced a similar problem, without an error message, and after much effort I've decided that it was some combination of fragmented files (my storage drive's an HDD) and poor mkv muxing. Since then I've kept my storage drive defragmented (defragmenting the sources before muxing) and checked the mkv files (sampling the audio-video sync at the beginning, middle, and end of the mkv) after muxing and before encoding, and I've not experienced this problem since.

Lucky for you. I defragmented my HDD & even tried encoding on another HDD and nothing has changed!
Thanks for the input.

[LouieChuckyMerry]

AMED: I understand that, but it's not possible. The point of my original post was that I'm not home to queue smaller batches so I'm looking for a way to add a "dummy" encode, or some such, to rest the CPU for half a day every couple days in a one to three week queue. I wouldn't have the question if I was home to tend the queue :) .


salam2009: sorry that didn't help, I wish I knew more.

[ryszardzonk]

Guys I am using following profile in avisynth script creator for files I indexed using l-smash with Megui File Indexer.

<input>
AudioDub(last, LWLibavAudioSource("source location", av_sync=true))
AssumeTFF()
Trim(111,222) ++ Trim(333,444)
Audio=KillVideo()
AudioDub(last,Audio)
Load_Stdcall_Plugin("C:\Program Files\MeGUI\tools\yadi\yadif.dll")
Yadif(order=-1)
crop(2, 2, -2, -2)
Spline36Resize(720,400) # Spline36 (Neutral)
Import("C:\Program Files\MeGUI\tools\avisynth_extra\_load\degrain.avs")

degrain.avs
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_extra\TTempSmooth\TTempSmooth.dll")
ttempsmooth()
LoadPlugin("C:\Program Files\MeGUI\tools\avisynth_extra\RemoveGrain\RemoveGrainSSE3.dll")
RemoveGrain(mode=1)

My question is what to do to improve import and .avs save speed of files indexed with l-smash, because those operations can take for like an minute on my Intel Q9400 processor or even longer the larger indexed file is. Adding resulting .avs script for audio queue is fast as click of a mouse while adding video to the queue takes just as long as saving it.

Where is this lag coming from? I have never experienced it with with files indexed with DGIndex* tools.

Megui version - 2525
L-smash version - r784

[LigH]

Some source formats are easier to index than others, especially when they already contain a keyframe index which can be read separately (e.g. AVI, MKV); for more broadcast oriented containers without such index chunks (especially TS), an indexer application has to follow the whole file, trying to demultiplex the streams and looking for starts of decodable blocks in each stream, which is a lot more elaborate.

Indexers supporting only a small range of input formats (few containers, one video stream only) may be faster (ignoring unsupported streams) than more generic indexers supporting a wider range (more containers, several audio streams too, maybe even subtitles).

[ryszardzonk]

I understand that indexing itself can take time, but I was referring to the situation where the index is ready and I am preparing avs script based on the lwi index I input to the "avisynth script creator" inside megui. Perhaps megui is reindexing stream only for trimmed parts?

[LigH]

It is not possible to index only trimmed parts. You may have chosen trim regions which don't match decodable ranges (GOPs). The trims will be applied after the whole source is indexed and then loaded.

The smaller the decodable units, the larger the index will be. Uncompressed or losslessly compressed sources (especially keyframe-only video formats and PCM audio) can be a real pain, causing huge indexes to be created, which have to be loaded into RAM while opening a source file, except a GUI would know when to avoid the caching to avoid huge indexes where they are not necessary. As a thumb rule, you should possibly prefer AviSource over L-SMASH Source for AVIs with lossless/DV/MJPG video and PCM audio, if you don't have an option to disable indexing.

[ryszardzonk]

My sources are only TS files recored from DVB streams in MPEG2 and MPEG4 formats. As I record some tv channels for extended period of time it is important to use only needed parts and cut out the rest. DG* tools do quite fine job for most of them, but for those with most advanced forms of codecs that they are not able to handle I am using l-smash to index. I understand l-smash has to index the whole file which obviously would take time which is no problem, but after file is indexed and I want to load LWI index into AVS script creator it takes long there and so does the process of saving the script and loading it in the queue. Seems like 30-60sec for that task means it does there more than loading file into the RAM hence the question where the delay is coming from as for other indexes it was almost instant.

[LigH]

It may also be possible that MeGUI deletes the existing index to enforce recreating it when you create a new AviSynth script, because the indexer does not recognize if the index is up to date, and may not create a new index when you have a new content with the same file name, so L-SMASH Source may try to open new content with an old index which doesn't match the new content with the same file name...

[Zathor]

That should not happen. Does it happen? Then I need to have a look and fix it.

[salam2009]

Hi everyone,
I get this frustrating mkvmerge error occasionally after encoding videos (without adding their audio tracks) using x264 Encoder (which I need) then muxing the result with the audio from the file source.

"video.720p.mkv: Error in the Matroska file structure at position 4010858. Resyncing to the next level 1 element.
The last timecode processed before the error was encountered was 00:00:19.978000000.
Resyncing successful at position 4782373.
The first cluster timecode after the resync is 00:00:25.025000000."

Now when the video reaches the defective minutes, the picture freezes with continuous audio until the point of the first cluster timecode arrives!
If the error doesn't show up in mkvmerge, the muxed file will probably get the same issue!
I tried the old versions of mkvmerge to be sure but got the same error, so it must has something to do with MeGUI encoding process.
I'm using v2525 of MeGUI with updated components and even tried reinstalling it along with K-Lite Mega Codec Pack but sadly that didn't help either!
Any tip would be greatly appreciated.
Thanks a bunch!

Cheers,
Salaam

That should not happen. Does it happen? Then I need to have a look and fix it.

What about me? :(

[Zathor]

Sorry, no clue. Post a full log please. Also run only the command line of the encoding to see if MeGUI is the problem.

[salam2009]

@Zathor
Here you go:
http://pastebin.com/7X64tJeS
It used to encode properly before! I even tried without any AviSynth script and the same thing.
Thanks for any tip :)

[ryszardzonk]

I have done some testing to see what is happening and why the delay in queue addition while using l-smath as index. I have used 4 different files with different codecs. Here is step by step what I did
1. created file indexes with CTRL+ F2 [ l-smash, select first audio track only, uncheck "on completion load files"]
2. created avs scripts with CRTL+R [used & edited preset]
3. saved scripts and timed how long would it take load into Input/Video encoding screen [video preview disabled in megui options to speedup process as with it it takes even longer]
4. added audio to the queue [no delay in load time as it instantly appeared in the queue]
5 added video to the queue [timed the delay before it appeared in the queue]

What strikes me is the difference between handling audio and video from the same script. Obviously for video avs script gets checked for proper settings, but so it does for DG* tools indexes and there addition to the queue is instant. What might be important is I create DG* indexes directly using those apps outside of megui for only the needed parts and just load created that way indexes into megui.

Times
http://pastebin.com/kWVdhyXe
Logs
http://pastebin.com/5ye0thEi
AVS Scripts
http://pastebin.com/Gzjjjdn5

[videoh]

DG* tools do quite fine job for most of them, but for those with most advanced forms of codecs that they are not able to handle Are you talking about HEVC? It sounds highly dubious that you capture DVB TS with HEVC video, and your links point to simple MPEG2 video. So please tell what formats you are unable to use with DG tools, and why you cannot use DG tools on the source you linked to.

[ryszardzonk]

If you look closely 2 of them are MPEG2 and other two are AVC not handled by DGIndex nor DGAVCIndex or DGAVCIndexDI. They samples are meant to compare results of different cases and if You notice delays happen in both cases.