mirror of
https://github.com/advplyr/audiobookshelf.git
synced 2026-05-30 23:40:40 +02:00
[Enhancement]: Include itemid and "audiobookshelf" in metadata.json sidecars & API endpoint to pull itemid from the full path on disk. #1959
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#1959
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 @iconoclasthero on GitHub (May 6, 2024).
Describe the feature/enhancement
I have another FR requesting the ability to change the name of metadata.json so that it matches the rest of the files in the directory, this is for file maintenance purposes. Additionally, metadata.json is generic and could conflict with another application.
I want to use the metadata.json files in my library for cli scripting and it would be helpful if there was some way to verify that it is an abs-created metadata.json, but I don't see any sort of designation for that. Maybe that's not a thing that's done in .jsons? I dunno, but between the generic file name and the lack of anything that specifically ties it to abs, means that I've been unable to come up with a way to verify the metadata.json i'm running through jq is from abs.
A good deal of the end points require the itemid, but there's no itemid query i could find. You basically need to know the itemid before you can do a lot of the things. The easiest way to get the itemid given the path that I've found is to query the sqlitedb:
Searching the api documentation:
So if there was an endpoint to do this with the API, then the sqlite db could be left alone, and itemid could be retrieved remotely, however, ideally, the itemid would be included in the metadata.json sidecar so it's right there for jq to pull for an api query!
@advplyr commented on GitHub (May 6, 2024):
Item id should not be in the sidecar file, that is only metadata so you could share it with someone who has the same audiobook and it gets scanned in.
I don't see the value in adding that API endpoint. It seems like you already wrote a script to query the db to find what you need which is a good solution. You can also use the endpoint to get library items in a library and traverse through it to find what you need. You can share specifically what you are trying to do with the API and why then maybe we can find a better solution for you.
@iconoclasthero commented on GitHub (May 10, 2024):
Goal: As per the discussion last weekend, I'm looking to establish some ability to run CLI/ChUI queries at a minimum. To put it fairly succinctly: I want
abcthe audiobookshelf cli that is what mpc is to mpd.* I, personally, am unable to glean any benefit from icon-based displays of music or audiobooks and, again personally find them extremely and disproportionately frustrating...thought this is apparently a minority view. As such, I'm going to develop what I can.(A ChUI was one of my first FRs as was some sort of DB query. The ability to access those functions from bash is still something I use and need/want to be extended.)
With that in mind, the first thing I did was extend the m4b indexing functionality to opus with updated chapter info from the web via the API. This will also allow me to drop chapter information into audiobooks via a simple script I can execute over ssh on my phone... I don't have to use the webui at all if the book has an ASIN. This basically takes care of another FR I put in.
I know that there are some abs/python3 libraries being developed and python's easy enough, but I only know BASH so that's where I'm going to start to figure out what I eventually want to develop. That said, there are some places I know I want to start and that is with the aforementioned queries.
Presently, the only queries I can run (i.e., via GNU find) are based on my file structure and they end up being Author(s); Title: Subtitle; and Year. That takes care of most of what I need, but since I now have this entire database of metadata on my audiobook library that abs has created, it makes sense to leverage that rather than either trying to index the files myself or, worse, trying to query the opus metadata or the metadata.json.
Speaking of which, the rationale for not putting the itemid in the sidecar makes sense. I still wish that there was at least something that would identify it as an abs file...the only test i could come up with for that is to run .json through jq and check the index against what it should be.
rationale for itemid endpoint
I suggested using the PWD because that is something I know without reference to anything other than my file system, so it's a known known and it is in the database so I know that it is a handle that can be used. Also, it is unambiguous and unique while the title is not. So, let's say I want to do something with one of the three copies of Moby Dick I have. How do I start with the API? Search for Melville or Moby Dick? ...So where do you envision someone starting here because I see a chicken-egg problem.
* I use CLI for 99% of how I interact with my music collection (let's exclude Picard...which is a gui for processing text). Most of those are custom scripts, so I have every reason to want, desire, expect to be able to do the same thing with other self-hosted platforms on my server.