Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[API] Support search by filename #1044

Open
Fmajor opened this issue Aug 1, 2024 · 5 comments
Open

[API] Support search by filename #1044

Fmajor opened this issue Aug 1, 2024 · 5 comments

Comments

@Fmajor
Copy link

Fmajor commented Aug 1, 2024

Now the /api/search API seems to search in the title and tags field.
Can you support search by the filename field (or add a new parameters fields to control which fields to use for search)

@Difegue
Copy link
Owner

Difegue commented Aug 1, 2024

the filename field isn't really meant to be exposed.. it's just saved as raw bytes in the database to avoid having to care about filesystem encoding.

What are you trying to do where filename searches would help ?

@Fmajor
Copy link
Author

Fmajor commented Aug 2, 2024

the filename field isn't really meant to be exposed.. it's just saved as raw bytes in the database to avoid having to care about filesystem encoding.

What are you trying to do where filename searches would help ?

filename is the unique indicator for one item in the file system. I have custom scripts to download things and then tar them to the data folder of LANraragi, and then update metatdatas of these files. I need to known the maps between arcid and filename, so that my pipeline can work.

Now the default title is the filename, but after I update the title from some metadata source, I completely lost the map between one item and its conresponding file.

e.g., I want to force update metadata of a item (by providing its filename)

@gustaavv
Copy link

gustaavv commented Aug 3, 2024

I am in a similar situation like you, where I use scripts to automatically update the metadata.

Currently, there are no maps between arcid and filename.

The archive IDs computed by LRR are created by taking the first 512KBs of the file, and computing a SHA-1 hash from this data.

If you don't have the same archives in different paths, you can calculate the arcid of an archive on the client side, which will always be the correct one.

@Difegue
Copy link
Owner

Difegue commented Aug 3, 2024

Yeah I was going to recommend the same, calculating the IDs yourself is probably the easiest path forward here.
I'll still keep this issue open for tracking 👍

@vuhe
Copy link

vuhe commented Aug 17, 2024

Since custom scripts can directly access files through paths, they should be deployed locally in LRR.

If you need to know the mapping between arc_id and path, you can also try accessing Redis directly to obtain information. Reading only data should not affect LRR.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants