MKVToolNix v24.0.0 released

[ndjamena]

The latest version of Subtitle Edit can export TextST into PES format.

[Mosu]

You can test your app on virtual machine. I'm using free Vware player with win10. You can easily download iso from torrent sites. (key/activation is not required for trial mode)

I've installed both the 32bit and 64bit versions of Windows 10 Professional (you can get ISO images legally directly from Microsoft without a problem, BTW). I've tried both the 32bit and the 64bit version of MKVToolNix. Here are the results:

| | Windows 10 32bit | Windows 10 64bit |
|---------------------------+------------------+------------------|
| 8.2.0 release 32bit | ✓ | ✓ |
| 8.2.0 release 64bit | – | ✓ |
| 8.2.0 current devel 32bit | ✓ | ✓ |
| 8.2.0 current devel 64bit | – | ✓ |


Meaning that for me, at least, all possible combinations run just fine, and I cannot reproduce the issue locally.

[Atak_Snajpera]

(you can get ISO images legally directly from Microsoft without a problem, BTW)
Downloading iso from torrent is just simpler and faster for me.

[Bigmango]

I've installed both the 32bit and 64bit versions of Windows 10 Professional (you can get ISO images legally directly from Microsoft without a problem, BTW). I've tried both the 32bit and the 64bit version of MKVToolNix. Here are the results:

| | Windows 10 32bit | Windows 10 64bit |
|---------------------------+------------------+------------------|
| 8.2.0 release 32bit | ✓ | ✓ |
| 8.2.0 release 64bit | – | ✓ |
| 8.2.0 current devel 32bit | ✓ | ✓ |
| 8.2.0 current devel 64bit | – | ✓ |


Meaning that for me, at least, all possible combinations run just fine, and I cannot reproduce the issue locally.
Version 8.2 is also working fine here on windows 10 x64 clean install.

[Mosu]

