Selur's Little Message Board - Weird CRASH work-around !

Helluh,

First of , currently on hybrid build → 2024.16.06.01 .. Win11 still on "23H2" ..

I like to report these weird crashes with some (Not all) source files..

Every now and then, hybrid crashes right at encode stage → "Crash Exit Code 10" !!

The only way to get arround that , is to remux the source file every time that happends !? Happends mostly with mkv files !!

Thats another thing.. so far never with TS containers... to my knowledge..

So, something strange about the fact that the file first needs to be remuxed in order for hybrid to handle the source properly !!

Cheers,
td

check audio codec and built-in subtitles for "copy protection"

PS
The Japanese love/LIKE to add copy protection

@ToiletDuck:
Your post states:

you use Win11 23H2 with Hybrid 2024.16.06.01
for some mkv files (no details about these) Hybrid crashes right at encode stage with "Crash Exit Code 10".
if you remux the files (I guess using mkvtoolnix), the encoding works.

So it seems the issue might be some incompatibility with your source and whatever is doing the decoding.
It might be that the used decoder / source filter can't handle the source or the source is broken somehow.
Since, I assume you remuxing from .mkv to .mkv, helps, the latter seems more likely.
It could also be that some antivirus software or similar is interfering.

Can't reproduce, can't really help with random problems.

(02.09.2024, 04:09)humanoid86 Wrote: [ -> ]

PS
The Japanese love/LIKE to add copy protection

..🤨

(02.09.2024, 05:06)Selur Wrote: [ -> ]@ToiletDuck:
Your post states:
you use Win11 23H2 with Hybrid 2024.16.06.01

for some mkv files (no details about these) Hybrid crashes right at encode stage with "Crash Exit Code 10".

if you remux the files (I guess using mkvtoolnix), the encoding works.

So it seems the issue might be some incompatibility with your source and whatever is doing the decoding.
It might be that the used decoder / source filter can't handle the source or the source is broken somehow.
Since, I assume you remuxing from .mkv to .mkv, helps, the latter seems more likely.
It could also be that some antivirus software or similar is interfering.

Can't reproduce, can't really help with random problems.

Have checked the source file thorougly, and can't find anything strange about it..
i.e: i know crashes can happend when timecodes are fubar for instance.. but the source seems to be clean,yet.. After remux, containing every bit of info (sub, chapters, audio etc..) hybrid doesn't have one bit of problem with it encoding it 🤔..

So, if the content (tracks, subs, audio etc) of the source would cause this, i shouldn't be able to remedy / work around that issue that easily .. right ?

Also, an bad source file shouldn't be playing flawless on a Hw/sw restricted player... In 99,99% of the cases if something is wrong about the source file, that alway's will translate into an problematic playback .. i.e hickups, distortion, no sound / broken sound, no video / missing frames during playback.. you name it ... atleast in my experience..

Also, i have had these EXACT crashes before in the past, and instead of just remuxing the thing (easiest work around) , i did work around that by changing containers restrictions and/or some settings in VapourSynt→Source settings .. But i don't know what i have changed in combo to overcome these weird crashes .. just fyi, something about hybrid isn't playing nice with some sources ... !
Ta TA
Toilet(°^°)

... update..

Hmm... just copied/moved (no remux) the exact source file to another storage device (internal nvme.m2) and hybrid is playing nice and started the encoding whitout any crashes Dodgy

!!

Strange, it picks just this file to refuse and encode from the default HDD drive, but other files that are on the same HDD do in fact encode (no crashes) .. it just crashes with that One specific particular file 🤔...
So this seems to be NOT a remux fix / work around...!

I wonder... could the problem be → using very long file names ?

EDIT 2: Yep → CONFIRMED , seems using Long / weird filenames will induce hybrid to crash 😑
That's ↑ the quickest fix , my personal best imo 🤭

Although, iam shocked long filenames is STILL a THING ... 😦! An restriction of the Ol DOS dayz 😑!!

Without any details, nothing I can check, workaround, etc., but happy you found the cause of your problem.

Cu Selur

aah....

when coding there are multi-threaded HDD drives and letters of the name with symbols, like &&&&?????!!!!!!!!!!!!@@@@@@@@@@%%%%%&&&&^^^^^^^^^^^^^^^^^''''''''''''''''''''''' and etc

PS
encoding always 99.99% without errors
00.01% error due to:

- multi-threading HDD/SSD/memory/routes...
- CPU/GPU/OS due to codec or container or name (containing Hieroglyphs or Symbols) or filter

Okay, not looking into that.
That just seems broken to name stuff like that.

(02.09.2024, 14:29)Selur Wrote: [ -> ]Without any details, nothing I can check, workaround, etc., but happy you found the cause of your problem.

Cu Selur

Do i sense a "debug file request" there 😏 ?

I get it.. And i did created one to see and check it for myself, ..

But i didn't find anything unusual compared to an debug from an normal working source file , you know !
so.. but if you still want it to DL and have an look, i'll post it..

Granted, the Devilish devil 😈 is in the "details" sure enough 😉.

And again, just ran a test sample (long filename) = no errors / crashes..
But check this, running the complete media file (same long filename) = crash

Here's the ↑ other thing we have covered numerous times in the past ,→ for some reason it's impossible to reproduce an certain crash/issue using an small samples taken from the original source !?

For some reason , hybrid doesn't have any problem processing the small samples completely ...

Wich leads me to believe, something has been corrected / changed during remux for hybrid to complete the task.. yet the strange part is, i can overcome all this read/write stuff by just changing the file name.. wich is comparing apples with oranges and raises another question !?!? Is it "realy" the source.. or just a matter of the filename !?

And thats the interesting and most funny part of all...

There's 2 way's to work around that issue.. Either i have to remux it keep the same EXACT LONG filename, and hybrid will process it completely despite of the long complex file name..

Orrr... i simply use the quickest route, and just shorten the filename from the source... Strange... 2 complete different approaches, yet one is necessary to defeat this strange issue !

Up untill know i thought only a remux would work around this, but clearly something about what and how long the filename is from the source is causing this aswell... interesting..

Anyhow, it's nothing that can't be remedied by adjusting the source or settings in hybrid fortunately 🥹👌

(02.09.2024, 15:00)humanoid86 Wrote: [ -> ]aah....

when coding there are multi-threaded HDD drives and letters of the name with symbols, like &&&&?????!!!!!!!!!!!!@@@@@@@@@@%%%%%&&&&^^^^^^^^^^^^^^^^^''''''''''''''''''''''' and etc

... duck senses tingling (° ^°) *smelling a malicious bot * Dodgy

..

Ta Ta
TD(° ^°)

If someone does a proper report with reproducible data, I will probably look into it.
Got no time or motivation for whatever your posts are meant to be.
¯\_(ツ)_/¯

(02.09.2024, 18:59)Selur Wrote: [ -> ]If someone does a proper report with reproducible data, I will probably look into it.
Got no time or motivation for whatever your posts are meant to be.
¯\_(ツ)_/¯

.. glad we are on the same page Dodgy

..

My posts are meant to be helpfull.. If not to you atleast it will be helpfull to others facing the same problem, iam sure of..
Have posted several "work arounds" in the past to quite some issues hybrid is struggling with fyi.. 🫡

ta ta