I haven't found a solution, but I can also confirm that 1.17.7 worked for me first try whereas I'd been struggling with 1.18.3.
I was wondering if the issue was with my installation of Linux Mint, so I spun up an Ubuntu VM which appeared to work (aside from some VM-specific issues). Feeling good, I did a live boot of Ubuntu, installed MakeMKV via Snap, and then immediately ran into the same issue.
Someone on Reddit suggested I do the LibreDrive firmware, but I don't know how to do that on Linux and I don't have another Windows machine (this desktop now running Mint was my last).
MakeMKV above v1.17.7 still broken on Linux
-
WoodenCheese
- Posts: 1
- Joined: Mon May 04, 2026 6:28 pm
Re: MakeMKV above v1.17.7 still broken on Linux
As far as I know, flashing firmware and dumping firmware are broken on Linux with any version newer than 1.17.7. This might be why MakeMKV hangs - I believe it's trying to get the firmware dump, but due to the bug with the newer versions, it can't.
I think I had to insert a Blu-ray disc in order to get the firmware dump.
(Note that when downgrading, you don't need to downgrade the GUI, AFAIK. Just downgrading makemkv-bin should work.)
I believe the "firmware tar file" should start with "dump_FW" and is actually a tgz file (so a tar/gzip archive, basically). It can be obtained by downgrading MakeMKV to a version that supports firmware dumping, or by using MakeMKV on Windows and then copying the file into your Linux MakeMKV config folder, for example.Do you need to download that manually?
I think I had to insert a Blu-ray disc in order to get the firmware dump.
To the best of my knowledge ? Yes, it will work. Just having the firmware dump tgz file inside the right folder certainly fixed the issue for me.If you get it downloaded using 1.17.7 does that mean you can then install a later version and it will work?
(Note that when downgrading, you don't need to downgrade the GUI, AFAIK. Just downgrading makemkv-bin should work.)
-
nuts_fulgurates
- Posts: 3
- Joined: Sat May 09, 2026 2:56 am
Re: MakeMKV above v1.17.7 still broken on Linux
Version 1.18.3 works for me after flashing my drive with LibreDrive firmware on Debian 13.
Before flashing with LibreDrive I got the infinite spin. After flashing it works fine.
Before flashing with LibreDrive I got the infinite spin. After flashing it works fine.
Re: MakeMKV above v1.17.7 still broken on Linux
I'm finding that the checksums for the tar.gz files on the old downloads page don't match the hashes from the accompanying .txt files. Is that happening for anyone else, or just me? I've tried 3 files and none of them match...
Re: MakeMKV above v1.17.7 still broken on Linux
Please see this topic for more information on the checksum issue : viewtopic.php?f=3&t=41798
Re: MakeMKV above v1.17.7 still broken on Linux
Checksums match. Do not use Firefox for donwloading. Bug in Firefox.labmonkey wrote: Wed Jun 10, 2026 7:43 pmI'm finding that the checksums for the tar.gz files on the old downloads page don't match the hashes from the accompanying .txt files. Is that happening for anyone else, or just me? I've tried 3 files and none of them match...
Debian
MakeMKV 1.17.6 (Registered)
MakeMKV 1.17.6 (Registered)
Re: MakeMKV above v1.17.7 still broken on Linux
I can confirm this, I used wget and everything is fine checksum-wise now. Thank you very much for solving this mystery.Checksums match. Do not use Firefox for donwloading. Bug in Firefox.
Re: MakeMKV above v1.17.7 still broken on Linux
Not exactly.
Apparently it's really just that Firefox sends this header:
Code: Select all
Accept-Encoding: gzip, deflate, br, zstd
Which apparently result in the server to perform on-the-fly gzip compression on what it serves -- only those that has already gzip-compressed. (I'm not sure what's the exact "criterion" that triggers the compression. Could be any file type that the server "doesn't really recognize" -- the content-type response header is set to "application/octet-stream" when a *.tar.gz is requested from it, whereas for .exe and .dmg the header would be set to something more specific.)
With that said I did see that there has been discussion (decades ago) about whether Firefox should decompress such on-the-fly compression -- or more precisely, when the response header "content-encoding: gzip" is received, it seems like the verdict is that it should only do so conditionally -- when the extension is not .gz. (I think the argument is more or less like "we cannot tell whether it is on-the-fly compression done by the server or not when the file is served with the header and named with .gz".)