RDF just posted on Github (https://github.com/mbunkus/mkvtoolnix/issues/1384#issuecomment-129027824) that it seems to be a permission problem on the MKVToolNix installation folder caused by the upgrade to Windows 10.

[KoD]

Hi mosu, I've noticed a little user interface issue with the mkvmerge GUI on Ubuntu. It seems like each time a window or dialog is opened, its size is increased over what it was when the window/dialog was last closed. The easiest way to observe this is to start a mux, let it finish and then close the dialog, then start a mux again - now, the dialog that opens is not only moved to a different position (which is somewhat annoying, but not the real issue here) but it's also larger than it was when closing it. This can also be seen with the mkvmerge GUI window itself. After several muxes, the dialog that shows is so big that it's larger than the display area. And this behavior seems to persist after closing mkvmerge and opening it again.

In case it matters, this is on Ubuntu 14.04 Desktop, with the default Unity window manager, and using the 64 bit build of mkvmerge from your apt repository.

[Mosu]

The mkvmerge GUI is not supported anymore and will be removed in release 8.4.0. Please switch to the MKVToolNix GUI.

[KoD]

Ah, ok!

Just tried it now, and there is a problem with the tab titles in the new GUI though:
http://s9.postimg.org/y0kyp07bf/tabs_issue.jpg (http://postimg.org/image/y0kyp07bf/)

[Mosu]

That's a known issue on Linux with certain window managers that's been fixed since the release already. You can compile your own package (https://www.bunkus.org/videotools/mkvtoolnix/source.html#debian_ubuntu_package) for the current development sources, if you want.

[v0lt]

@Mosu
mkvmerge packs TrueHD streams in blocks of 1 ms. I think it is wrong. Standard size TrueHD unit is 50 ms.

sample (https://yadi.sk/i/9yOzspEOiRZsJ)

[Mosu]

No, that's not wrong. Each packet really contains only that few samples.

TrueHD has two types of headers: full ones including a sync word and those small ones that basically consist of the packet's data size only, but nothing more. I've tried to pack them together (one sync frame and all following non-sync frames) into a single Matroska block in the past. That was a monumental failure; no player could play such packed frames properly.

[v0lt]

The problem is that 0.83ms is very small. In addition to send TrueHD HDMI in, we have to group the packages of 24 pieces (20ms).

[nevcairiel]

The problem is that 0.83ms is very small. In addition to send TrueHD HDMI in, we have to group the packages of 24 pieces (20ms).

You have to do that anyway, as you get TrueHD out of BD m2ts this way, so getting it the same way out of all containers is actually a good thing.

[Mosu]

nevcairiel made my point much better than I did. All containers actually packetize TrueHD in such small frames, especially MPEG transport streams.

How certain special outputs require their packets formatted should be of no concern to a container format. Converting from storage to the actual format required for playback is the demuxer's job (additional filters and other processing might be required as well).

[Mosu]

Hey,

I've released MKVToolNix v8.3.0. Even if I'm starting to sound like a broken record: this release implements a lot of enhancements and new features for MKVToolNix GUI, pretty much all of them requested by users. Several bugs in the GUI have been fixed as well.

This is the last release that includes the old GUI (mkvmerge GUI).

Changes for package maintainers: nothing's changed since v8.2.0.

Here are the usual links: the MKVToolNix home page (https://www.bunkus.org/videotools/mkvtoolnix/), the Windows installer and portable version (http://www.fosshub.com/MKVToolNix.html) and the source code (https://www.bunkus.org/videotools/mkvtoolnix/source.html).

All binaries that I provide have been uploaded already.

Here's the full ChangeLog (https://www.bunkus.org/videotools/mkvtoolnix/doc/ChangeLog) since the previous release:

2015-08-15 Moritz Bunkus <moritz@bunkus.org>
* Released v8.3.0.
* MKVToolNix GUI: chapter editor enhancement: pressing return will cause the next appropriate chapter control to be selected depending on where the focus currently is: from a chapter input to the first chapter name, from a chapter name to the next chapter name and from the last chapter name to the next chapter entry's start time. Implements #1358 (https://github.com/mbunkus/mkvtoolnix/issues/1358).

2015-08-14 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: the number of running jobs is shown in the status bar. Implements #1381 (https://github.com/mbunkus/mkvtoolnix/issues/1381).
* MKVToolNix GUI: new job queue feature: added a context menu for force-starting selected jobs. This allows for running more than one job at the same time. Implements #1395 (https://github.com/mbunkus/mkvtoolnix/issues/1395).
* MKVToolNix GUI: new merge tool feature: added an option for automatically setting the »default track« flag to »no« for all subtitle tracks when they're added. Implements #1339 (https://github.com/mbunkus/mkvtoolnix/issues/1339).

2015-08-12 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new merge tool feature: dragging & dropping files onto line edit controls that expect file names (e.g. the »chapter file« control) will set that line edit's text to the dropped file name. Implements #1344 (https://github.com/mbunkus/mkvtoolnix/issues/1344).
* mkvmerge: bug fix: track statistics tags can be kept with the option »--engage keep_track_statistics_tags«. This allows outputting them in verbose identification mode for easier parsing. Fixes #1351 (https://github.com/mbunkus/mkvtoolnix/issues/1351).

2015-08-11 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: new feature: jobs in the queue can now be edited again. For that they're re-opened in the corresponding tool and removed from the queue. Implements #1296 (https://github.com/mbunkus/mkvtoolnix/issues/1296).
* build system: stack protection is enabled when building with gcc on all platforms. For Windows DEP and ASLR is enabled. Implements #1370 (https://github.com/mbunkus/mkvtoolnix/issues/1370).

2015-08-09 Moritz Bunkus <moritz@bunkus.org>
* build system: the Boost detection macros were updated from www.gnu.org resulting in better compatibility with bare-bones shells like dash.
* MKVToolNix GUI: enhancement: the format of the setting and queue files has been changed from INI style to JSON documents. Reading older setting files in INI style remains supported, but saving will convert them to JSON. Together with the other three changes mentioned below this results in a noticeable reduction in the time needed for writing the queue files, e.g. when pressing »start muxing« or when quitting the application.
* MKVToolNix GUI: enhancement: the way the job queue is stored has been changed. Earlier all jobs were stored in the same file (or registry on Windows) as the preferences. Now they're stored in a sub directory called »jobQueue« with one file per queue entry.
* MKVToolNix GUI: enhancement: on Windows the preferences are not stored in the registry anymore, not even if the application has been installed. Instead they're stored in an INI file in the user's AppData\Local directory tree.
* MKVToolNix GUI: enhancement: the number of times the queue files are saved has been reduced. The queue files are also loaded only once on startup, not twice.
* MKVToolNix GUI: bug fix: fixed various crashes when dragging & dropping in all of the tree views (merge tool: files view, tracks view, attachments view; chapter editor: edition/chapter tree, chapter name list; job queue). Fixes #1365 (https://github.com/mbunkus/mkvtoolnix/issues/1365).

2015-08-08 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: enhancement: if an instance is already running when the application is started a second time then the GUI requests that the already-running instance will be activated. Implements #1379 (https://github.com/mbunkus/mkvtoolnix/issues/1379).
* MKVToolNix GUI: new feature: added an option in the preferences for automatically switching to the job output tool whenever the user starts a job (e.g. by pressing »start muxing«). Implements #1376 (https://github.com/mbunkus/mkvtoolnix/issues/1376).
* MKVToolNix GUI: new job output and job queue feature: added a function for opening the output folder. Implements #1342 (https://github.com/mbunkus/mkvtoolnix/issues/1342).
* MKVToolNix GUI: new job output tool feature: added a way to clear the output, warnings and errors views. Implements #1356 (https://github.com/mbunkus/mkvtoolnix/issues/1356).
* MKVToolNix GUI: merge tool bug fix: attachments: sometimes changing values didn't apply the changes to all selected attachments depending on how they were selected. Fixes #1373 (https://github.com/mbunkus/mkvtoolnix/issues/1373).
* MKVToolNix GUI: merge tool bug fix: the automatically suggested description for new jobs contained the file name twice, even in the directory portion. Fixes #1378 (https://github.com/mbunkus/mkvtoolnix/issues/1378).
* MKVToolNix GUI: merge tool bug fix: if »set output file name automatically« is enabled then file names ending with a number in parenthesis (e.g. »Berlin (1962).mkv«) will keep their number in the generated output file name. Fixes #1375 (https://github.com/mbunkus/mkvtoolnix/issues/1375).
* MKVToolNix GUI: merge tool bug fix: the GUI will keep manual changes to the output file name even if »set output file name automatically« is enabled. Fixes #1372 (https://github.com/mbunkus/mkvtoolnix/issues/1372).
* MKVToolNix GUI: bug fix: fixed the stereoscopy drop down box not being re-translated when the GUI language is changed. Fixes #1224 (https://github.com/mbunkus/mkvtoolnix/issues/1224).

2015-07-22 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: chapter editor bug fix: it was possible to drop chapter entries on the top-level reserved for editions. Fixes #1369 (https://github.com/mbunkus/mkvtoolnix/issues/1369).

2015-07-21 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: Windows: if the application has been installed then its settings will no longer be saved in the registry but in an INI file in the user's data application folder (e.g. C:\Users\mbunkus\AppData\Local\bunkus.org\mkvtoolnix-gui).

2015-07-20 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: merge tool enhancement: added »Simple OGM-style chapter files (*.txt)« to the file selection dialog when selecting a chapter file. Implements #1269 (https://github.com/mbunkus/mkvtoolnix/issues/1269).

2015-07-18 Moritz Bunkus <moritz@bunkus.org>
* MKVToolNix GUI: bug fix: fixed compilation when building without curl support. Fixes #1359 (https://github.com/mbunkus/mkvtoolnix/issues/1359).

Have fun.

[hubblec4]

many thanks mosu

the gui start/close very quickly.

There are any changes in the mtxcfg?

[Mosu]

Yes. I've implemented several changes to how the GUI stores its configuration and its job queue. Those are four of the commits listed for 2015-08-09.

The new format is JSON, BTW. The structure itself is the same (meaning the groups and keys have retained their names and the values should be encoded in roughly the same manner they had been encoded before – safe for how escaping is done in JSON vs. that INI format, of course).

In order to save space the GUI writes compact JSON, but you can force it to write properly indented JSON by having the environment variable MTX_JSON_FORMAT set to »indented« before starting the GUI. That can be useful if you want to analyze the format. Or you could just run the content through any JSON pretty printer out there.

Note that the GUI can still read the old config file format. It will continue to support reading both formats for the foreseeable future as I currently don't have any plans for dropping support for that INI format. The GUI will not write that INI format anymore, though (only for the preferences, but those are small enough not to matter too much regarding the performance).

[Mosu]

Apart from the format changes there has been one addition: the key destinationAuto. It's set by the GUI to the automatically generated output file name (if that feature is activated) so that the GUI can determine whether or not the user has changed the output file name manually. If (s)he has then the GUI will not touch the output file name anymore.

[mastrboy]

Just wanted to thank you for another update.

Considering this is the only useable muxing/demuxing software for mkv and that you have been doing pretty much everything by yourself for years is quite impressive.

Github lists 49 contributors, so also a thanks to them :)

[Sparktank]

Just wanted to thank you for another update.

Github lists 49 contributors, so also a thanks to them :)

http://i.imgur.com/oqgqmYu.png

[rsotome]

So far, a great deal of nice improvements to the new GUI, especially storing each job in a separate file, thank you for all your hard work. :)

I do have 2 questions about the .mtxcfg format & jobQueue.

-Is it possible to generate better filenames in the jobQueue, instead of what seems like a mix of random letters & numbers?
-Will it ever be just as easy to mass edit .mtxcfg files as it is the older .mmg files with a text editor (eg. Notepad++) ?

The .mtxcfg is hard to make heads or tails out of, and mass editing 20+ TV series jobs is still much easier with the .mmg format.

Hopefully I didn't put a damper on your new release, since it's really starting to take shape. :)

