You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Why you want this feature to be implemented? Please describe.
Current system has a lot of issues, such as: Buggy UI (#91) or No External Storage support (#78).
Describe the feature you'd like to be implemented
Faster, more universal approach, for example SAF.
Ironically all other android book readers "implementing" SAF from koreader to moon to others appear to do the same mistake: they don't allow you to scan a directory recursively to find the books you want on a non flat directory hierarchy.
It's awful, you either use a calibre webserver, or a opds server (like calibre web) or you import\add external paths the books slowly one by one. And opds servers never never bother with a flat library page with covers.
I guess I'll have to ressurect my very dead and very awful ebook project (bookjar) if I want a good flat searchable library. Well probably not but it's so annoying that I could do a flat metadata searchable cover libraryd that watched for new books and deletions, with glazed lists and lucene 20 years ago in java and android apps are still struggling importing showing remote files that exist in more than one dir. All this while importing a library of 5000 books while not blocking the UI and generating thumbnails.
This is actually just completely bizarre and must be a problem with using SAF or android killing apps that dare to import 100+ books at once, because it's kind of a standard of calibre\epub to keep the covers and metadata seperate from the epub in the same dir for speed, so when you import a epub normally you'll also want to import the cover and metadata file so you don't extract them.
I mean that usually a android ebook reader will "import" (either copy to the local filesystem or true remote access) a SAF file one at a time. Or at most all files in a single directory.
This is almost completely useless if you have a large book collection organized sanely (in a directory hierarchy). In fact the only exception I know is a program that is not a book reader, scummvm "adds" a directory to their own internal filechooser and can scan the whole directory tree. They do this with a virtual filesystem abstraction they use for their whole program that they specialize for SAF dirs: https://github.com/scummvm/scummvm/blob/master/backends/fs/android/android-saf-fs.cpp
it appears this is more complicated than just ask android native filechoooser to grant you access to a single dir...
Why you want this feature to be implemented? Please describe.
Current system has a lot of issues, such as: Buggy UI (#91) or No External Storage support (#78).
Describe the feature you'd like to be implemented
Faster, more universal approach, for example SAF.
Task list
The text was updated successfully, but these errors were encountered: