mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Bug]: Incorrect authors created from match results due to comma-separation #1764
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/audiobookshelf#1764
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Originally created by @mikiher on GitHub (Feb 25, 2024).
Describe the issue
Currently, when book match results are created, several authors are joined into a single author field with commas (e.g. "John Doe, Jane Doe"). Then when a match is selected (or when using quick match), the author field is again split into several authors, using comma separation.
Te current logic is problematic, since in many cases a single author name can include a comma (e.g. "John Doe, Ph.D."), and it is then split incorrectly into a number of authors (e.g. "Joen Doe" and "Ph.D"). A side-effect of this bahviour also caused #2650.
Proposed Solution:
Most match providers already return separate authors (I believe itunes is the only one returning a single author)
Instead of joining them into a single author field and then splitting it again, we should change the match results structure to contain an array of authors.
Steps to reproduce the issue
Expected: Book has single author "John Doe, Ph.D."
Actual: Book has two authors, "John Doe", and "Ph.D."
Audiobookshelf version
v2.8.0
How are you running audiobookshelf?
Built from source
@advplyr commented on GitHub (Dec 21, 2024):
I can't remember if this was fixed yet but I remember some work being done there at some point. I don't know of a book to test this with.
@mikiher commented on GitHub (Dec 21, 2024):
This is not resolved.
For example, try matching Feeling Good by David Burns on Google Books.
@damajor commented on GitHub (Feb 5, 2025):
This is really a pain and getting urgent to fix I think.
Audiobooks with multiples authors (same logic applies also to narrators) gets completly screwed when the list contains a single name author, even perfectly tagged audiobooks.
@advplyr You don't need specific audiobook to reproduce, just setup an author/narrator metadata with a list like this one
"Fname1 Lname1, Fname2 Lname2, SingleName, Fname3 Lname3"No matters where the single name author is, the fuzzy detection logic of ABS will screw up things.
I even tried with different authors separators and it does not help. I falsely assumed that some separators (
';','&') would help because I don't remember any author names with';'or'&'in them, but not.It happens when using metadata from audiobook files AND also when using PATH to discover authors.
Possible solutions:
The fuzzy discovering logic is great BUT it should never be mandatory.
This issue is very similar to this one #1675
@advplyr commented on GitHub (Feb 5, 2025):
@damajor
I just tested this with the author names you mention in the folder structure and it pulled in correctly.
To run this test I updated the scanner precedence moving folder structure to the top to ensure that the authors would be pulled from the folder name.
I'm aware of author names like this
John Doe, Ph.Dbeing an issue but I'm not sure how to reproduce the single name author issue you are referring to.Can you verify what version of Abs you are running and give more exact reproducible steps?
@damajor commented on GitHub (Feb 5, 2025):
I just made a new test container (latest ABS) with the following audiobook tree:
I used this library settings:
Folder authors string is exactly the same inside the audiobook file.
And the results:
Well honestly I did not test with a single name author/narrator in middle of the list, but it seems that does not work if there is one in the first place of the author list. Maybe a side/edge effect ?
@mikiher commented on GitHub (Feb 5, 2025):
In any case, the thing you're describing is not the same as the issue I described when I opened this bug. My issue specifically has to with matching (i.e. getting metadata from a match provider like Audible), not with metadata obtained through scanning. You should probably open a separate issue.
@damajor commented on GitHub (Feb 5, 2025):
@mikiher & @advplyr I created this one (#3940) to track my issue.