ML warns people about using ML at their own risk and possibly bricking a camera. So what is the difference there? A double standard?
There's a big difference between warning users to expect rough edges, and willfully keeping code that was proven to be dangerous.
Canon cameras have a design flaw in my opinion (
and not only mine): certain settings (properties) can be saved in the non-volatile memory without validation. I already wrote about it in the FAQ. Once you manage to save a wrong setting, the camera will show ERR70 even if you boot without ML. Semi-brick.
That's why you should be really careful when changing these properties.
Fortunately,
I know how to recover from many of these semi-bricks, especially if I know what setting was changed. I've semi-bricked my cameras with stupid mistakes, spent countless hours trying to figure out how to unbrick them, and I've started to understand what are the situations where Canon code may fail and how to minimize the probability of these things happening with public builds. I wrote some
low-level diagnostic tools and successfully unbricked quite a few cameras in the past.
Yes, people come to me or to g3gg0 to unbrick their cameras when something goes wrong.
I still have to learn how to flash back the firmware from a bricked camera (that's why I'm keeping the ROM backup code in ML builds - something that TL removed).
So yeah, keep ignoring my warnings (which I've learned the hard way by semi-bricking my own cameras) or challenging them with anecdotal evidence.
TL had a strong tendency of disabling the error message rather than fixing the actual cause of the problem. WAV recording is one of them: I wrote the memory backend to catch mistakes, it caught a severe bug in the wav recording code (writing to unallocated memory), and I have disabled the feature until a proper fix is found. What 1% did? He bypassed the memory backend, disabling the error message but keeping the bug.
Same for many other things that were my own code, I found them to be buggy (e.g. movie remap, sraw, dual iso preview) and disabled them. TL simply enabled them without actually fixing the issue I found.
Result: waaaa, Tragic Lantern has more features!!!Not to mention that bitrate adjustments and beep code from TL were implemented by removing the safety checks (assertions) from Canon code. These checks are there for a reason, and disabling them is something I don't agree with.
I have an engineering background, and I'm trying hard to build software that would not fall down when the
first woodpecker comes along.