[Mosu]

Hey,

So far, a great deal of nice improvements to the new GUI, especially storing each job in a separate file, thank you for all your hard work. :)

You (and the others who thanked me) are quite welcome :)

I do have 2 questions about the .mtxcfg format & jobQueue.

-Is it possible to generate better filenames in the jobQueue, instead of what seems like a mix of random letters & numbers?

Those are GUIDs (Globally Unique Identifiers) (https://en.wikipedia.org/wiki/Globally_unique_identifier). They're used by the GUI in order to ensure that each job file has a unique name. This also facilitates copying those job files to another installation without clashing with any existing job queue file on that installation, be it on the same computer or on other computers.

I don't have any plans on changing that schema as I don't see a compelling reason. If you want to manually add your own jobs to the queue without the GUI and you're worried about having to name the files in a similar way: don't be. The GUI should pick up all files in the jobQueue directory whose extension is ».mtxcfg« and assign a GUID automatically.

Knowing that do you still want the GUI to use different a file naming scheme? If so what are the reasons?

-Will it ever be just as easy to mass edit .mtxcfg files as it is the older .mmg files with a text editor (eg. Notepad++) ?

Like I've said above in a reply to hubblec4: the GUI uses JSON for writing .mtxcfg files now. If you want to edit those files manually make sure the environment variable »MTX_JSON_FORMAT« is set to »indented«. That way they'll even look nice.

I consider JSON to be a good choice. There are bindings for parsing and writing JSON available in pretty much each and every programming language. Modifying those files should be very, very easy.

The .mtxcfg is hard to make heads or tails out of, and mass editing 20+ TV series jobs is still much easier with the .mmg format.

You already know the .mmg format, you don't know the .mtxcfg format yet. Of course .mmg is easier for you under those circumstances. Why don't you just ask about the points in .mtxcfg that you don't understand? I'm happy to explain the meaning of those things, you know ;)

The internal format won't change, sorry, you should get used to it if you want to fiddle around with it.

hubblec4 generates his own .mtxcfgs, too. Here are a couple of points I've explained to him a while ago:

It's UTF-8 encoded JSON. The same JSON used everywhere else.
There's one important distinction between .mtxcfg saved from the merge tool and the .mtxcfg used in the jobQueue. The files in the jobQueue contain more information on the top level, and the merge configuration is nested one level down in the »muxConfig« key. Think of structures/classes in a programming language. There's a class called »MuxConfig« and one called »Job«. »Job« contains a member of type »MuxConfig«, and that's how they're stored in the jobQueue. Manually-saved .mtxcfg files from the merge tool, however, only contain the »MuxConfig« instance and aren't wrapped in an instance of »Job«.
objectId is just a numeric value uniquely identifying each object within the file. The GUI uses memory addresses, but you could just as well use serial numbers.
properties are the key/value pairs output by »mkvmerge --identify-for-mmg«. Note that mkvmerge escapes certain characters (https://www.bunkus.org/videotools/mkvtoolnix/doc/mkvmerge.html#mkvmerge.escaping), and that escaping has already been undone when the values are stored in the .mtxcfg.
The »type« member for a track is the numeric track type. See this list (https://github.com/mbunkus/mkvtoolnix/blob/master/src/mkvtoolnix-gui/merge/track.h#L23): audio equals 0, all following are numbered sequentially.
Tye »type« member for containers is the numeric container type. See this list (https://github.com/mbunkus/mkvtoolnix/blob/master/src/common/file_types.h#L31): unkown equals 0, all following are numbered sequentially.

[hubblec4]

-Will it ever be just as easy to mass edit .mtxcfg files as it is the older .mmg files with a text editor (eg. Notepad++) ?

The .mtxcfg is hard to make heads or tails out of, and mass editing 20+ TV series jobs is still much easier with the .mmg format.

I can feel with you, in the past i have do the same.
Create one mmg manually, and all other episodes by copy/paste(replace) the paths in the mmg.



@Mosu

puuhhh the new format JSON looks like not so well for me.
There is only one line in the mtxcfg.
But the old mtxcfg will supported in future? So I can use this?

[hubblec4]

The new JSON mtxcfg seems to be easier.
When path's contains "ä , ö , ü ..etc" the format will not changed like in the old mtxcfg (ä = \xe4). Now its very easy to change mass mtxcfg's with an editor.

I will change to JSON too.

[Mosu]

Like I said: set that environment variable and the GUI will write nicely formatted JSON. It can always read both the compact and the indented variants.

[AYColumbia]

Mosu, any estimate on when the command line stuff will be complete in the new UI? Also, I noticed the current Windows cmd.exe is escaping the double quotes, i.e., ^" but they don't need to be escaped, however, the parans do, i.e., ^( and ^). Thank you.

BTW, I copied the current command line and tried to run it manually and received an error. Obviously if CLI not ready you can ignore this. ;)
"mkvmerge.exe" "--output" "title.mkv" "--language" "0:und" ( "sourceTitle.mkv" ) "--language" "0:und"
( "sourceTitle.ac3" ) "--language" "0:und" ( "sourceTitle.sup" ) "--chapters" "sourceTitle_chapters.txt"
"--engage" "no_cue_duration" "--engage" "no_cue_relative_position" "--track-order" "0:0,1:0,2:0")
mkvmerge v8.3.0 ('Over the Horizon') 64bit
Error: '0)' is not a valid file ID in '--track-order 0:0,1:0,2:0)'.

[Mosu]

The command line handling is ready: Merge → Show command line. The quoting is intentional. It may look ugly, but it actually is the only proper way to escape for cmd.exe.

What you think you know about escaping for cmd.exe is most likely incorrect or at least incomplete. See this informative but frightening (http://blogs.msdn.com/b/twistylittlepassagesallalike/archive/2011/04/23/everyone-quotes-arguments-the-wrong-way.aspx) blog post from a Microsoft employee.

BTW: I'm sorry to say but cmd.exe stinks. Especially if one is used to sane shells like zsh or bash.

And what do you mean – you »copied the current command line«? You definitely copied one closing parenthesis too much, I have no idea where you got that one from.

[AYColumbia]

I copied the command line string from the UI from the same location you mention, i.e., Merge > Show command line. I didn't notice that it had an extra paran on the end so good catch.

Regarding the escaping, yes, I just realized that it's fine the way it is since it's meant to be copied and executed on the command line directly as opposed to be consumed by a script/batch file. I was looking at it from a command file script perspective which is not correct here.

I don't use zsh or bash. Just basic Windows CLI to batch process stuff. I'm sure you're passionate about not liking CLI but please don't be condescending towards those of us that still use it. Speaking for myself, the reason I still use it, is the lack of a UI to accomplish what I need for each situation whether it's re-encoding, re-muxing or what have you.

[Mosu]

Not liking the CLI? Geez, you misunderstood me completely :) I love the command line! But cmd.exe is simply not a good shell. zsh and bash are: way more powerful, much saner… That's all I wanted to say.

What you've pasted above doesn't look like the new GUI's version of a command line escaped for cli.exe but for Linux shells. You should not use that escaping with cmd.exe, instead switch to the cmd.exe escaping mechanism. And if you're still using mmg.exe for generating command lines: please use the new GUI instead. mmg.exe's command lines are not correct for cmd.exe in certain situations (e.g. if quotation marks are involved).

[sneaker_ger]

This is intended?
http://abload.de/img/mkvtoolnixgui_830_cnd45r31.png

[Mosu]

Like I've said above (http://forum.doom9.org/showthread.php?p=1734612#post1734612): yes.

[sneaker_ger]

Quoting the path to mkvmerge.exe in this manner does not work here. It stops at the first space in the path. (c:/program not found)

[Mosu]

That's interesting. I'll have to look into it.

[Boulder]

Probably because there's a slash instead of a backslash (Windows paths..)

[Mosu]

Like I said: cmd.exe and command line parsing on Windows is completely bonkers.

Looks like cmd.exe uses different rules for escaping the initial argument than the MS Visual C libraries use for all remaining arguments. The joy!

I'll have to fix that and will open an issue for it in the meantime. Note that only the escaping of the very first argument (the path to mkvmerge.exe) has to be changed – the other arguments are escaped correctly.

[Mosu]

No, backslashes vs. slashes is not what's wrong here. cmd.exe doesn't interpret ^" the way that CommandLineToArgvW() does. If you just use "C:/Program Files/MKVToolNix/mkvmerge.exe" and leave the rest as it is then it does work. Windows does support forward slashes just fine.

[Boulder]

Windows does support forward slashes just fine.Whoa..you definitely learn something new each day. That one just removed one almost 30-year-old piece of knowledge off my head :)

