csandman
commented
3 years ago looks like I was able to fix it by running it with the platform tag:
docker build . -t m4b-tool --platform linux/amd64Closed csandman closed 2 years ago
csandman
commented
3 years ago looks like I was able to fix it by running it with the platform tag:
docker build . -t m4b-tool --platform linux/amd64
sandreas
commented
3 years ago This should be fixed in the mp4v2 repo. Feedback would be great.
csandman
commented
3 years ago @sandreas ok I'll give it a shot! so it looks like in your README you link to the latest tag in your releases but that is from 2019. If I'm installing using the docker method, do I still use the same link?
As in this:
docker build . --build-arg M4B_TOOL_DOWNLOAD_LINK=https://github.com/sandreas/m4b-tool/files/6584376/m4b-tool.tar.gz -t m4b-toolI always refresh the links. So the instructions in latest should be ok. Don't forget to skip caches / do a full rebuild :-)
csandman
commented
3 years ago The build ended up succeeding but now it's just stuck when I try and run a merge.
m4b-tool development, OS: Linux (Welcome to Alpine Linux 3.9
Kernel \r on an \m (\l))
'ffmpeg' '-hide_banner' '-version'
== load input files ==
searching for cover in output/source/James S. A. Corey/The Expanse Series/The Expanse - Book 02 - Caliban's War
using cover output/source/James S. A. Corey/The Expanse Series/The Expanse - Book 02 - Caliban's War/cover.jpg
skip cover extraction, file output/source/James S. A. Corey/The Expanse Series/The Expanse - Book 02 - Caliban's War/cover.jpg already exists - use --force to overwrite
preparing conversion with 8 simultaneous jobs, please wait...
'ffmpeg' '-nostats' '-loglevel' 'panic' '-hide_banner' '-i' 'output/source/James S. A. Corey/The Expanse Series/The Expanse - Book 02 - Caliban'\''s War/Track 01.mp3' '-map_metadata' '0' '-max_muxing_queue_size' '9999' '-strict' 'experimental' '-movflags' '+faststart' '-vn' '-ab' '64k' '-ar' '22050' '-ac' '0' '-acodec' 'aac' '-f' 'mp4' '/tmp/m4b-tool/01-converting.m4b'
'ffmpeg' '-nostats' '-loglevel' 'panic' '-hide_banner' '-i' 'output/source/James S. A. Corey/The Expanse Series/The Expanse - Book 02 - Caliban'\''s War/Track 02.mp3' '-map_metadata' '0' '-max_muxing_queue_size' '9999' '-strict' 'experimental' '-movflags' '+faststart' '-vn' '-ab' '64k' '-ar' '22050' '-ac' '0' '-acodec' 'aac' '-f' 'mp4' '/tmp/m4b-tool/02-converting.m4b'
'ffmpeg' '-nostats' '-loglevel' 'panic' '-hide_banner' '-i' 'output/source/James S. A. Corey/The Expanse Series/The Expanse - Book 02 - Caliban'\''s War/Track 03.mp3' '-map_metadata' '0' '-max_muxing_queue_size' '9999' '-strict' 'experimental' '-movflags' '+faststart' '-vn' '-ab' '64k' '-ar' '22050' '-ac' '0' '-acodec' 'aac' '-f' 'mp4' '/tmp/m4b-tool/03-converting.m4b'
'ffmpeg' '-nostats' '-loglevel' 'panic' '-hide_banner' '-i' 'output/source/James S. A. Corey/The Expanse Series/The Expanse - Book 02 - Caliban'\''s War/Track 04.mp3' '-map_metadata' '0' '-max_muxing_queue_size' '9999' '-strict' 'experimental' '-movflags' '+faststart' '-vn' '-ab' '64k' '-ar' '22050' '-ac' '0' '-acodec' 'aac' '-f' 'mp4' '/tmp/m4b-tool/04-converting.m4b'
'ffmpeg' '-nostats' '-loglevel' 'panic' '-hide_banner' '-i' 'output/source/James S. A. Corey/The Expanse Series/The Expanse - Book 02 - Caliban'\''s War/Track 05.mp3' '-map_metadata' '0' '-max_muxing_queue_size' '9999' '-strict' 'experimental' '-movflags' '+faststart' '-vn' '-ab' '64k' '-ar' '22050' '-ac' '0' '-acodec' 'aac' '-f' 'mp4' '/tmp/m4b-tool/05-converting.m4b'
'ffmpeg' '-nostats' '-loglevel' 'panic' '-hide_banner' '-i' 'output/source/James S. A. Corey/The Expanse Series/The Expanse - Book 02 - Caliban'\''s War/Track 06.mp3' '-map_metadata' '0' '-max_muxing_queue_size' '9999' '-strict' 'experimental' '-movflags' '+faststart' '-vn' '-ab' '64k' '-ar' '22050' '-ac' '0' '-acodec' 'aac' '-f' 'mp4' '/tmp/m4b-tool/06-converting.m4b'
'ffmpeg' '-nostats' '-loglevel' 'panic' '-hide_banner' '-i' 'output/source/James S. A. Corey/The Expanse Series/The Expanse - Book 02 - Caliban'\''s War/Track 07.mp3' '-map_metadata' '0' '-max_muxing_queue_size' '9999' '-strict' 'experimental' '-movflags' '+faststart' '-vn' '-ab' '64k' '-ar' '22050' '-ac' '0' '-acodec' 'aac' '-f' 'mp4' '/tmp/m4b-tool/07-converting.m4b'
'ffmpeg' '-nostats' '-loglevel' 'panic' '-hide_banner' '-i' 'output/source/James S. A. Corey/The Expanse Series/The Expanse - Book 02 - Caliban'\''s War/Track 08.mp3' '-map_metadata' '0' '-max_muxing_queue_size' '9999' '-strict' 'experimental' '-movflags' '+faststart' '-vn' '-ab' '64k' '-ar' '22050' '-ac' '0' '-acodec' 'aac' '-f' 'mp4' '/tmp/m4b-tool/08-converting.m4b'
18 remaining / 18 total |Its been on 18 remaining for about 4 hours now. With the platform flag I mentioned earlier it worked at least, now not so much.
sandreas
commented
3 years ago Thanks for the quick feedback. Well this is strange... there must be a ffmpeg-dialog that is invisible. 4 hours is way too long, especially when there is no progress and your files are not the size of GB. You could try to use merge with 2 small files an see if there is any, but I'm afraid, that there is still something wrong.
Unfortunately I got no M1 Mac, but I'm gonna check the latest m4b-tool on my machine again, maybe I broke something else.
sandreas
commented
3 years ago Well, on my machine everything is working correctly. I improved the logging with the latest pre-release, but I suspect that there is something else, that does not work. Maybe you could try to login into your docker and try to run one of the commands manually?
Perform the following while the jobs are running:
# find out the m4b-tool container id
docker ps
# start a shell
docker exec -it <containerid> /bin/ash
# run one command that might be stuck:
'ffmpeg' '-nostats' '-loglevel' 'panic' '-hide_banner' '-i' 'output/source/James S. A. Corey/The Expanse Series/The Expanse - Book 02 - Caliban'\''s War/Track 01.mp3' '-map_metadata' '0' '-max_muxing_queue_size' '9999' '-strict' 'experimental' '-movflags' '+faststart' '-vn' '-ab' '64k' '-ar' '22050' '-ac' '0' '-acodec' 'aac' '-f' 'mp4' '/tmp/m4b-tool/01-converting.m4b'And then see, if you can figure out, what the problem is (maybe ffmpeg is asking for input?)
csandman
commented
3 years ago So I gave running it inside the container a shot, and it also appears to just be hanging still:
csandvik@Chriss-MacBook-Air audiobook-scraper % docker exec -it 4e07fe18c43e /bin/ash
/mnt $ 'ffmpeg' '-nostats' '-loglevel' 'panic' '-hide_banner' '-i' 'output/source/Eoin Colfer/Artemis Fowl Series/Artemis Fowl - Book 01 - The Fowl Twins, Book One/Track
08.mp3' '-map_metadata' '0' '-max_muxing_queue_size' '9999' '-strict' 'experimental' '-movflags' '+faststart' '-vn' '-ab' '64k' '-ar' '22050' '-ac' '0' '-acodec' 'aac' '-
f' 'mp4' '/tmp/m4b-tool/8-converting.m4b'
File '/tmp/m4b-tool/8-converting.m4b' already exists. Overwrite ? [y/N] y
/mnt $ 'ffmpeg' '-nostats' '-loglevel' 'panic' '-hide_banner' '-i' 'output/source/Eoin Colfer/Artemis Fowl Series/Artemis Fowl - Book 01 - The Fowl Twins, Book One/Track 08.mp3' '-map_metadata' '0' '-max_muxing_queue_size' '9999' '-strict' 'experimental' '-movflags' '+fastst/mnt $ 'ffmpeg' '-nostats' '-loglevel' 'panic' '-hide_banner' '-i' 'output/source/Eoin Colfer/Artemis Fowl Series/Artemis Fowl - Book 01 - The Fowl Twins, Book One/Track 08.mp3' '-map_metadata' '0' '-max_muxing_queue_size' '9999' '-strict' 'experimental' '-movflags' '+fastst
art' '-vn' '-ab' '64k' '-ar' '22050' '-ac' '0' '-acodec' 'aac' '-f' 'mp4' '/tmp/m4b-tool/8-converting.m4b'
File '/tmp/m4b-tool/8-converting.m4b' already exists. Overwrite ? [y/N] y
After that there is just an empty line with no progress.
sandreas
commented
3 years ago So it's and ffmpeg problem (not something, I could fix in m4b-tool code). This might be, because I just copy the static ffmpeg from mwader image - which might be x64 only (I have to do a bit of research here). Maybe an upgrade helps, you could try to replace this in Dockerfile:
# COPY --from=mwader/static-ffmpeg:4.2.2 /ffmpeg /usr/local/bin/
COPY --from=mwader/static-ffmpeg:4.4.0 /ffmpeg /usr/local/bin/But I'm pretty sure this will not help much. Maybe compiling ffmpeg manually will do the trick, but I'll try to find some reliable information about this.
If I can do something about it, I will try to update the Dockerfile
wader
commented
2 years ago Hey, this discussion might be interesting about arm builds of static-ffmpeg https://github.com/wader/static-ffmpeg/issues/158#issuecomment-1034928961
Hopefully will get multi-arch builds in the future somehow, unfortuently a it's a bit messy to do as it is now.
sandreas
commented
2 years ago Hey, this discussion might be interesting about arm builds of static-ffmpeg https://github.com/wader/static-ffmpeg/issues/158#issuecomment-1034928961
Thank you, this is very helpful.
Hopefully will get multi-arch builds in the future somehow, unfortuently a it's a bit messy to do as it is now.
I plan to do so, there is a lot on my todo list... I would also like to migrate mp4v2 to the new maintained fork https://github.com/enzo1982/mp4v2/
Edit:
@wader Wait, are you the maintainer / owner of mwader/static-ffmpeg? Awesome work! How did you find your way to my little project m4b-tool lol
wader
commented
2 years ago Yes is me, thanks :) Was doing some surveying how people are using it and what issues there are. But think i've seen your repo before for some reason, probably from me just lurking around in various media projects.
sandreas
commented
2 years ago Yes is me, thanks :)
@wader: Unbelievable. Thank you for maintaining the project. I use it everywhere :-)
wader
commented
2 years ago Glad to hear it's useful! I use ffmpeg in a lot of place also.. that was kind of the reason it got started, was a pain to build many variants or use pre-packaged binaries with different versions of ffmpeg :)
wader
commented
2 years ago @sandreas hi again, since mwader/static-ffmpeg:5.0.1-3 is now a multi-arch amd64 and arm64 image
sandreas
commented
2 years ago hi again, since mwader/static-ffmpeg:5.0.1-3 is now a multi-arch amd64 and arm64 image
This is awesome news. I try to implement this as soon as possible. @wader Is there anything I need to do except upgrading the version number in the Dockerfile?
wader
commented
2 years ago Nope hat should be it, docker should figure out the rest automatically. Let me know how it goes
sandreas
commented
2 years ago Nope hat should be it, docker should figure out the rest automatically. Let me know how it goes
Thank you, you probably saved me a lot of work.
wader
commented
2 years ago Thank you, you probably saved me a lot of work.
No problem, @pldin601 did more or less all the work, so thank him :)
csandman
commented
2 years ago @wader that's great news! I was actually just looking at https://github.com/wader/static-ffmpeg/issues/94 yesterday, curious about the progress!
sandreas
commented
2 years ago Ok, a quick check seems to work - I upgraded the docker file. I would love to get feedback for M1 Macs. If I do not get feedback, I'll close this issue soon assuming that it is fixed.
csandman
commented
2 years ago @sandreas I can give it a shot when I have some time
krejko
commented
2 years ago I was curious if we could also get support for 32 bit arm (armv7?, not 100% on the naming). This would be super helpful for anyone running Raspberry Pis without the brand new 64bit os. Thanks!
(sorry if this is the wrong location for the request, was linked to from this issue)
wader
commented
2 years ago @krejko Hey, yes sadly there is only 64bit ARM support at the moment. I wrote a comment some time ago for the reasons why it's a bit complicated https://github.com/wader/static-ffmpeg/issues/94#issuecomment-886467154 TLDR: it is possible but very inconvenient and hard to maintain.
The reason why we got 64bit ARM now was because AWS offers native 64bit ARM hosts and @pldin601 made a github action that made it easy and convenient to use.
But i would like to support as many architectures as possible so if we can find a convenient way to support it i'm up for it.
@pldin601 do you know if AWS or someone else offers 32bit v7 ARM hosts? could we make a 64bit ARM host run in 32 bit mode somehow?
wader
commented
2 years ago Reading about AWS Graviton2 ARM hosts i get feeling there is some kind of 32bit support but a bit confusing. What would happen if you booted a ARM v7 linux kernel? would it act exactly like it was a ARM v7 or would some 64bit-ness leak thru and mess up for some build systems?
pyldin601
commented
2 years ago @pldin601 do you know if AWS or someone else offers 32bit v7 ARM hosts? could we make a 64bit ARM host run in 32 bit mode somehow?
No, I have no idea about different services, but I briefly looked into AWS AMIs and hasn't found any 32-bit Linux distros, even x86.
Reading about AWS Graviton2 ARM hosts i get feeling there is some kind of 32bit support but a bit confusing. What would happen if you booted a ARM v7 linux kernel? would it act exactly like it was a ARM v7 or would some 64bit-ness leak thru and mess up for some build systems?
AFAIK, in addition to the kernel, all applications must be compiled for 32-bit architecture. Furthermore, are you sure that all codecs used in static-ffmpeg can be compiled in 32-bit mode?
csandman
commented
2 years ago @sandreas I just gave it a shot on my M1 mac, no issues building or running m4b-tool with Docker with the newest changes to the Dockerfile! You should be good to close this issue.
wader
commented
2 years ago Don't think i can promise anything about other arm variants, but i can comment in #156 etc if there is some progress.
sandreas
commented
2 years ago Don't think i can promise anything about other arm variants, but i can comment in https://github.com/sandreas/m4b-tool/issues/156 etc if there is some progress.
@wader Very kind of you... maybe it is more my job to keep an eye on your project, but if you would like to report updates, it would be great support.
Closing this issue due to positive feedback. Thanks to all participants.
I recently got a new M1 Macbook Air and tried to run a build on this project. It ended up failing with the following error: