Tragic Lantern for 6D

[1%]

https://bitbucket.org/OtherOnePercent/tragic-lantern-6d


Modules should be ok unless you have some xtra symbols you added. Did you pull req them to main?

[Marsu42]

https://bitbucket.org/OtherOnePercent/tragic-lantern-6d

Thanks!

Modules should be ok unless you have some xtra symbols you added. Did you pull req them to main?

Yes, unfortunately my modules need some get functions for model-specific defines from the core. I once did a pull request and it was going nowhere, because where I put these functions (in a new file module-glue.c/.h) wasn't universally appreciated and I didn't have the enthusiasm to see this through.

Since then I keep mentioning that there is no commonly accepted solution what to do with model-specific variables and if these functions will be accepted into the core even if only one 3rd party module uses them... I hope once module mature this problem will be addressed.

[Marsu42]

One more question before I'll be bold enough to try to put this repo onto my new 6d (I cannot help but to ask): Is the 6d release as stable as the main dev trunk? i.e. were there any backend changes that affect stability other than plain feature porting?

I'm asking because some people just had a near death experience with the 60d - a recent trunk change introduced a memory bug that was only caught by ml's built-in safety net - see here: http://www.magiclantern.fm/forum/index.php?topic=8473.msg78027#msg78027 ... it's a bit like the old movie-remap which turned out to be brick-risky :-o

Is the potential of the Tragic Lantern repo to brick my camera larger than say the recent 5d3 builds? I have to admit I'm rather nervous here, I've been running ml on my 60D for 3 years even when the port was very fresh, but I don't want to use a port with known stability issues.

[a1ex]

As I'm currently in the middle of porting some changes from Tragic Lantern, here's my detailed code review, based on this diff (ML 4b3129d vs TL 7a5ccc6). I hope it answers the questions about safety and about the differences between TL and ML.

Cool stuff - this will get merged sooner or later

- various features (dual ISO, raw overlays, ResLock) ported
- stubs/consts updated
- advanced HDR video updated for new menus
- installer fix for new cameras
- FPS timer tweaks
- bracketing prefix (this is my code, I just didn't fully test it)
- some little bugs caught (e.g. EOS M menu not working while recording, or debug messages forgotten in the Protect/Rate shortcut)
- EOS M updated to 2.0.2
- 50D FPS warning

Major concerns:

- In many places, Canon error checking code is disabled (examples: beep.c or bitrate-6d.c, especially the second one). This is a no-no for me, and it's like running with a bike downhill at full speed without brakes. Just try understanding that code if you don't believe me.

- ROM backup (which g3gg0 created so we can unbrick the cameras if something really bad happens) is commented out:

Code: [Select]

+#undef CONFIG_AUTOBACKUP_ROM //WTF, Batman?

Okay, I know we never actually used this, but who knows?

- The stability tests from ML (which I wrote, and ran them hundreds of times), were disabled without reason:

Code: [Select]

+#undef CONFIG_STRESS_TEST // Not Needed

- Movie mode remap (which I know it's dangerous, because I've soft-bricked my 60D with it) it's enabled here.

- GUI timers are completely disabled (FEATURE_TIMER_HACK). I'm OK with slowing down the refresh rate, but completely disabling them isn't safe IMO.

- Some debug tools that I consider dangerous and were written for developers only (DIGIC poke, prop browser, dm/tp intercept) are enabled in TL builds (so users without proper knowledge have access to these tools, and they shouldn't IMO).

- Picture quality hacks (SRAW, MRAW) are included. I've bricked my 5D2 with wrong picture quality settings (ERR70 even without ML). I've unbricked it successfully.

- Error handling in bitrate code is done by rebooting the camera in the middle of recording!

Minor concerns

- raw_rec also records in photo mode (it shouldn't)
- boot methods changed (any reason?) [OT: remember the early days of 6D when ML was running without even allocating memory for it?]
- no checks before patching Canon code
- code changes are very hard to follow (very short commit messages, often the commit alters totally unrelated stuff, changes that do nothing but add commented code)
- ML warnings are disabled (hint: some people are under the impression that Tragic Lantern is actually a stable release):

Code: [Select]

+#define FEATURE_NOHELP //No one can help you now

Neutral

- some more things optimized with -O3 (can anyone show the difference, maybe with a video?)
- new peaking (I feel it's too slow, and the bug reports I've received from 5D3 alpha were enough for me to disable it until the code will be optimized)
- dma_memcpy
- uniwb (my old code, nothing wrong with it, it was useful when we didn't have raw histogram, but now it's no longer needed)
- REC_ON_RESUME and MOVIE_AUTOSTOP_RECORDING: these should be done with scripting (yeah, I know, somebody should revive the scripting engine first)

Not reviewed (some of these things are cool, but I just didn't take a closer look):

- video hacks
- feature additions to raw_rec
- mlv_rec (it's on the todo list, but it's very complex)
- audio
- QEMU changes
- a lot of stuff in debug.c that is impossible to understand

Conclusion: personally I'm afraid to run Tragic Lantern on any of my cameras. Sure, I don't remember anyone bricking his camera with TL code, but I've learned about some dangerous things the hard way, by bricking my own cameras (and then learning how unbricking them). Of course, you should not trust me blindly, you should review the code on your own (even the code from the main repo).

Sorry if I sound like bashing or underestimating the contributions from 1%. I've just tried to do an objective review of Tragic Lantern, especially regarding code safety, and I've tried to back every argument with a link or a code snippet. These are the main reasons TL code didn't get merged into main repo; I've pointed them out many times, but the issues were not solved, so a little reminder shouldn't hurt.

Now, I have to admit I don't have a better solution. The main repo for 6D (and other cameras, e.g. EOS M) was not touched for months, so it's completely untested. I can't help with that, because I don't own these cameras, and I already have too many of them). I just want people follow some really basic development guidelines, and submit their changes to the main repository, where they will be subject to code review from me, g3gg0, nanomad and many others - both devs and nondevs). Now, the entire 6D/EOSM/7D development is done in a fork where the core ML developers have absolutely no influence, and most people are not aware of that.

[1%]

- The stability tests from ML (which I wrote, and ran them hundreds of times), were disabled without reason:

After completing the test successfully, why keep it. Just added bloat.

- Movie mode remap (which I know it's dangerous, because I've soft-bricked my 60D with it) it's enabled here.

Only useful on 600D, other cameras its pointless. i.e Softbricked 60D. 50D the modes don't support LV.

ML warnings are disabled (hint: some people are under the impression that Tragic Lantern is actually a stable release):

I'd tried running with the warning it just got too naggy. I don't need to be reminded with popups every day. And what is the solution? Not use ML? The only one without is technically 2.3

CONFIG_AUTOBACKUP_ROM

The files it produces are not a great backup on many cameras, some parts of the rom are doubled.
DIGICV/IV have different addresses. I wouldn't flash this stuff back.

Picture quality hacks (SRAW, MRAW) are included. I've bricked my 5D2 with wrong picture quality settings (ERR70 even without ML). I've unbricked it successfully.

It only has these modes on 600D. Other cameras either have SRAW/MRAW or it just doesn't work.

boot methods changed (any reason?) [OT: remember the early days of 6D when ML was running without even allocating memory for it?]

The reason was 640K bins... EOSM/6D are the main changed boot deals. 5DIII is lucky with the giant malloc. They are already booting with cache hacks, just with bigger bin space.

no checks before patching Canon code

A BL isn't going to change, nor is the position in rom. Its ifdefed to only run on the camera it belongs too.

- Error handling in bitrate code is done by rebooting the camera in the middle of recording!

That error is funny, resource manager doesn't want to start recording and leaves the camera in a "busy" state where the only other option is a battery pull. You're not in the middle of recording anything, it doesn't write anything but a blank dat file. Usually its from pressing rec too fast before the config fully loads. I kinda want to find this one and fix it.

- uniwb (my old code, nothing wrong with it, it was useful when we didn't have raw histogram, but now it's no longer needed)

Uniwb for video, esp raw video is nice. Leaves the WB for post but you still get to see some of the color in your image.

- code changes are very hard to follow (very short commit messages, often the commit alters totally unrelated stuff, changes that do nothing but add commented code)

Thats just testing stuff from things I tried, more or less notes for me. Same for debug.c, its just reverse engineering testing.

but completely disabling them isn't safe IMO.

The worst it does is graphical glitches. Saves 50D/7D/5d2? silent pic bursts, otherwise you get massive pink frames.

+#define FEATURE_NOHELP //No one can help you now

Yep, ripped out the help system, the instructions aren't updated and you get a nice 10kb or so of bloat.

Now, the entire 6D/EOSM/7D development is done in a fork where the core ML developers have absolutely no influence, and most people are not aware of that.

There are some things which would benefit from code review... ie a clean fix for audio IC read/write on digic V where a better coder would have an easier time fixing the warnings.

beep.c

No wav without patching out the state machine. On EOSM this doesn't work. Canon really didn't want asif use on digic V. I guess they don't want a camera that doubles as an audio recorder. They're touchy about the audio monitoring too.
 

I have to admit I'm rather nervous here, I've been running ml on my 60D for 3 years even when the port was very fresh, but I don't want to use a port with known stability issues.

I don't just write stuff that will brick your camera wily nily, I try it on the one here first. So far haven't had a single brick. The biggest danger is crashes but people have been running it on their pro shoots and not having too many issues or they would have complained loudly by now. Only thing thus far have been crashes or user error. Thats why I say test it first before you go and depend on it. Main hasn't been perfect with this either.

[nandoide]

Well 1%, alex.  As an user, I've been compiling and intensively using the magic lantern unified branch for 550D, and the tragic lantern branch for 6D for a lot of months, and I only can say that stability never be an issue in none of them. It's indeed astonishing, because of continuous changes on the code that arised almost every day, and the reverse engineering nature of designs.

Risks, if there are, were primarily related to my own experiments with the code :-(

What I believe is that it's a pity, the fact that there are not a consensus between you two, to unify the two branches. Perhaps you need to accept the point of view of the other in some items, a posible way for that it's refactoring some things in 6D as modules (birate...?), I don't know but I think it will be a great benefit for the project.

I want to encourage you to reach that consensus.

Whatever happens, I have only thanks to both of you and all the team of developers and testers.

[Marsu42]

I don't just write stuff that will brick your camera wily nily, I try it on the one here first. So far haven't had a single brick.

Not to be misunderstood: I wasn't implying you don't test your fork, not at all! My curiosity was just based on seeing that your 6d repo has moved further away from main as I expected, at first I thought it'd be just the usual number of test commits that are regularly dispatched to main - thus the question about the stability, it's marked as "dev kit" after all.

I cannot comment on the dev specifics, but I'd also suggest to enable the ml warnings in the binary releases you distribute to avoid confusion about the dev state - personally I also disable them in my local compile because I know I'm compiling trunk, and so can you on your own camera?

What I believe is that it's a pity, the fact that there are not a consensus between you two, to unify the two branches. [...] I want to encourage you to reach that consensus.

I can only concur, forking is great and the basis of distributed sources, but the main focus should lie on re-merging changes to be able to get one trunk... wherever that is. Until I looked closely, I didn't realize the main 6d code is outdated, currently it's even completely broken.

The specific list of issues seems like a great way to sort out concerns, either in this thread or via pm - I'm always willing to listen to alex since he has so much experience with the code, but I am happy to see 1% is also putting a lot of thought into this - that's because imho the most important thing is never to brick cameras, though of course crashes are to be expected and can be fixed by removing the battery, I'm used to this :-) ... don't forget the main fud with ml out there seems to be that it's a "hack" and "dangerous", so no need to feed this misinformation.

Also, if there should be any hierarchy problems like who has access to what and who gets to decide what the only way to solve this is to openly discuss any concerns, either the dev group or with all users, I'm absolutely sure we're all on the same side here. So I'm eager to see how the 6d development progresses, looking at the popularity of the 6d it's a very important platform for the continued success of ml!

[1%]

but I'd also suggest to enable the ml warnings in the binary releases you distribute to avoid confusion about the dev state - personally I also disable them in my local compile because I know I'm compiling trunk, and so can you on your own camera?

You turn them off... so does everyone else who compiles. I see no need to nag users who read the guides on how to get it working and know the implications of rolling release. The L.C.D will not read any warnings, they don't even read instructions. I see them as valid if the downloads were on the main page but they are in the forums so I'm assuming they are *somewhat* familiar with ML and everything else. I can see the warning coming up once on first run, that would be OK, but it comes up way too much. Nobody needs to be reminded every day or every few power ons or worse yet have a shot blocked/hindered by the popup. I run the same exact thing I release (+/- some commits), for photos it really needs to be up and running quickly or the shot is gone and frowns all around.

Why punish the users while disabling it for yourself? Because they didn't want to download a few 100MB of toolchain to obtain 2MB of binary?

Would you want your linux distro to do this every start up or every update? I've seen those updates down production servers. People who rolled them out without looking were sorry afterwards and never did it again without testing. Basic computer stuff.

Everything since 2.3 has been tested in place, one would hope until 2.4 people will understand rolling release didn't get the same 100s of hours of testing that a full stable release did.

[a1ex]

The main issue here is that development takes place in a fork that went far away from the mainline, without any code review, and people have no idea what they are running on their cameras. Of course, it stays up to date with the mainline (and that's a good thing), but the reverse doesn't happen (so the knowledge is shared mostly one way, and it's supposed to happen in both directions).

Normally, fork authors submit their changes to mainline via pull request, we review them, point out stuff that can be improved, and merge them. Here I've tried to import the changes from 1% a few times, but it's a lot of work because of huge diff and changes difficult to follow, and there are major technical issues in the code, as I've pointed out earlier.

Now, the nitpicks:
- stability test: the backend is changing, so these tests may point out some problems that are hard to notice in actual usage
- remap: if it worked for you, but not for me, it doesn't mean it's safe to use; you are creating a mix of movie mode with settings from the mode you come from, and that mix is out of control.
- ROM backup: can you show a specific example where they are wrong? Covering a 8MB ROM twice isn't a problem, it's just for code simplicity (one size fits all).
- checks before patching: you have so many of them in the code that it's impossible to tell if all of them are correct or not. What I'm telling you is to let the computer catch your mistakes. It's also for other people that may play with your code. I did a single code patch in raw_rec, and the checking code was triggered (there's a screenshot in the 7D thread).
- error handling: I'd rather print something like take the battery out. Properties are a touchy area, as you know.
- help: if the instruction are not updated, why not update them, instead of removing them completely?
- beep: I'm sure we can find a cleaner solution.

About code safety: of course, things working on your camera it's a good thing, and nobody denied it. But if some things can result in random code execution, even if the chances are like 0.001%, and I point them out, why refusing to do something about it? Instead, you are simply dismissing my remarks.

A recent example: I've asked you to run some test code on 50D, because FIO code stopping in the middle of reading a file is a major issue IMO (it's likely to indicate a bug somewhere else), and you dismissed it with "I don't care". Enough said.

Don't forget that we are running without a MMU unit, so a mistake in our code can overwrite Canon code or data structures. The reverse is also true - g3gg0 and me have patched a Canon bug that was overwriting ML code on many cameras. So, a little extra care doesn't hurt.

Regarding warning: of course, a lot people don't read instructions, as you said, and this is why they should get something that is less likely to contain dangerous options. If they want some bleeding edge stuff (e.g. advanced bitrate control), and they understand the risks, you can point them to your fork. Maybe we can create a separate forum area for forks, so it no longer causes confusion.

But right now, the mainline development was abandoned, there was no attempt from you to merge your changes into mainline (I've been trying to do that myself, also nanomad, but we had difficulties), and people are running your fork thinking it's the mainline, while that fork contains stuff that I consider dangerous.

This is not nice.

[Marsu42]

I can see the warning coming up once on first run, that would be OK, but it comes up way too much.

Well, so there's your solution - just add a version tag to the config file and enable the warning only once per build!

Of course the warning is tiresome for a lot of users, but as in "better safe than sorry" and "We told you so" it's made for people who are pointed at the "How to install ML" thread from somewhere else & just skip all warnings like we ignore health warnings on our favorite food items :-p ... I also directed people to the forum to the 6d port because I knew it was more mature than other early ports, but there still should be a difference to a "stable" version. But I think the one-time warning per trunk tag could be a consensus?

The main issue here is that development takes place in a fork that went far away from the mainline, without any code review, and people have no idea what they are running on their cameras. Of course, it stays up to date with the mainline (and that's a good thing), but the reverse doesn't happen (so the knowledge is shared mostly one way, and it's supposed to happen in both directions).

I don't want to get between people, but I can understand some frustration can be generated by such a situation if there is no timeline or understanding when a re-merge will happen and who has to sort out incompatibilities. The nitpicks alex mentioned seem to be not that many, and if he from his experiences thinks these are serious issues I don't see any reason for not enabling these safety measures, even if some other people think they're not necessary?

- stability test: the backend is changing, so these tests may point out some problems that are hard to notice in actual usage

Sounds reasonable to me...

- remap: if it worked for you, but not for me, it doesn't mean it's safe to use; you are creating a mix of movie
mode with settings from the mode you come from, and that mix is out of control.

I was very disappointed when alex pulled the "movie mode remap" feature from trunk, but in hindsight as a user I have to say I'm very happy he's that determined on catching every small bricking possibility.

- ROM backup: can you show a specific example where they are wrong? Covering a 8MB ROM twice isn't a problem, it's just for code simplicity (one size fits all).

Ok, 1% doesn't think it's actually working, but it doesn't hurt, so why not just enable it? This is about reaching an understanding, and this certainly doesn't seem to be a crucial point.

- checks before patching: you have so many of them in the code that it's impossible to tell if all of them are correct or not. What I'm telling you is to let the computer catch your mistakes. It's also for other people that may play with your code. I did a single code patch in raw_rec, and the checking code was triggered (there's a screenshot in the 7D thread).

Ok, this is a serious code architecture difference, I hope both a consensus can be reached here, I wouldn't want to comment right now. But this shouldn't be a reason for permanent forking.

- error handling: I'd rather print something like take the battery out. Properties are a touchy area, as you know.

Me too, even though I'm quick at taking the battery out by now :-p ... but back when I first started using ml I nearly had a heart attack every time if my very, very expensive dslr just froze.

- help: if the instruction are not updated, why not update them, instead of removing them completely?

Hmmyes, I have to admit since since there is no one around to update the help text, it probably doesn't matter to 404 all of them or remove them - when (and if :-p) someone is found to write the texts for the next "stable"  - if that should ever happen - re-patching them in won't be a probem?

This is esp. since there seems to be no schedule or idea about further ml "releases", are you going to branch a stable and only bugfix, will it be rolling releases only, or will it be the Linux model with a merge window and then bugfixing/testing only for a certain time? But of course this is an issue for another thread.

About code safety: of course, things working on your camera it's a good thing, and nobody denied it. But if some things can result in random code execution, even if the chances are like 0.001%, and I point them out, why refusing to do something about it?

I wouldn't know about probabilities, but when alex recently messed up the code I was very happy the error was caught rather than bricking my camera (or crashing it) - so +1 for safety nets, and publicity-wise ml bricking or freezing is very bad since this is what a lot of fud is about.

Maybe we can create a separate forum area for forks, so it no longer causes confusion.

I still am positive that you guys sort this out and a re-merge will happen in the near future! Meanwhile, if TL remains a fork and not just a branch in the main repo, to avoid confusion that doesn't sound like a bad idea so responsibilities are sorted out. I for one didn't realize there were any differences between the 6D port and the rest of ML I'm currently running on my good ol' 60d.

But right now, the mainline development was abandoned, there was no attempt from you to merge your changes into mainline (I've been trying to do that myself, also nanomad, but we had difficulties)

What I don't quite understand right now, maybe someone can enlighten me: How did this happen at all? Is TL intended as a real, permanent fork, or is the intention to first develop a complete 6d port and then re-merge, or was more often re-merging with trunk hindered by some problems?

Since this is GPL nobody can do anything about a (semi-)permanent fork, but without very good reasons this is always a pity and sub-optimal from a user's perspective in oss - as I'd be running *two* different ml distros on my cameras, ML on 60d and TL on 6D which makes putting my own patches into them very tiresome and makes it much more difficult to report bugs and test features.

[NikeFreak]

как установить [6D]Audio_Controls.zip, МЛ 1,1,3 уже установлена, это новое обновление нужно просто скопировать на флешку, или ее нужно прошить 6D000ML.FIR ?
how to establish [6D]Audio_Controls.zip, to ML 1,1,3 it is already established, this new updating needs to be copied simply on a flash card, or it needs to be stitched 6D000ML.FIR?

[Marsu42]

how to establish [6D]Audio_Controls.zip, to ML 1,1,3 it is already established, this new updating needs to be copied simply on a flash card, or it needs to be stitched 6D000ML.FIR?

The ML .fir is *only* required *once* to enable using ml at all - from then on, just copy the appropriate files, mainly autoexec.bin & the modules to the card.

[NikeFreak]

The ML .fir is *only* required *once* to enable using ml at all - from then on, just copy the appropriate files, mainly autoexec.bin & the modules to the card.

я это знаю, просто не понял зачем тогда положили в эту сборку fir файл.
I know it, simply didn't understand why then put in this assembly fir the file.

[1%]

Its there if someone is a first timer and needs to boot flag/remove the boot flag.

The movie remap on 600D was the reason for the fork. It was working great there and still is for 2 years. On everything else it mostly doesn't. Its not enabled on any other camera for that reason.

For help, you just comment out FEATURE_NOHELP and they're back.


I agree that stuff should be merged back, ie 7D display filters. Some stuff like that is easy to port back from the source. Some stuff like audio controls, yea, it would be harder to find all of the pieces.
TLDR: I need to figure out pull requests.

I do run the stability test every once in a while... I just don't put up bins with it enabled.

Main thing that keeps me from working on merging is that I port/build/test changes coming from main or work on something new instead. My programming is pretty simple, didn't think anything was hard to follow, esp for a more experienced coder.

- beep: I'm sure we can find a cleaner solution.

I hope so, it was meant to be a temporary thing and needs to be done for EOSM, that solution should work for 6D too. EOSM/650D will need it too since audio controls can now be done for it.

Instead, you are simply dismissing my remarks.

I'm not dismissing anything.  I just never got to it The flip side is when something is broken by main I also have try to figure it out with usually little help  ie. 7D master stuff right now or voice tags being broken... I didn't apply set unpress fix on 7D and its broken there right now

Covering a 8MB ROM twice isn't a problem, it's just for code simplicity (one size fits all).

Don't digic V and digic IV have the rom on different addresses? At the least rom1/rom0 are flipped at the worst its backing up garbage.

error handling: I'd rather print something like take the battery out. Properties are a touchy area, as you know.

True, I just did the reboot since nothing else worked, I can set it up the other way, its not a big problem for me (comment out one line), I want to solve the bug so it doesn't happen.

Maybe we can create a separate forum area for forks, so it no longer causes confusion.

I would hope they can figure this out, the name is different, you've explained it 100 times like this. Its not on the main page even. Some people still don't read.

This is not nice.

I'm not trying to be a pain in the ass. My main goal is to have working bins for these cameras that people enjoy.

[a1ex]

Just reproduced the voice tags bug, SET is getting trapped by the "moving spotmeter" feature. Will fix.

For bitrate error, if it's caused by loading the config file in the middle of recording, you could just skip loading it if you already started recording. If this is not enough, try locking the buttons (ui_lock) while loading the config, so you can't start recording with incomplete configs.

[1%]

I added MSLEEPS, will try UI lock and see if it goes away.

Thanks, so far its gone, knock on wood.

[Marsu42]

Ok, since with my new 6D I again discovered how unusable the camera is w/o ml, I boldly put 1%'s port on it, and (knock on wood) everything works fine so far - apart from one crash and some assert logs, that is. But thanks a lot all for making this work on the 6D, ml being not available prevented me from buying it earlier.

Question 1: Where do I post bug reports for the 6D: In the main repo bugtracker or on 1%'s bitbucket repo?

Question 2: 6D related feature requests still go into the Magic Lantern forum, even though the work is currently being done in the Tragic Lantern fork?

[1%]

apart from one crash and some assert logs, that is

You can post bug reports here or in the repo for it. What crash tho?

[Marsu42]

You can post bug reports here or in the repo for it. What crash tho?

I deleted the crash log, sorry - it was in raw.c and had something to do with me trying raw ettr & raw_rec - I'll try harder next time to give a proper report

[a1ex]

I had some assert logs with ETTR on 5D3 (I know I had it on SET button in LiveView), but I couldn't reproduce them. So, if you get these errors again, I'm interested.

[1%]

The too many requests for raw_lv error? That is what asserts with ETTR... I thought that bug was gone

[a1ex]

Yeah, that one. How to get it?

[1%]

For me it happened on cold boots, hitting set for it to go into live view. It opens/closes real quick and gives up/asserts.

Code: [Select]

ML ASSERT:
raw_lv_request_count >= 0
at ../../src/raw.c:1368 (raw_lv_release), task livev_hiprio_task
lv:0 mode:3


Magic Lantern version : v2.3.NEXT.2013Sep24.6D113
Mercurial changeset   : 18cfee2de867+ (unified) tip
Built on 2013-09-24 16:55:44 UTC by user@D610.
Free Memory  : 380K + 1828K

Cold boot half shutter double click, almost every time.

Narrowed it down, if AF is on and it afs a little then you get the error.

[a1ex]

Nope, still can't reproduce (5D3, 50/1.8, M, AF on halfshutter, ETTR with SET or halfshutter double-click, cold boot, all fine).

Just merged some changes from TL into mainline. It's still work in progress, as I've merged mostly the easy part (what was pretty obvious). Will continue tomorrow.

I've updated the official nightly builds too (but didn't try them, obviously). Can you check if it actually works?

[1%]

Nightly is working and not doing anything bad. I think audio remote shot might not be working because audio controls aren't in.

You think a DM log would help? I can log and wait for a couple of the asserts ( i see them flash the LED).