No mux on excessive subjobs?

[b0red]

Okay, that seems to work.
Problem was: Hybrid assumed that it had 85 unique files (giving different uids to the same file is just wrong!), so the muxing call didn't start since it assumed the missing files would be created later.
-> will build a new dev version and send you a link for testing in ~20min via pm.

Cu Selur

I don't think the duplicates affect the muxing after another experiment while waiting for the Dev version to download:
Made 2 altered files:
In one I deleted all the font attachments and just added a single font twice, it muxes fine but there's a waiting left due to the duplicate file already being deleted:
   
In another I deleted the duplicates manually and added the android Roboto fonts to make it reach 100 sub jobs and it doesn't mux
[attachment=1474]

After installing the Dev version I ran the original sample and it muxed because the number of subjobs dropped below 100 (and had the nice benefit of smaller file output and not stopping a batch).
Running my no duplicate version above with the Dev also results in no mux (& job 100 running).

mux @ 11 and 100+ sub jobs is a rather unlikely combination admittedly but it's showing a bug exists somewhere...

[Selur]

it muxes fine but there's a waiting left due to the duplicate file already being deleted:

That was the point, of the dev verison, making sure that each file one appears once so it isn't included multiple times and thus not deleted.

But seems like there's still some problem since some files still get deleted before the muxing.
-> Looking into it.

Cu Selur

[Selur]

Okay, you are right the number exceeding 99 causes a problem too. (the not properly handling the duplicates also was an issue)
What should happen is that Hybrid should go through the subjobs sorted by their number and then only execute a job if the jobs with a lower number are not hindered by it. In general this works fine. Problem is that the sorting is not by number but by string atm. so 2 > 100 etc.
-> will have to go through the source so see where this happens exactly and how to fix this.

Cu Selur

[Selur]

Okay, I hink I fixed it.
-> Will send you a new link via pm for testing in ~15min minutes.
Going to bed, once the upload is finished, but will look at it tomorrow in case it isn't fixed then.

Cu Selur

[b0red]

Seems to be working fine now.

P.S. - Could you consider adding a CleanUp (or adding it to reset) a function where right clicking on a job deletes all files with that JobID in the filename in the temp output folder?
It takes up a lot of space after a crash or non-finishing encode until you remember to do it manually.

[Selur]

Could you consider adding a CleanUp (or adding it to reset) a function where right clicking on a job deletes all files with that JobID in the filename in the temp output folder?
It takes up a lot of space after a crash or non-finishing encode until you remember to do it manually.

I'll think about it. Hybrid by default doesn't delete content on a crash to:
a. not potentially delete needed/wanted content (if for example you process a source for a week and then there's a small but with the muxing, it is usually preferable to be able to manually mux the content)
b. help when looking for problems to figure out what whent wrong.

Cu Selur

[b0red]

Heh, came across another edge case with matroska attachments:
   
Case sensitivity.
   
[attachment=1479]

P.S.- think you might have forgotten to delete something in the font sorting after Hybrid has finished with it: after doing a couple of batches of of series the font deletion slowed down massively with the font's starting in upper case taking 2 seconds EACH to delete, oddly the numbers then lower case ones deleted almost immediately? fixed after a restarting hybrid.

P.P.S - have also had a few random cases where I go to check on the minimised Hybrid... and it isn't there. Starting hybrid then results in an old job queue, no idea how to recreate it...

[Selur]

I can reproduce the problem.
Will look at it and hopefully fix it tomorrow after work.

Cu Selur

[Selur]

I see the problem.
Once the font is added as:
"2021-08-03@07_26_50_1054_LEVIBRUSH.TTF"
and once as
"2021-08-03@07_26_50_1054_LEVIBRUSH.ttf"
on any OS aside from Windows that would be two different file names,.. :/
-> will write a workaround for it after work.
(wondering whether that file will properly playback on non-Windows systems,...)

Cu Selur

[b0red]

Did some research on Substation alpha (.ssa/.ass) and .ttf/.otf formats after noticing that hybrid appends the Job ID prefix to attachments yet it still works correctly...

Seems like libass & VSfilter doesn't look at the filename at all!

The container (usually matroska) gives it a list of local attachments, libass\vsfilter queries the files and looks for the internal values for font format and font family then concatenates the same font family together to build up a local font cache for the subtitles to use.

The .ass format in it's style section takes a font_family or font_sub_family value, looks at the font cache and if it can't find it then it goes to the system default (Arial on windows).

Tested this by looking at a known font at a certain timestamp, removing it, noting that the subtitle changed to Arial, changed the font extension from .otf to .ttf and attached it back and the correct font was shown then removed the font again and removed the file extension entirely, reattached it and it rendered correctly (mkvtools listed it's MIME type as "font/otf".

So realistically it doesn't matter what the filename, filecharactercase or even extension is as long as the container tells the subtitle library executable that it's a font!


That said hybrid probably shouldn't be sticking the jobID prefix to attachment names as it might break something somewhere.
Easiest solution would be to extract to a jobID folder with the proper original file names, ASSume duplicates contain the same data & let them overwrite the other, stick whatever is left into the new output file and simply delete the folder at the end?