MKVToolNix v79.0 released

[hubblec4]

Hi Mosu

This time I have a question about chapters :-)

I want split an mkv with the split option "By Parts based on timestamps" and insert new external chapters (SimpleChapters).
Here a very short options file:

[
  "--output",
  "F:\\Output.mkv",
  "--no-chapters",
  "--no-global-tags",
  "(",
  "F:\\Input.mkv",
  ")",
  "--split",
  "parts:00:00:00.000000000-00:01:05.586000000,+00:01:42.299000000-00:02:40.571000000",
  "--chapters",
  "F:\\chapters.xml"
]

The chapters file:

CHAPTER01=00:00:00.000
CHAPTER01NAME=Kapitel 1
CHAPTER02=00:00:20.000
CHAPTER02NAME=Kapitel 2
CHAPTER03=00:00:40.000
CHAPTER03NAME=Kapitel 3
CHAPTER04=00:01:00.000
CHAPTER04NAME=Kapitel 4
CHAPTER05=00:01:20.000
CHAPTER05NAME=Kapitel 5
CHAPTER06=00:01:40.000
CHAPTER06NAME=Kapitel 6
CHAPTER07=00:02:00.000
CHAPTER07NAME=Kapitel 7

The issue is, mkvmerge recalculate the external chapter time stamps after first split-pair.

Chapters from Output.mkv:

CHAPTER01=00:00:00.000
CHAPTER01NAME=Kapitel 1
CHAPTER02=00:00:20.000
CHAPTER02NAME=Kapitel 2
CHAPTER03=00:00:40.000
CHAPTER03NAME=Kapitel 3
CHAPTER04=00:01:00.000
CHAPTER04NAME=Kapitel 4
CHAPTER05=00:01:05.666
CHAPTER05NAME=Kapitel 6
CHAPTER06=00:01:23.367
CHAPTER06NAME=Kapitel 7

Last both chapter times are now wrong.

OK, wrong is not right. I think when mkvmerge make such a split case without external chapters and keep existing chapters than it is important to shift the time stamps.
But I want the chapter times from the external chapters.

Is there something that I missed or could you change this so that when external chapters are used then all chapter times stay untouched?

[Mosu]

mkvmerge assumes that all content belongs together, no matter whether or not splitting is used. It therefore assumes that the chapter timestamps will have to be shifted if the output timestamps are shifted.

There's no option to change this, and I don't plan on adding one.

[hubblec4]

Originally Posted by Mosu

...
There's no option to change this, ....

An option is not absolutely necessary, an automatic would be better.

When I append files (I know appending is not splitting) with chapters, all chapter times will be shifted, but when I use an external chapters.xml file, there is no recalculate for the chapter times.

I guess it would be very easy to do the same for splitting.

If external chapters are present then mkvmerge must not assumes that all content belongs together and you can skip the recalculate function.

[Mosu]

I won't add anything in that direction.

[hubblec4]

Hi Mosu

I have a question about Tags and the pre-switch "all:" and "global:".

propedit My.mkv --tags all:tags.xml
propedit My.mkv --tags global:tags.xml

I had changed in my chapterEditor from all: to global: and it seams that all work, but it breaks the Matroska Tags editor.
What are the differences of this switches?

[Mosu]

With "all", all tags are replaced. With "global", only those tags that do not target a track (via "Targets" → "TrackUID") are replaced.

[hubblec4]

Ah ok, global: is depend of Targets->TrackUID. Good to know.

[Megalith]

Would it be difficult to add an option for auto-sorting source files? Ideally, the order should be video, audio, and then subtitles, but the video file is always last when I drag them into MKVToolNix due to the naming convention my de-muxer uses.

[Mosu]

Auto-sorting wouldn't be too hard. Please open a feature request over on [Gitlab](https://gitlab.com/mbunkus/mkvtoolnix/issues/) for that so I won't forget about it.

[Mosu]

Hey,

time for another release of MKVToolNix, v26.0.0. It's on the smaller side regarding the number of changes.

Here are the usual links: the MKVToolNix home page, the Windows installer/portable version & macOS DMG & Linux AppImage and the source code.

The Windows and macOS binaries as well as the Linux AppImage are available already. The other Linux binaries are still being built and will be available of the course of the next couple of hours.

Here are the NEWS since the previous release:

# Version 26.0.0 "In The Game" 2018-08-26

## New features and enhancements

* mkvmerge: chapter generation: if the name template given by `--generate-chapters-name-template` is empty, no names (`ChapterDisplay` master elements with `ChapterString`/`ChapterLanguage` children) will be generated for the chapter atoms. Part of the implementation of #2275.
* mkvmerge: chapters: chapter names generated from MPLS files will now use the name template if one is set via `--generate-chapters-name-template`. Part of the implementation of #2275.
* mkvmerge: mkvmerge will no longer abort with an error message if no audio, video and subtitle tracks should be multiplexed. This allows copying of chapters from non-chapter source files (e.g. Matroska or MP4 files).
* MKVToolNix GUI: the font size in the tool selector on the left will scale with the font size the user selects in the preferences.
* MKVToolNix GUI: the GUI will no longer automatically resize the columns in tree and list views to match the content size. Instead it remembers and restores the widths set by the user. Implements #2353.
* MKVToolNix GUI: multiplexer: the chapter name template will now be set automatically to the name template in the preferences' "chapter editor" section. Additionally the option `--generate-chapters-name-template …` will be passed to mkvmerge in situations when mkvmerge will generate chapters (either because automatic generation is enabled or if chapters are generated for MPLS playlists). Part of the implementation of #2275.
* MKVToolNix GUI: chapter editor: if the chapter name template is empty, chapters will be generated without names. Part of the implementation of #2275.
* MKVToolNix GUI: chapter editor: added an option to remove all chapter names to the "additional modifications" dialog. Part of the implementation of #2275.

## Bug fixes

* mkvmerge: Matroska reader: fixed wrong timestamps when appending Matroska files where the second Matroska file's first timestamp is bigger than 0. Fixes #2345.
* mkvmerge: MP4 reader: fixed division by zero errors during file identification if the timescale is 0 in the `MVHD` atom.
* mkvmerge: Windows Television DVR files are now recognized as an unsupported file type. This prevents mis-detection as MPEG-2 with an accompanying flood of error messages. Fixes #2347.
* MKVToolNix GUI: info tool: under certain circumstances "cues" were shown at the wrong level (inside the previous master element instead of on level 1). Fixes #2361.
* MKVToolNix GUI: job queue: fixed invalid memory handling and consequent crashes when using the "edit in corresponding tool & remove from job queue" option if one of the files in that job contained attached files. Fixes #2368.

## Build system changes

* An AppStream metadata file will be installed in `$prefix/share/metainfo`.

Have fun

[Klaus1189]

v26.0.0 is singed by "LINET Services GmbH"

[Mosu]

That is correct, as explained on the MKVToolNix home page. LINET Services is my own company. It was easier to get a code signing certificate for an organization than for an individual.

[73ChargerFan]

Ouch.. twice in two hours the v26.0.0 GUI crashed but mkvmerge keeps running in the background.

It happened when I was interacting with the Multiplexer tab, but that's all I know. Restarting the GUI works (Which Is Really Cool) - it shows me the job that's running, and the jobs I'd queued before the gui crashed keep starting like nothing happened.

I'll reinstall and restart my system, maybe all the in place upgrades have finally caught up with me.

EDIT:
Turns out now I have two instances of mkvmerge running.

[Mosu]

Well, you'll have to figure out which steps make the GUI crash exactly. I cannot act on "it happens sometimes somehow".

[73ChargerFan]

I'm spending all day doing this, and will try to maybe pay closer attention some of the time. Thanks.

[anddi]

Originally Posted by Klaus1189

