On Device matching fails with custom send-to-device save templates

[clemon79]

Plugin version: 0.2.7
Device: XTEINK X3 / CrossInk
Calibre: reproduced on Windows and macOS

When using a custom send-to-device template, books successfully transferred by the plugin may not be recognized as On Device by another Calibre installation, or after the plugin's local metadata cache is unavailable.

For example, I use:

{author_sort}/{series} - {series_index} - {title}

which produces paths such as:

/Dinniman, Matt/DCC - 7 - This Inevitable Ruin.epub
/Dinniman, Matt/- - Operation Bounce House.epub

The files are present on the device and the plugin successfully retrieves them. Books transferred from the current Calibre installation are also correctly shown as On Device, because their identity has been stored in the plugin's local metadata cache.

However, when no valid cache entry exists, _match_from_library() in driver.py attempts to identify the book from the filename:

stem = os.path.splitext(os.path.basename(lpath))[0]
candidates = list(index.get(self._norm_title(stem), ()))
if not candidates and ' - ' in stem:
    candidates = list(index.get(self._norm_title(stem.rsplit(' - ', 1)[0]), ()))

For DCC - 7 - This Inevitable Ruin.epub, this searches for the titles:

DCC - 7 - This Inevitable Ruin
DCC - 7

but never searches for:

This Inevitable Ruin

Likewise, - - Operation Bounce House.epub never produces Operation Bounce House as a candidate.

As a result, the fallback matcher appears to assume a filename layout in which the title is the complete stem or occurs to the left of the final - delimiter. This is incompatible with other templates supported by the plugin, including templates that place {title} at the end.

I reproduced this using two Calibre installations pointed at the same library. Books sent by installation A are immediately and persistently recognized there because A has cached their identities. Installation B successfully retrieves the same device inventory but does not recognize those books as On Device when it lacks A's cache. Reversing the test produces the same result.

Enabling Fetch metadata for side-loaded books can recover the identity by downloading and inspecting each EPUB, but that seems unnecessary for files generated by the plugin and masks the filename-matching problem.

A possible fix would be to use the configured send template to construct/recognize the expected device path when possible, with more flexible filename matching as a fallback. At minimum, the fallback parser could consider the portion to the right of the final delimiter as a potential title as well as the portion to the left.

Successful fallback matches can then continue to be stored in the existing metadata cache as they are now.