While I was reading the suggestions on the roadmap I felt that managing files still is a topic that could need refinement in later versions. It is by far not a pressing issue, but maybe a thought to keep in mind for later versions.
For video files there are fully fledged solutions, such as the very powerful nPlayer, which allows maintaining a list of logins to network shares (SMB/CIFS, (S)FTP, WebDAV, etc.), from which files can be downloaded to the device. nPlayer would then get meta-data and cover art from various sources, such as the IMDB api.
To my knowledge, an API like that doesn't for audiobooks (yet). But it still would be nice to have BookPlayer index a folder and its subfolders on one (or more) network share(s). BookPlayer could import meta-data, as well as extract the cover art, title and duration from the stored files upon an initial load and then upon refresh only update titles that got altered or added.
The audiobooks could then be displayed in a gallery or list style view. Tapping a cover could start a download to the device.
As far as I have tested iCloud is the only storage provider that displays cover art via the Files app. When I access Synology network shares (via the Synology Files app integration) or Dropbox/Drive no cover art is shown. Personally I think cover art is very helpful when scanning a list of files.
That view that compiles all the available books could also help to keep track of the "to read/listen" list. It could utilize the completed boolean state, which could be stored on device for the indexed files on network shares, which already have been removed from the device after listening.
In that way BookPlayer could become a personal "audiobook manager" without the need for a clunky server-side application, such as Plex or other media centers.
Thanks a lot in advance.
@GianniCarlo will have to weight in here, but for me this is way beyond the scope of this application. BookPlayer provides a simple solution to listen to audiobooks. Adding files is possible from all types of file management apps without requiring us to implement such a solution.
I know this sounds harsh and I apologize for that, but a good app has to maintain focus. Some of the problems you describe should be handled in apps you mention, so you should file a feature request for artwork handling with the DS File app.
Hi @boettges , we've discussed something similar to what you're mentioning, I do want a list (like audible) to know all the books I've listened to, and re-download them if I wish to listen to them again.
The steps towards that end are:
For the time being we've defined that the iCloud integration would store the hash of the file too, and let you re-add the book if you have the proper file. The last step is still up for debate on actual implementation, since this most definitely would mean integration to a paid cloud storage, and would mean having some sort of paid tier inside the app. We would like to keep the app in its entirety free, so we'll revisit that last step once the iCloud integration is done.
@GianniCarlo That sounds more than good. It actually seems like a feasible solution that does not require complicated network protocol connections.
The persistent list of completed books is exactly the core feature that I would appreciate.
The main reason for the proposed network share access would be that the need to load the files onto the device to scrape the meta-data could be skipped. But of course adding network share access natively in the app opens up a whole new level of compexity.
@pichfl I'm fully aware of that. By no means was my suggestion a demand.
@boettges feel free to help out with any open issue if you have the time 馃榿. I'm closing this issue since I think we're on the same page on this topic 馃憤
closing this in favor of #287 which will follow the progress on the second step regarding iCloud sync