Fixing 'Narrators' and 'Series' update on re-scan

[warnwar]

Brief summary

When re-scanning an existing audiobook, I noticed that the 'Narrators' and 'Series' fields will not update if you change the audio tags from empty to something else

Which issue is fixed?

I did not create an issue for this, instead I figured I would fix it myself

In-depth Description

Steps to repro:

• Add an audiobook to your library. Leave the 'composer' and 'grouping' audio tags empty.
• Check that audiobookshelf did not somehow pick up data for 'Narrators' and 'Series' fields
• Outside of audiobookshelf, fill in the empty tags
• Inside audiobookshelf, click the 'Re-Scan' button
• See that the two fields are not updated

How have you tested this?

I followed my repro steps listed above, debugging through the code. I found the problem was the AbsMetadataFileScanner.js was overwriting the new 'Narrator' and 'Series' information with empty data.

Screenshots

[advplyr]

This is an issue we have to decide how to handle.

Consider the scenario where you have some incorrect data in the compose field, so after the scan you manually remove the narrator in Abs.

If the Audiobookshelf metadata file is set to the highest priority then it is fair to assume that future scans would keep the narrators empty instead of continue to fill it with the bad data in the compose field.

I never figured out how best to handle this.
Oddly enough this scenario in the opposite direction just came up: #3649 (comment)

In that case they don't want the bad tags from the OPF source.

Right now the code is inconsistent so it should be adjusted to be consistent. But what is the best way?

[warnwar]

@advplyr I think rewriting the code to better handle metadata preference is a little beyond my abilities. Would it make sense to merge this (for consistency) and deal with that at a later time?

[advplyr]

I'm not suggesting that you write the code. It is a question of how best to handle the problem I outlined. We try to implement solutions that best serve the userbase as a whole instead of pushing changes for specific use-cases.

I think we go the other direction because it is more intuitive to have the metadata file take precedence, even for empty values. We can also consider adding an additional scan option (maybe only for a "Re-Scan" in the modal to start) to ignore the metadata file for that scan. Alternatively, we add an additional library setting in the metadata precedence tab that specifies how to handle empty values.

Since you want the audio file metadata to take precedence over the metadata file you can adjust the order of precedence in library settings.

[CLHatch]

This is an issue we have to decide how to handle.

Consider the scenario where you have some incorrect data in the compose field, so after the scan you manually remove the narrator in Abs.

If the Audiobookshelf metadata file is set to the highest priority then it is fair to assume that future scans would keep the narrators empty instead of continue to fill it with the bad data in the compose field.

I never figured out how best to handle this. Oddly enough this scenario in the opposite direction just came up: #3649 (comment)

In that case they don't want the bad tags from the OPF source.

Right now the code is inconsistent so it should be adjusted to be consistent. But what is the best way?

It seems to me that the order of precedence a user would want would depend on the source of the file ("source" being ripped from Audible, made themselves from a CD and metadata embedded by them, some download site where they like the metadata embedded, another site where they don't like the metadata embedded...).

Given that, wouldn't it make sense to have separate precedence settings that apply to a folder rather than one for the entire library? For example, I have a library where I add a folder for my Audible books, another folder for my wife's Audible books, and a few other folders listed as "Other". I'll generally trust the metadata added by Libation for my Audible books, but may not for the "Other" ones. I want them all in the same library, but I don't want them all to have the same metadata preference settings.

[advplyr]

I'm not sure how many people have that use-case (I don't personally) but changing the metadata precedence to be folder specific isn't a solution to the issues I mentioned. If the metadata precedence did become folder specific the issues mentioned would still need to be addressed

[CLHatch]

I'm not sure how many people have that use-case (I don't personally) but changing the metadata precedence to be folder specific isn't a solution to the issues I mentioned. If the metadata precedence did become folder specific the issues mentioned would still need to be addressed

Ah, true, I suppose it wouldn't fix this.