[Mosu]

The cmd.exe escaping snafu has been fixed in pre-builds 867/868 (https://www.bunkus.org/videotools/mkvtoolnix/windows/pre/).

[AYColumbia]

Not liking the CLI? Geez, you misunderstood me completely :) I love the command line! But cmd.exe is simply not a good shell. zsh and bash are: way more powerful, much saner… That's all I wanted to say.

All good. :) Sorry for the misunderstanding on my part. It just came across as harsh rather than sarcastic is all.

What you've pasted above doesn't look like the new GUI's version of a command line escaped for cli.exe but for Linux shells. You should not use that escaping with cmd.exe, instead switch to the cmd.exe escaping mechanism. And if you're still using mmg.exe for generating command lines: please use the new GUI instead. mmg.exe's command lines are not correct for cmd.exe in certain situations (e.g. if quotation marks are involved).
You're correct. I had to remove the ^" because am running in a Windows cmd.exe (already addressed by earlier posts by others so won't delve further). I saw you had a fix build already in the latest post. Many thanks for jumping on this so quickly. Very much appreciated. :)

BTW, I have switched over to the new GUI which is how I ran into the escaping thingy. ;) It's taking some getting used to but I like it.

[ShadyCrab]

Whenever I select a video file in the new GUI (8.3.0 and current nightly 64 bit, both through the Installer) an error pops up saying 'the mkvmerge executable was not found'. I went to task manager, opened the file location and its definitely launching from the same folder as mkvmerge.exe. I deleted the bunkus.org AppData folder, didn't help. Portable edition works, but installer will not. Tried reinstalling 4 times, even deleting old regedit data (though the new one doesn't use it, just to be sure).

