This project isn't finished yet. Goal is to create a SickBeard, CouchPotato, Headphones-like application for ebooks. Headphones is used as a base, so there are still a lot of references to it.
729
stars
72
forks
source link
Use of fixed priority for interpretation of metadata tags in audiobooks leads to no match if narrator is Composer #1675
To help with identifying and fixing issues, please include as much information as possible, including:
Version: 52be663d
OS: TrueNAS SCALE 22.02.2.1
Interface: default
API: Goodreads
Source of installation: TrueCharts helm chart version lazylibrarian latest_11.0.24
Honestly though, this isn't about versions or debug logs... I can point you to the logic in the code.
The problem is with library scanning for audiobooks. There's a presumption in the code about how best to find the author in the metadata tags as delivered by tinytag (from lazylibrarian/bookrename.py, lines 70-77):
if composer: # if present, should be author
author = composer
elif performer: # author, or narrator if composer == author
author = performer
elif albumartist:
author = albumartist
else:
author = None
The difficulty is that if the metadata, as is the common practice for many sources, populates the tags so that the composer tag contains something other than the author, the audiobook will fail to match and not be imported.
Example: Here is a mocked up tinytag output for an example audiobook.
Artist : Some Author
Album : Example Audiobook
AlbumArtist : Some Author
Composer : Talented Narrator
Comment : This book is an awesome example, written by Some Author and read for you by Talented Narrator.
Title : Example Audiobook
Track : 1
EndTrack : 0
Duration : 12345.000
So the narrator is inferred from the tags to be the author, and as such the incorrect author is identified and the book fails to match.
Now, I think you can make a strong case for why the author should be the in the composer tag and the narrator in the artist tag, but the reality of the situation is that none of the tags were really designed for audiobooks, but for music, and as such are often populated in a non-standard way.
I'd propose either of two possible fixes:
Simply make the preferred order configurable so that users could specify which tag they'd like to see given priority. Then you can simply loop through those tags in the order specified. This would let users override the current behavior while still allowing users to keep the current behavior for compatibility.
Add some intelligence to the matching by attempting matches against each tag until a match is found rather than starting with the first populated tag and giving up if it doesn't match.
Personally I'd go with option 2, but it would be a bit more complicated to write and would mean that the number of calls to match would go up for audiobooks that had the author in one of the tags farther down the line of preferences. Better still would be to do both, making the order configurable, but trying each until a successful match was made.
To help with identifying and fixing issues, please include as much information as possible, including:
Version: 52be663d OS: TrueNAS SCALE 22.02.2.1 Interface: default API: Goodreads Source of installation: TrueCharts helm chart version lazylibrarian latest_11.0.24
Honestly though, this isn't about versions or debug logs... I can point you to the logic in the code.
The problem is with library scanning for audiobooks. There's a presumption in the code about how best to find the author in the metadata tags as delivered by tinytag (from lazylibrarian/bookrename.py, lines 70-77):
The difficulty is that if the metadata, as is the common practice for many sources, populates the tags so that the composer tag contains something other than the author, the audiobook will fail to match and not be imported.
Example: Here is a mocked up tinytag output for an example audiobook.
pwd
/app/lazylibrarian/lib
python3 -m tinytag /audiobooks/'Example Audiobook.m4b'
Artist : Some Author Album : Example Audiobook AlbumArtist : Some Author Composer : Talented Narrator Comment : This book is an awesome example, written by Some Author and read for you by Talented Narrator. Title : Example Audiobook Track : 1 EndTrack : 0 Duration : 12345.000
So the narrator is inferred from the tags to be the author, and as such the incorrect author is identified and the book fails to match.
Now, I think you can make a strong case for why the author should be the in the composer tag and the narrator in the artist tag, but the reality of the situation is that none of the tags were really designed for audiobooks, but for music, and as such are often populated in a non-standard way.
I'd propose either of two possible fixes:
Simply make the preferred order configurable so that users could specify which tag they'd like to see given priority. Then you can simply loop through those tags in the order specified. This would let users override the current behavior while still allowing users to keep the current behavior for compatibility.
Add some intelligence to the matching by attempting matches against each tag until a match is found rather than starting with the first populated tag and giving up if it doesn't match.
Personally I'd go with option 2, but it would be a bit more complicated to write and would mean that the number of calls to match would go up for audiobooks that had the author in one of the tags farther down the line of preferences. Better still would be to do both, making the order configurable, but trying each until a successful match was made.