Having images or text files in an intermediate directory for batch processing can lead to unexpected results

[StefanLobbenmeier]

Just spent some time debugging why the readme did not work for me, wanted to share what was wrong with my setup so it does not happen to others.

My folder structure was about like this:
input/Fantasy/J.K. Rowling/Harry Potter/5/Harry Potter and the Order of the Phoenix/Chapter 33 - Fight and Flight.mp3

The issue was, I also had some general thumbnails in input/Fantasy/J.K. Rowling/Harry Potter

The code here looks for text and image files and stops looking for deeper folders once it found them:

m4b-tool/src/library/Command/MergeCommand.php

Lines 257 to 260 in 02142f6

	$currentBatchDirs = $dirLoader->load($input->getArgument(static::ARGUMENT_INPUT), $this->parseIncludeExtensions(array_merge(
	static::DEFAULT_SUPPORTED_IMAGE_EXTENSIONS,
	static::DEFAULT_SUPPORTED_DATA_EXTENSIONS
	)), $this->alreadyProcessedBatchDirs);

That meant that the matching like this --batch-pattern="input/%g/%a/%s/%p/%n/ no longer worked, because it is unable to match %p/%n/

Does not necessarily need a fix, but maybe we can add this to the README that when creating the folder structure the directory tree should but completely free of files to avoid this from happening. As a workaround I renamed my .png and .txt files to .png.hide and .txt.hide and that also works 😄

[sandreas]

Yeah sometimes m4b-tool tries to hard to be convenient :-) Probably my fault because I follow an absolutely strict file structure for my personal library.

Maybe you could try the command with

--batch-pattern-path="input/"

that might fix the problem, but this is only available in the latest pre-release.

The documentation update is something I defintely consider, regardless --batch-pattern-path works or not.

Thanks for reporting.