mirror of
https://github.com/advplyr/audiobookshelf-app.git
synced 2026-07-24 21:48:42 +02:00
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 #20
Assignees
adam (Adam Melkus)
Clear assignees
adam (Adam Melkus)
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: starred/audiobookshelf-app#20
Reference in New Issue
Block a user
Originally created by @zombiehoffa on GitHub (Nov 8, 2021).
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. The original mp3s are 303 MB, when I download the m4b on my desktop it works and comes in at 286 mb but when I download it on my phone via this app it always creates a 221MB file that won't play in audiobookshelf but will play in other apps. I don't see any obvious difference in the log output for either operation in the main app in docker and I don't see a way to get log data out of the android app or I would provide it...
@advplyr commented on GitHub (Nov 8, 2021):
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?
@zombiehoffa commented on GitHub (Nov 8, 2021):
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.
@advplyr commented on GitHub (Nov 8, 2021):
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?
@zombiehoffa commented on GitHub (Nov 8, 2021):
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:
@advplyr commented on GitHub (Nov 9, 2021):
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.
@zombiehoffa commented on GitHub (Nov 9, 2021):
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.
@advplyr commented on GitHub (Nov 10, 2021):
I'm release
v1.6.14of 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
m4bfile is because a concat does not require encoding and should be very fast. A concat should take a few seconds or less, whereas anm4bcould take several minutes.If you have an audiobook that is made up of multiple mp4's then it will download a single mp4.
@zombiehoffa commented on GitHub (Nov 10, 2021):
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.
@zombiehoffa commented on GitHub (Nov 10, 2021):
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.
@advplyr commented on GitHub (Nov 13, 2021):
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.