I have an mp3 audiobook with 18 tracks that creates a partial sized broken m4b when downloaded through this app but nearly full size when downloaded via desktop web browser about audiobookshelf-app HOT 10 CLOSED

If you go to the log on the config page and watch it as you press download in the mobile app you can check for errors.

This may be bug though because the app shouldn't be generating and m4b from mp3 tracks, all it should be doing is concatenating the mp3 files and downloading an mp3. The desktop web app will generate an m4b with embedded metadata and cover art.

Can you double check it is downloading an m4b on the app?

from audiobookshelf-app.

I apologize you are correct it looks like it is concatenating the mp3s for download on the app but on the app it is now failing out at 28kb downloaded. Here's the debug log for the transaction

On the phone it says it completed, but lists 28.4KB as the file size, when I investigate the directory it is supposed to be saving to. When I look in the metadata/downloads dir I see one mp3 that is 221MB (original mp3s are 303 MB), as well as a files.txt file that lists all 18 files that should be making up the new mp3. When I copy that mp3 out and play it it is cut off before the end of the book. The download on the app is stuck at 93% now (trying again) as I am watching it very closely so I wonder if I just missed timing out behavior on the app expecting more mp3 than was sent? if it finishes before I have to close the app and go to work Iw ill report back.

from audiobookshelf-app.

Log is showing download expired after 1 second.. I believe I have downloads set to expire after 10 minutes, so this could be a bug.
Are you experiencing this with any other audiobooks?

from audiobookshelf-app.

I tried another book with 64 mp3s and the file only came out a couple MB's smaller, played on the phone and was the whole book. Here's the log of that:

edit:
skipping ahead to check the book was complete generated a lot of log content, sorry here's the part where I requested the book:

from audiobookshelf-app.

I'm confused about the first thing you said. Do you mean that you tested on another audiobook and it worked fine?
So we can narrow it down to just be happening with that one particular audiobook.

from audiobookshelf-app.

yes, I tested one other similar audio book ( one with a bunch of mp3s making up the book) and it worked, so it's probably a problem with something in that book breaking concatenation. Do you happen to know how to get the concatenation command out so i can try it manually and see what happens?

Also, I am kind of curious now that I am not so focused on sorting this bug I thought applied to my whole collection out. You have it make an m4b if I download from the web browser, but create a concatenated single mp3 if I try to download it via the android app. Why the different behavior? It would have made more sense to me to just send the entire thing over to the app and store it in a directory and avoid the potential failure point of additional file modification, or for it to do the same behavior (make an m4b or concatenate) for both ways to download. There's extra work here to support two different paths for file modification, and I don't understand the reasons why.

from audiobookshelf-app.

I'm release v1.6.14 of the server now which fixes a bug with logging for downloads. The logs you showed were missing the most important info, so hopefully if you run again after updating we should see an error or some log with an ffmpeg command.

Working with a single file on the mobile app is easier to manage actually. The reason the mobile app concats the files instead of making an m4b file is because a concat does not require encoding and should be very fast. A concat should take a few seconds or less, whereas an m4b could take several minutes.
If you have an audiobook that is made up of multiple mp4's then it will download a single mp4.

from audiobookshelf-app.

So I did a bit more investigating and I think I have been leading us astray by reporting the file as 221MB on the server when that is what du is reporting it as, but looking at the actual size it is 302.9MB, which is correct. Sorry about this, I have disk compression turned on on that zfs array and it must be doing a better job than I expected...

What is actually happening is my regular android download dir have 11 copies of the book mp3 named kvpg8viy-1,2, etc and nothing is being copied to the book storage directory on the android phone so the bug is in the android app not completing the copy over and rename of the mp3.

from audiobookshelf-app.

I figured it out. I deleted the 11 copies in my download dir and that utterly broke the android app so that it wouldn't start, but once I deleted the cache, storage and app and reinstalled it downloaded no problem. The issue appears to be the app downloads it expending it to be named string.mp3 and when the android downloading mechanism finds string.mp3 already in the download dir it puts it in the download dir as string-1.mp3, at which points audiobookshelf app loses its mind and gives all this weird behavior.

from audiobookshelf-app.

We can keep this closed, but I want to add that the naming behavior of adding a hyphen # when the name is taken will need to be fixed. When that happens the file is no longer tracked by the app.

from audiobookshelf-app.