rmcrackan/Libation

Series number padding ignored in file template (<series#[00.##]>)

Closed this issue · 5 comments

H2OKing89 commented

Describe the bug
The file-naming template formatter for the series number is ignoring the zero-padding mask.
Using <series#[00.##]> produces an unpadded integer (e.g., 6) instead of the expected 06.

Context: In Edit File Template I’m using:
<audible title> <if series-> vol_<series#[00.##]> <-if series> [<year>] [<first author>] [ASIN.<id>]]
The live preview shows vol_6 even though the docs’ Number Formatters table says <series#[00.##]> should yield 01 style padding.

To Reproduce

  1. Open Settings → Edit File Template.
  2. Set the template to:
    <audible title> <if series-> vol_<series#[00.##]> <-if series> [<year>] [<first author>] [ASIN.<id>]]
  3. Save any audiobook that is part of a series with a single-digit volume (example: “Baccano Vol. 6”).
  4. Observe the preview/created filename.

Expected behavior
<series#[00.##]> should honor the zero-padding mask and output 06 (so the filename includes vol_06). The formatter appears to ignore the mask and just outputs 6.

Screenshots

  • Edit File Template showing the formatter and the preview rendering vol_6.
    Edit File Template preview shows vol_6

  • Documentation table showing <series#[00.##]> example and expected result.
    Number Formatters doc

Platform
Windows 11 Pro (23H2), 64-bit.

Log Files
No crash. I reproduced the issue and attached the latest Libation.log from %USERPROFILE%\Libation\ after saving a single-digit series volume. The log shows normal operations; no errors are emitted when rendering the template.

Additional context

  • The same template correctly inserts the year, author, and ASIN; only the series# padding mask seems to be ignored.
  • Based on the docs, composite masks like [00.##] should be supported; here they appear to be treated like a plain integer without formatting.
  • Example preview from the UI:
    ... \Baccano Vol. 6 - vol_6 [2025] [Ryohgo Narita] [ASIN.B0F5CYVLWD].m4b
    Expected:
    ... \Baccano Vol. 6 - vol_06 [2025] [Ryohgo Narita] [ASIN.B0F5CYVLWD].m4b
Mbucari commented

@H2OKing89 We recently changed the series number from being an integer type to a string type, due to some book collections having series numbers "1-5", for example. I'm not sure if we want to update the documentation to reflect that face, or if we want to try to do a better job parsing series numbers.

H2OKing89 commented

What if the padding logic still applied even when the series number is a string?

  • For example, "1-5" could become "01-05" when the template uses <series#[00.##]>.
Mbucari commented

@H2OKing89 Yes there's certainly are options, and I'm open to exploring them, but it's not going to be as simple as that. There's no known finite set of series number formats. The dash separating two numbers is one alternate format, but there are others. Since we're not privy to Audible's internal numbering scheme (assuming they even have one that is 100% consistent), the best we can do is try to be a bit smarter identifying numbers, and if all else fails revert to using the string (which is the current behavior).

rmcrackan commented

we're not privy to Audible's internal numbering scheme

Even if the internal numbering scheme were 100% consistent (...and it's not), there are times when it's not possible to know. When a series has 9 books, what should the final number be? Presumably 9. What about when another book comes out next year? Now it's 09 so that we can accommodate 10 through 99. Are there any series with over 99 entries? I can't think of any but our software can't discount it.