[Mosu]

@ShadyCrab: I cannot reproduce such issues, and I haven't received similar reports either. Therefore I guess it's something on your end. Maybe incorrect folder/file permissions after the installation? Both the installed and the portable version use the very same code for finding and executing mkvmerge.exe. They only differ on where they store their settings.

[noee]

Mosu:
First, thanks for the great tool - indispensable, it is.

Build question: I've got a openSUSE TW box that use for dev work (latest QT5, KF5, Plasma5, etc.) and I have to change to -fPIC in the "makefile" after config or it complains at the kax_qt step. Is this expected? I'm building x86_64.

[Mosu]

You mean you have to change -fPIE to -fPIC? Or what do you have to change, exactly?

If so I'm somewhat surprised. I don't build on Tumbleweed myself, but I do build on 13.1 and 13.2, and neither requires such changes. Additionally I also compile with the latest Qt 5 (MKVToolNix has nothing to do with KDE so those libraries don't count) and the latest gcc (5.1.0) on Arch Linux, and I don't need any such changes for those either.

So no, this isn't expected.

[noee]

Yeah, exactly, I changed -fPIE to -fPIC. It might be the way the KDE team at openSUSE builds QT, IDK. Either way, it works and the mkvtoolnix tools seem to work as expected. TW has a later version of boost, so the repos using the OBS only have mkvtoolnix up to 7.9. Also, TW is up to gcc 5.1.1, fwiw.

[Mosu]

Huh, interesting. I don't have any preference regarding using -fPIE instead of -fPIC. I only do because created a pull request (https://github.com/mbunkus/mkvtoolnix/pull/1361) for it and judging from the compiler's documentation it sounded sensible. I think I'll revert it as it obviously causes problems.

[bartonnen]

(version 8.3.0)
I added a bunch of jobs to the queue today, switched to the job queue tab and pressed Ctrl-R to start the queue. The jobs started one by one as expected and they all completed successfully - but I noticed that the right-hand "total progress" bar kept resetting to 0% as each job completed, instead of just continuing to increase.

[Mosu]

Thanks for the report. Hmm, I cannot reproduce such behavior. For me the left of the two progress bar resets to 0% as soon as a job starts, the right one never resets as long as the queue is running. I've tried this with five jobs.

If you can give me a list of all the exact steps you've taken and if you can reproduce the issue then I'll look into this some more.

[bartonnen]

I did have two failed jobs from a previous day still at the top of the list, perhaps they affected it.

[bartonnen]

OK - I figured out the issue - it's because I have "Remove job from queue after completion" checked, it must be getting removed from the calculation as well.

[Mosu]

(oops, I misread your comment)

Yes, removing jobs affects the total, and therefore the total will always reset to 0 as the completed jobs are taken out of play almost immediately.

This is somewhat surprising for users, I guess… I'll have to look into how to fix this properly.