Repository navigation
Replies: 20 comments
|
Very interesting ideas. I am very hesitant on adding another way of adding folders because it is already quite complex for users to understand the current folder modes right now. On the idea of adding more metadata and utilizing it in the search: |
I hear you. My vision would be to have only two modes (because either you tagged your files correct or you need parts of the filename used for book data):
Unfortunately this is a long way to go. To prevent breaking things I think that adding the
Great. I'm working on it, but I'm not promising anything :-) These changes only make sense, as long as the fields have real content and therefore I must check the reading process for
Yeah we could establish a |
|
Regarding parsing, my preference would be that we can rely on media3 as much as possible and would not need to do any byte magic. Media parsing is ugly (well it's beautiful if tagging programs ahere the standards but many don't) Ideally everything is in here already: https://github.com/androidx/media/blob/release/libraries%2Fexoplayer%2Fsrc%2Fmain%2Fjava%2Fandroidx%2Fmedia3%2Fexoplayer%2FMetadataRetriever.java |
Yes, I'm trying to do it correct. Since I'm pretty new to Android / Kotlin development, maybe I need some help with the polish, but I think I can do the ground work.
If these are really bugs in media3, I'm afraid we have to either agree on a partial solution (supporting only I'm skipping |
|
@PaulWoitaschek Update: I filed an issue with a feature request: androidx/media#2754 See Screenshot and this code reference, there is no trace for 
|
|
@PaulWoitaschek |
|
Ok, since this is done now, I would like to take the next step towards First I would like to outline, what the General Rules
Possible Additions (later)
Use Case - one book per directory, multiple files for one book Example: Result: 2 books found
Use Case - files in the root directory Result: 3 books found
Use Case - multiple files in the a directory each representing one book Result: 4 books found
ignored Use Case - one audio book in multiple sub folders I would ignore this use case for now, maybe we find a solution for something like this later I would implement a producer/consumer (https://kotlinlang.org/docs/channels.html#buffered-channels) to scan the filesystem with a limit of 250 files, a total filesize of 1.5GB and reading their metadata in the background - then group the books based on the found metadata and the file and directory names. What do you think? |
|
@PaulWoitaschek There are some things I stumbled over and that I would like to have a (short) conversation about... The
So besides the fact, that I cannot wrap my head around the fact, that a Questions:
Soon I'm going to post some code to explain further... |
|
I still can't wrap my head around the general idea of the Auto mode. UX wise right now I see these options:
That auto mode would need to be very functional and for cases where it has a low certainty it needs to have a UX flow that helps users resolving it. On the technical questions:
Yes, it has a built-in cache. That's good because that leads to unnecessary parsing being omitted.
No, it either reads from cache or it analyzes and then writes to cache. If it would only do the parsing, it would be inefficient because it would lead to multiple scans of the same file.
I don't understand. Directories don't have metadata and authors. I have the feeling we're talking past each other. |
I try to keep my explanation simple. Example rules:
We want this: to be separate books, not ONE book with multiple chapters, as it is now. A VERY early draft (see I'm still figuring out the producer/consumer pattern in Kotlin - the idea is to separate the file-scanning, the metadata-retrieval and the categorization (file=whole-book or file=book-chapter). I also have to adjust the test code because it uses My final approach (for the distant future) would include 2 modes (replacing the 3 modes that currently exist):
I really hope the code example of |
After doing some more research, I think I now can break down the problem. Definintion:
Process description:
The Problem (unfortunate): |
|
@PaulWoitaschek At the moment this implementation is pretty simple - but it could be extended to use analyzed directory files combination of Limitations:
Let me know what you think - I would really appreciate your feedback, especially on the |
|
I really love your enthusiasm and all the ideas you bring to the table! I'm pretty confident you have the technical solutions and a way that will make it work for your use-case. But the hard thing for me to solve here is how to build a great product from it. Letting users type a template language will certainly work for programmers. But the majority of our users are people who just randomly throw in audiobook files and they just want to play it. And their metadata is a random mix. They need an App which they immediately understand. Before we jump into the technical solutions we need a solid product concept. And this is where I'm currently not having the capacities for. So I'm open to discuss a few changes that would make it easier for you to maintain a fork, but I do not see it currently as an option to really bring this to users. |
I think you already have a great product. The way you're protecting it from stuff which does not fit your vision is respectful, clear and you have high quality standards. That's a good thing.
Probably, but that's not what I had in mind. The template language should be the technical concept behind storing the user input. The UI should just allow changing the order via selectable named placeholders. I made a little browser demo here of what I had planned: 
Here you can play with it: https://pilabor.com/voice-demo/ This would just be more flexible than having to select a predefined pattern via radio button. And please keep in mind: This would be the
And that's the thing that I totally accept. I'm with you on that and it's fine. Having to maintain an open source project is huge and should not be punishing in a way that it eats up time that you could spend with your family. Instead it should be fun and enriching :-) Additionally, my Android / Kotlin skills aren't there yet. I played around a bit but I'm nowhere near a seasoned Android developer contributing to a well maintained project. So just do your thing keeping Voice up to date, I keep maintaining my little changes in a fork and as soon as you feel that the situation is right to talk again, reach out. There is one more thing I would like to emphasize: The issue, that a directory structure like this cannot be loaded as separate audio books is still valid. I'm not sure, if there is a method to load these, but I did not find one except adding each file separately. I think #3048 is either related or exactly what I'm talking about :-) If you sync your books with a third party app that cannot change the directory structure, this is really frustrating and impossible to solve (without maintaining a fork ;-)). |
|
Thanks for your understanding! On the concrete problem and the mentioned strucutre: If you select it and pic |
I'm so sorry, the example in my last comment above was wrong (in the original issue text it was correct). There needs to be a subdirectory for series... so the pattern is
Here is a corrected example: There is also no unit test for |
Sorry for derailing discussion but reading this I've remembered I had some cache issues in the past and I have a question. Is book cache entry ever become obsolete/removed? E.g. I had some
I personally like to have pattern parsing option. And pattern usage is pretty common in library collection software like calibre or various standalone ebook converters. But proposed variant is too basic and IMHO it should also support optional arguments with if/else logic (or ternary conditions) to be usable on book collections. E.g. there is often no point in creating |
Answering your question ONCE might prevent the need for an extra discussion so: I get your point that a "simple" comparison would be nice to have to automatically invalidate cached files on changes. Maybe this could be done by some kind of
This would be WAY too much effort - not only in the logic department but also within the UI. Having a scripting language (IF / ELSE / Functions) to match a directory structure is prone to be over-engineered and hardly usable on a mobile device (IMHO). I'd instead suggest to have either multiple patterns per directory using the first match and others as fallback or, as Voice already supports, just adding multiple "virtual" directories with different patterns pointing on the same physical directory. And as already stated: I don't like the manual |
I guess this can work fine but can be a bit fragile. If this option is power user anyway and to not reinvent the wheel why not just use regular expressions with named capture groups instead? That way you can have relatively simple syntax for simple cases, e.g.
Compacted and optimized != unmaintained :-) |
You're clearly biased by too much developer experience ;) There is no way even power users want to use regular expressions for this. I'm a techie but even I don't want to use such a thing let alone typing a regex with special chars on a mobile devices keyboard hoping it'll work without an option to test. If you would like to see a more or less working version of the auto scanner, you could take a look at my fork. This is something I wrote for myself, so it might not match your use case. However, I don't thing that this ( |
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
Overview
Hi,
I'm using
Voiceas my favorite audio player for local files.Since there is no integrated possibility to access Network repositories (like
JellyfinorAudiobookshelf) I useAudiobookshelfas my companion app to download remotely stored audio books into a local folder and then usingVoiceto scan and play it. The following structure is created ( base folder is/Internal Storage/Audiobooks/Audiobookshelf:<Author>/<Series>/<Part> - <Title>.m4bExamples:
There are 3 modes to scan for books:
Unfortunately none of them can be used to scan the whole folder and result in a correct listing of audio books. The
Authorsmode comes close, but groups different parts of the same series to ONE book, which is wrong.Now, there are workarounds to this, but:
Looking around I found this discussion and tried to write code for a solution, but I found problems that I think should be solved before:
MediaScannerandBookParseronly rely on the folder structure instead of the audio metadata tags to add books%author%/%series%/%part% - %title%.m4b) when selecting a ModeSo my suggestion for a fix would be a 3 step process:
Series,Part,Narrator,Genre)SeriesandPartare required for a difference when books have the same name (example)Narratoris required, because a book can be read by different narrators (example1 - example2)Genreis not required but helpful for searching new audio books of a specific genre (e.g.Fantasy)MediaScanner/BookParserto read (at least some) metadata before categorizing a folder / file asSingle File BookorFolder With Multiple Files BookModenamedAuto - I tagged my files very carefully, so use these instead of relying on file structureNote:
Partshould be a string, because there are part names like2.1which cannot be represented by an integer.The steps that could work in my opinion are:
Author,Title,Narrator,SeriesandPart(this could also be done via sql files table for huge libraries)So, would you consider adding the follwing metadata fields (including
bookSearchFtsfor fulltext search) as a first step?Series(akamovementName)Part(akamovementIndexorPart)Narrator(akaComposer)GenreHow to reproduce
Create a folder with the mentioned structure including multiple
m4bfiles having representing one book each.Version
Latest
Android Version
13
Device Model
Pixel 4a
All reactions