[Bug]: ID3 series tag incorrectly parsed when multiple series are used

[flobernd]

What happened?

When importing/scanning an audiobook that defines multiple series in the ID3 series tag, only one series is used.

Example:

SERIES = "series A #1, series B #2"

The book ends up with a series series A #1, series B #2 without a sequence assigned to it.

What did you expect to happen?

The book should get detected with 2 series:

• series A (sequence number 1)
• series B (sequence number 2)

Steps to reproduce the issue

1. Use the UI to assign 2 series with (different) sequence numbers to a book
2. Embedd metadata using the UI
3. (Inspect .mp3 file to check the presence of the series tag)
4. Delete book from library, but do not delete the files
5. Re-scan library to discover the book again
6. Inspect the book properties and find the incorrect series meta-data

Audiobookshelf version

v2.13.4

How are you running audiobookshelf?

Docker

What OS is your Audiobookshelf server hosted from?

Linux

If the issue is being seen in the UI, what browsers are you seeing the problem on?

None

Logs

No response

Additional Notes

The series tag should correctly round-trip:

1. Split multiple series based on ,
2. Split series name and sequence-number based on #

The metadata-embedding task should probably as well check, if a series name contains either the , or the # character and escape them. Surrounding the whole string with " should probably be a good option as it's pretty unlikely that a legit series name starts with the " character.

An example series tag value could look like this:

"Series # One" #42, Series Two #1337

Looking at the code, it seems like the series-part tag is used besides series. This behavior could be preserved as long as:

1. There is only one series encoded in the series tag
2. There is no sequence number encoded in the series tag

If this proposal looks good to you @advplyr, I'm as well happy to submit a PR.

[advplyr]

I think we'll want to set up a lot of test cases for this because there are a lot of series with commas. Splitting on commas was an issue before switching to metadata.json files.
#2167

I think it'll be okay to implement this if we cover enough test cases