rmcrackan
Download raw metadata on demand (without redownloading books)
Is your feature request related to a problem? Please describe.
I absolutely adore the ability to store raw metadata from the Audible API in .metadata.json files, as introduced in https://github.com/rmcrackan/Libation/pull/679, so thank you so much for that. However, unless I'm mistaken, there is currently no way to have Libation create those files if the audiobooks were previously downloaded without it (i.e. with the JSON option disabled in settings). With a large, four-digit library of books, redownloading everything to get the JSON files is not ideal.
Describe the solution you'd like Two suggestions:
- CLI (which I use more): similar to the existing
-p/--pdfflag to only download PDFs, maybe a-j/--jsonor-m/--metadataflag to only download JSON metadata files. - GUI: add a "Download JSON Metadata" or similar item to the context menu for a single or multi-book selection.
Note that:
- I personally edit these JSON files quite a bit to correct/massage Audible metadata (e.g. to merge books in a single logical series that were purchased in different marketplaces), so I wouldn't want any solutions to overwrite existing data. But if people do want to update the metadata from the API after it's already been fetched, maybe that could be opt-in or a separate feature.
- I know neither of these are guaranteed to put the
.metadata.jsonfiles right next to the original audiobooks, if the user has moved/renamed the books in the meantime. That seems like a minor concern given that:- the PDFs feature presumably already exhibits this caveat (I don't know for sure as I don't use it); and
- the type of user who has a strong need for these files can probably work around it, somehow (e.g. I keep the ASIN in the filenames so I can always match stuff up later).
Describe alternatives you've considered Similar data can be obtained by enabling debug logging and then rescanning all accounts. But:
- It doesn't include chapter info, because only the content request endpoints return that. I use the chapter info quite heavily, so that would be a bit of a dealbreaker for me.
- It would still need to be manually dumped to
.metadata.jsonfiles via some means, if the aim was to have it next to the audio files.
Additional context Sorry if this is a bit long/rambly, and thank you for all your work!
I also would love this, I have a huge library and started using the metadata as soon as it was implemented. But I've got a TON of books without metadata and no idea how I can make my older books as nice as my new ones.
On Mon, Sep 2, 2024 at 8:49 PM James Scholes @.***> wrote:
Is your feature request related to a problem? Please describe. I absolutely adore the ability to store raw metadata from the Audible API in .metadata.json files, as introduced in #679 https://github.com/rmcrackan/Libation/pull/679, so thank you so much for that. However, unless I'm mistaken, there is currently no way to have Libation create those files if the audiobooks were previously downloaded without it (i.e. with the JSON option disabled in settings). With a large, four-digit library of books, redownloading everything to get the JSON files is not ideal.
Describe the solution you'd like Two suggestions:
- CLI (which I use more): similar to the existing -p/--pdf flag to only download PDFs, maybe a -j/--json or -m/--metadata flag to only download JSON metadata files.
- GUI: add a "Download JSON Metadata" or similar item to the context menu for a single or multi-book selection.
Note that:
- I personally edit these JSON files quite heavily to correct/massage Audible metadata (e.g. to merge books in a single logical series that were purchased in different marketplaces), so I wouldn't want any solutions to overwrite existing data. But if people do want to update the metadata from the API after it's already been fetched, maybe that could be opt-in or a separate feature.
- I know neither of these are guaranteed to put the .metadata.json files right next to the original audiobooks, if the user has moved/renamed the books in the meantime. That seems like a minor concern given that:
- the PDFs feature presumably already exhibits this caveat (I don't know for sure as I don't use it); and
- the type of user who has a strong need for these files can probably work around it, somehow (e.g. I keep the ASIN in the filenames so I can always match stuff up later).
Describe alternatives you've considered Similar data can be obtained by enabling debug logging and then rescanning all accounts. But:
- It doesn't include chapter info, because only the content request endpoints return that. I use the chapter info quite heavily, so that would be a bit of a dealbreaker for me.
- It would still need to be manually dumped to .metadata.json files via some means, if the aim was to have it next to the audio files.
Additional context Sorry if this is a bit long/rambly, and thank you for all your work!
— Reply to this email directly, view it on GitHub https://github.com/rmcrackan/Libation/issues/969, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAJ7H6LSMN5PDLV57IRMJTDZUUWVFAVCNFSM6AAAAABNRHYV7CVHI2DSMVQWIX3LMV43ASLTON2WKOZSGUYDCOBWGQYDAMA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Interesting idea. For now, a lot of data is available via the Export menu. You can also get the raw metadata with this hack which is intended for debugging:
- Settings > Import settings tab. At bottom: Logging level: Debug.
- Do a scan
- In the same directory as your log file is now LibraryScans.zip. This is the full metadata from audible, 1 file per account
The above is a debugging tool and not an actual feature. No effort has been made to make this robust or user-friendly. For instance if you do 2 scans back to back, I don't remember if it will append or overwrite. etc. When you're done I recommend restoring logging level to Information
@rmcrackan Thanks for the response. I did mention the library scans available via debug logging in my original comment, noting the reasons why they aren't quite comparable (no chapter info being the big one).
The same applies to the JSON export Libation itself can perform. In addition:
- The JSON export is formatted completely differently (for obvious reasons). Any code written to work with metadata would need to be written to handle both formats.
- The exported JSON lacks certain information that is important to have, at least for my use case, like author/series ASINs. It also lumps multiple author/narrator/series names together as single strings, rather than as arrays or arrays of objects.
Note that none of these are intended as complaints. I use the metadata files precisely because the JSON export doesn't quite do what I need.