The caller of the function `generateUniqueOutputFileName` knows
whether or not the base name given to the function is the base name of
the first added file or the current content of the destination file
name control. Only in the latter case is the suffix added for
uniqueness present and has to be removed.
The prior selection was pretty Western-centric with a couple of
additions from Asia. However, there are so many more languages, and
for a lot of them there are many more native speakers than for those
which were on the list before this change.
The new list simply mirrors Wikipedia's "List of languages by number
of native speakers" found at
https://en.wikipedia.org/wiki/List_of_languages_by_number_of_native_speakers
Additionally the GUI will only show the often used languages in
drop-down boxes by default.
Both can still be changed in the preferences.
Problematic were files for which DOS-style EOLs were
detected (carriage return followed by newline, \r\n) but which had
some lines terminated solely by a newline (\n). In such a case the
EOL was only detected upon seeing the next \r\n, and the value
returned from the `getline()` function would return something that
everyone would judge to be multiple lines of text.
Fixes#2594.
In this particular case the `clip_codec_information` field contained
the value `FMTS`. The file in the `STREAM` sub-directory still has the
extension `.m2ts`, though.
Fixes#2601.
Due to argument-dependent lookup rules the `boost::algorithm::split`
function has always been considered by the compiler when resolving an
unqualified call to `split`.
Before Boost 1.71.0 the `boost::algorithm::split` function took an
lvalue reference as its `Input` argument. Therefore a temporary
instance of `std::string` would cause `boost::algorithm::split` not to
be considered due to SFINAE, and the compiler would keep looking,
finally finding the top-level `split` function.
In Boost 1.71.0 the first argument was changed to an rvalue
reference. Therefore the temporary `std::string` instance is now a
valid argument to the function, and the compiler considers
`boost::algorithm::split` to be a possible call. Other functions
aren't looked up.
The fix is easy: just be explicit which namespace to take the symbol
from. That way argument-dependent lookup will not be done.
Fixes#2599.
This is a destructive action; no user confirmation is requested. The
action only works for multiplexer jobs, not for info jobs.
The action is disabled by default. It has to be enabled to be usable
at all, and if it should always be executed, one of the two options
"After a job completes successfully or with warnings" or "After a job
exits with an error or the user aborts the job" must be enabled, too.
Implements #869 and #2570.
With very large video frames (one test file has h.264 from Blu-rays
with ten seconds between key frames and an average frame size of ~350
KB) buffering due to external timestamps being applied could easily
lead to the packetizer holding more than 128 MB of data in memory
while waiting for the next key frame before it can apply the
timestamps. The reader must not refuse to deliver frames in such a
case, otherwise the next I frame will never appear, the packetizer
will never write out those buffered frames and the whole process ends
up in an endless loop.
Fixes#2550.
This mostly affects UNC paths (e.g. `\\server\Videos\…`) which would
be turned into forward slashes (`//server/Videos/…`) which mkvmerge
doesn't support.
Fixes#2533.
Before the GUI tried to make the destination file name valid after
each change. This worked badly with the user trying to change the
drive letter by adding the new one and removing the old one in two
steps.
Now the GUI will simply ignore an invalid destination file name for
the time being. The file name will still be verified when the job is
started or added to the queue.
Fixes#2527.
Removing all suffixes of the form "a space character followed by (
followed by a number followed by )" would also remove things such as
years (e.g. "Amélie (2001)" was truncated to "Amélie" before trying to
make the file name unique).
Now the GUI remembers which suffix it hat to add the last time it
tried to make the name unique, and only that suffix will be removed on
the next attempt.
Fixes#2521.
On Windows symbolic links are used when mounting a drive as a
sub-folder somewhere. Unfortunately Boost::Filesystem's `canonical`
function tries to read those symlinks and throws an exception that the
operation isn't supported.
Fixes#2522.
mkvmerge tries to find the Blu-ray base directory when handling
certain files that can occur on a Blu-ray such as M2TS or MPLS play
list files. It tries to find additional files with as the streams
referenced in the play lists or clip information files from the CLPI
sub-directory.
That function simply crawls the path upwards to the root of the file
system. This works nicely with Unix paths (`/path/to/file.m2ts`) or
normal Windows paths (`C:\path\to\file.m2ts`). Things go wrong on
Windows with UNC paths, though (`\\servername\sharename\path\to\file.m2ts`).
mkvmerge looks for `\\servername\sharename\path\to\index.bdmv` and
then iterates back towards the server name. As soon as the path to
check removes the share name, the check for the resulting
`\\servername\index.bdmv` will throw a
`boost::filesystem::filesystem_error` with the message that the server
in question doesn't offer a share named `index.bdmv`. That exception
must not bubble; instead the algorithm must simply stop at that point
and return unsuccessfully.
Fixes#2507.
The "portable or installed" detection looks for a file called
`portable-app` located in the `data` sub-directory of the directory
the GUI's executable file is located in. For this to work the path to
the executable file must be determined.
Before the fix this was done in the constructor of the `App` class,
which is rather early, but not early enough as the earliest code
trying to access the settings file (and therefore the earliest code
requiring knowledge of the executable's path) is actually run directly
from `main` long before `App` is instantiated.
When that code is run before the executable's path is determined, the
path to the executable is left empty. Therefore the GUI looks in the
current working directory for the `data\portable-app` file. This works
if the current working directory is the same the executable is located
in, e.g. you open Windows Explorer, navigate to the GUI's installation
folder and double-click the executable. In that case determining if
the application is portable or installed works just fine.
However, the working directory might be set to something completely
different. For example, the "open with" functionality sets the working
directory to the directory the file that the user calls "open with" on
is located in. The GUI then looks for `data\portable-app` in the same
directory the clicked-on file resides in and will not find
it. Consequently the GUI thinks it's been installed and looks for the
settings file in the user's `AppData\local\bunkus.org\mkvtoolnix-gui`
directory.
The fix is to initialize the MKVToolNix common library and with it the
current executable's location first thing from `main`, before the
GUI looks for the settings file for the first time.
Fixes#2501.
