I've noticed difficulty downloading the 1.18.3 files, or really any file.
I have been troubleshooting a persistent issue with MakeMKV 1.18.3 on a Linux/ARM environment for the past 7 days. After extensive testing, it appears that a seeming MakeMKV server instability is triggering a critical failure in the software’s network error-handling logic, rendering the Linux binary effectively unusable during this outage.
Symptom
When running makemkvcon (either via ARM/Docker or direct CLI), the process enters a permanent 100% CPU hang.
By enabling --debug, the log reveals the process is stuck in an infinite loop at this stage:
No SDF v0a5: [Drive ID]
SDF auto v0a5: [Drive ID]
Technical Investigation & "Broken Handshake"
Through network analysis and command-line isolation, I have confirmed the following from my part of the internet:
DNS Resolution:
www.makemkv.com and forum.makemkv.com resolve correctly to Cloudflare IPs (172.67.195.244 / 104.21.49.241). However, ident.makemkv.com (which formu/reddit, I don't remember states this is used for key validation) does not resolve at all, even when queried directly against the authoritative NS servers.
CDN Failure: While the website may appear to load, it is sporadic. I have frequently encountered Cloudflare "Host Error" pages, indicating the origin server behind the CDN is unreachable.
The 8KB "SDF" Trap: Attempts to fetch
https://www.makemkv.com/sdf.bin via CLI often result in an 8.2KB file. This is NOT the SDF table; it is the HTML for the Cloudflare 502/504 error page. The Linux binary appears to try and parse this HTML as a binary file, fails, and retries indefinitely, pinning the CPU.
This behavior of difficulty in retrieving files also extends to makemkv-bin-1.18.3.tar.gz and makemkv-oss-1.18.3.tar.gz
The "Unshare" Test: By running sudo unshare -n makemkvcon -r info dev:/dev/sr0 (stripping network access), the 100% CPU loop disappears instantly. However, the binary then fails with "This application version is too old," likely because it cannot perform the required "heartbeat" to validate the current Beta key or internal expiration date.
Evidence of Longevity
This doesn't appear to be a minor blip. Based on my logs and external reports:
Reddit reports suggest this behavior has been ongoing for ~7 days.
Forum metadata suggests origin server instability dating back to at least 2/11/26.
This renders automation tools like ARM (Automatic Ripping Machine) or MakeMKV-Auto-Rip completely non-functional as they cannot bypass the network-induced hang.
Potential Workaround/Ask
Manually injecting a verified 2MB sdf.bin into ~/.MakeMKV or _private_data.tar did not resolve the issue for me on 1.18.3; the binary still insisted on the "SDF auto" network check.
Is there a way to force the Linux binary into a "Strictly Offline" mode that honors local SDF files and the Beta key without the ident handshake? Or is 1.17.7 the only path forward until the origin server is restored?