Does that help?
https://forum.videohelp.com/threads/...es#post2526077

Yes. Wow. I came back here because I had just noticed that deleting every tag fixes thumbnails on Win10, but after seeing your reply I tried mkvpropedit with just "--delete-track-statistics-tags" option and that alone fixed my thumbnails on Windows 10. I don't use any software for thumbnails whatsoever.

[mkver]

Originally Posted by anddi

Yes. Wow. I came back here because I had just noticed that deleting every tag fixes thumbnails on Win10, but after seeing your reply I tried mkvpropedit with just "--delete-track-statistics-tags" option and that alone fixed my thumbnails on Windows 10. I don't use any software for thumbnails whatsoever.

Then I believe that the change introduced because of this issue is behind this. Someone tell Microsoft that TagDefault has a default value.

[Boulder]

Originally Posted by Mosu

Well, you'll have to figure out which steps make the GUI crash exactly. I cannot act on "it happens sometimes somehow".

I've experienced it as well. This is what Win10 Event viewer shows in the log:

Faulting application name: mkvtoolnix-gui.exe, version: 26.0.0.0, time stamp: 0x00000000
Faulting module name: mkvtoolnix-gui.exe, version: 26.0.0.0, time stamp: 0x00000000
Exception code: 0x40000015
Fault offset: 0x000000000141fcab
Faulting process id: 0x4778
Faulting application start time: 0x01d44126ac2dcb52
Faulting application path: C:\Program Files (x86)\MKVtoolnix\mkvtoolnix-gui.exe
Faulting module path: C:\Program Files (x86)\MKVtoolnix\mkvtoolnix-gui.exe
Report Id: 217c1904-3556-4978-afe9-d91c1dcf07af
Faulting package full name: 
Faulting package-relative application ID:

I've been transferring my encode archives from DVDs to portable HDDs. Some of the old archives are MKV split into parts, and I use MKVToolnix GUI to rejoin them to mux them as a single file on the HDD. So basically I drag-and-drop stuff, use Append, select file and mux.

What I have noticed that after some muxes, my OS turns quite sluggish and restarting MKVToolnix GUI will fix that. If I don't restart, after several rounds of rejoining and muxing files, the GUI crashes by simply vanishing and then it leaves its mark in the Event viewer log. I've had it happen twice, and both times it happened when I dragged a file in the source panel.

If you can come up with a debug build, I might be able to trace the problem for you. I may still have some split files to join

[Mosu]

Thanks. Doesn't help me that much, though.

What you've described sounds like a severe memory leak; the system thrashing would be swapping activity. The crash might then be due to all free memory being exhausted.

I've tried to reproduce this by appending various file types for several minutes now. Memory usage will rise while mux jobs are open, but that's to be expected, and it's not that huge usage either. With ten open settings with ~4 files each, memory usage rises from ~40 MB at start to ~68 MB.

There does seem to be some kind of leak that I can detect as memory usage doesn't drop back to ~40 MB when I close all settings, remove all jobs from the queue & clear the job log.

With those numbers, you'd need hundreds of open mux jobs in order to exhaust even those systems that don't have a lot of memory.

So far this doesn't help me much.

What you could do is have task manager open while you mux and watch the GUI's memory usage. If you notice severe increases due to certain files, I'd highly appreciate it if you uploaded them to my file server along with a description of how exactly you set up the job.

A debug build wouldn't help in this case. I'm convinced that the crash isn't the problem; it's just a symptom of the bug that leads to the system becoming sluggish (like I said, likely a memory leak). Debug builds don't help with memory leaks.

[Boulder]

I just experienced the crash again. There were no signs in the task manager view, normal memory consumption all the time even though the sluggishness started almost immediately after the first job was done. It definitely seems memory related because the sluggishness seems to be more apparent if I have an encoding task running, which means that around 50% of total memory is reserved by vspipe and x265. But like I said, there's nothing visible pointing to a memory leak because there is plenty of memory available right up until the crash.