[Bug]: matroska/webm chapter UIDs break assumptions

[itzexor]

Describe the issue

mkvmerge and possibly other tools generate mkv/webm files with randomly generated numbers as the chapter ID(called UID by matroska/webm), using it as a unique id rather than a chapter index. ffprobe, and possibly other tools, return this as the id parameter making it indistinguishable from actual valid chapter indexes without sanity checking.

note: ffmpeg generates these UIDs sequentially starting at 0 and thus they sometimes will be the expected "chapter id" style, matching the list of chapters.

effects:

• incorrect chapter ID display in web client/library metadata
• mobile client fails to load when this book is in the initial load payload, recently added for instance

Steps to reproduce the issue

1. generate a [webm compliant] source audio file to test with. i used audacity brown noise generator, 3 minutes, and exported as ogg opus
2. generate chapters.txt file with chapter definitions (or import from existing files metadata, or generate them using mkvmerge directly)
3. generate muxed webm: $ mkvmerge -o test.webm -w --chapters chapters.txt 3_min_brown.opus
4. dump metadata: $ ffprobe -hide_banner -loglevel fatal -show_error -show_format -show_streams -show_programs -show_chapters -show_private_data -print_format json test.webm
5. observe chapter UIDs
6. add as audiobook to ABS, and notice chapter indexes are the UIDs
7. attempt to load mobile client and it should fail at this point

ffprobe dump and chapters.txt contents here: https://gist.github.com/itzexor/a1ca8db49fbd5dab8d0afec46ca02c14
the only thing you'll need to provide to repro is some 121+ second(so that we have valid chapters) file to mux in.

Audiobookshelf version

v2.2.12

How are you running audiobookshelf?

Docker

[advplyr]

I missed this issue. I tagged the commit that fixes this with #1783, which is the same problem.

Basically I set it up to just ignore the ID that comes in from ffprobe since it is not useful in any way.

[advplyr]

Duplicate of #1783