starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-07-31 00:48:39 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Enhancement]: Include itemid and "audiobookshelf" in metadata.json sidecars & API endpoint to pull itemid from the full path on disk. #1959

New Issue
Closed
opened 2026-04-25 00:01:46 +02:00 by adam · 2 comments
adam commented 2026-04-25 00:01:46 +02:00
Owner
Copy Link
Copy Source

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:

sqlitepwd="${PWD//\'/\'\'}"
itemid="$(sqlite3 "$abssqlite" "select id FROM libraryitems WHERE path=='$sqlitepwd';" ".exit")"

Searching the api documentation:

itemid
No Results Found for "itemid"

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!

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: ``` sqlitepwd="${PWD//\'/\'\'}" itemid="$(sqlite3 "$abssqlite" "select id FROM libraryitems WHERE path=='$sqlitepwd';" ".exit")" ``` Searching the api documentation: ``` itemid No Results Found for "itemid" ``` 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!**
adam added the enhancement label 2026-04-25 00:01:46 +02:00
adam closed this issue 2026-04-25 00:01:46 +02:00
adam commented 2026-04-25 00:01:47 +02:00
Author
Owner
Copy Link
Copy Source

@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.

@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.
adam commented 2026-04-25 00:01:47 +02:00
Author
Owner
Copy Link
Copy Source

@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 abc the 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.

@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 `abc` the 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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No labels enhancement
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#1959