EOS M Alpha shutter-bug discussion

[santeri]

Any news regarding the issue? Since there's been no replies for a good while I assume not, but as an EOS M owner myself too, I'd of course like to see this get solved. I would love to have focus peaking!

It seems weird that the bug appears also when TL is not loaded but the loader is used to fire up canon's code. The thing that with the 11-22mm objective fully extended always manifests the problem and fully retracted (storage position) doesn't, tells it very likely has something to do with the lens initialization and it might be very sensitive to timing at the first power on of the camera. I assume with the 11-22mm it's almost the same there was no lens installed if it's retracted.

How much does the configuration with minimal autoexec.bin add to the startup time? How long does it take from the power-on to the jump to canon code with TL versus without TL?

Could it be just that Canon's code works with pure chance, the code is just magically waiting at the correct location / done some required initializations if only clean Canon firmware is used? When TL adds a bit of code to the startup, the lens has done it's own stuff before Canon's code reaches some point it should've been at a few milliseconds before and thus won't work.

I might possibly find the answer to the next question by searching a bit, but I'm just going to ask.. Is the power to the objective hardwired or can it be controlled from the software? Could the objective power on command (or some other thing that tells the lens it is attached) be removed from the startup of Canon firmware and make TL command it after everything else has loaded properly?


Edit: Just an idea, if the above would be true, it could mean that with clean firmware, no TL, the bug could be reproduced by having the lens a bit loose, powering on, and very quickly (almost simultaneously) turning the lens so it gets contact. Could be almost impossible to get the timing right of course..

[Malakai]

Any news regarding the issue? Since there's been no replies for a good while I assume not, but as an EOS M owner myself too, I'd of course like to see this get solved. I would love to have focus peaking!

It seems weird that the bug appears also when TL is not loaded but the loader is used to fire up canon's code. The thing that with the 11-22mm objective fully extended always manifests the problem and fully retracted (storage position) doesn't, tells it very likely has something to do with the lens initialization and it might be very sensitive to timing at the first power on of the camera. I assume with the 11-22mm it's almost the same there was no lens installed if it's retracted.

How much does the configuration with minimal autoexec.bin add to the startup time? How long does it take from the power-on to the jump to canon code with TL versus without TL?

Could it be just that Canon's code works with pure chance, the code is just magically waiting at the correct location / done some required initializations if only clean Canon firmware is used? When TL adds a bit of code to the startup, the lens has done it's own stuff before Canon's code reaches some point it should've been at a few milliseconds before and thus won't work.

I might possibly find the answer to the next question by searching a bit, but I'm just going to ask.. Is the power to the objective hardwired or can it be controlled from the software? Could the objective power on command (or some other thing that tells the lens it is attached) be removed from the startup of Canon firmware and make TL command it after everything else has loaded properly?


Edit: Just an idea, if the above would be true, it could mean that with clean firmware, no TL, the bug could be reproduced by having the lens a bit loose, powering on, and very quickly (almost simultaneously) turning the lens so it gets contact. Could be almost impossible to get the timing right of course..

From testing it appears the bug is more to do with the SD Card.

[santeri]

From testing it appears the bug is more to do with the SD Card.

The cases seemed mostly random, I didn't understand the issues with SD's. The only test that I see reproducing it every time in this thread so far is the 11-22mm objective. I don't own one, but if that is true, it would be easier to debug even if the problem had nothing to do with the objective but it just makes it happen.

[Malakai]

I can repeat the bug over and over on one SD card with both IS lenses but there is no bug for either lens when I use a different SD card. I switched to using the SD card without the bug even though its just a 8gb card.

[santeri]

Oh, okay. That just about nullifies everything I thought then, it can't be a timing issue related to the objective. If it was some SD cards being slow to start up or something, would guess the bug would appear with clean firmware then too and it clearly doesn't.

[gary2013]

The cases seemed mostly random, I didn't understand the issues with SD's. The only test that I see reproducing it every time in this thread so far is the 11-22mm objective. I don't own one, but if that is true, it would be easier to debug even if the problem had nothing to do with the objective but it just makes it happen.

it was mostly the 18-55 efm lens. But I also had it happen on the kit 22mm efm at one point. i now just run the canon reformat in camera with keeping the ML  files and the shutterbug goes away for me. I get the bug back when I install the ML nightly builds instead of the TL builds. But that reformat gets rid of it.

[ricsi]

I am a completely new user.
Bought my EOS M 2 days ago.
Installed Magic Lantern nightly from the 11th of january.
The bug bit me quit early!

So I now have it. As usual twisting the lens cures it until the next boot cycle.
I have tried with 2 SD Cards A-Data and fake no-name.
Both show the same behaviour.

Interestingly when I twist the lens, it WILL make a photo!
So it seems as if it was waiting for something, breaking the contact with the lens-lines clears that, and it snaps a photo, and starts working.
Also taking a video, and WHILE the video is recording, switch the dial to photo will work!

I have never attache the USB cable, so no dependence to this.

PS: I am a new to ML, so I downloaded the nightly and copied it over.
There was no FIR file in the EOSM 2.02 archive, so I googled it and found a 41KB file that seems to work. (Why is it not in the nightly archive?)
Then it complained about ml/data/fonts.dat not being readable, so I DL ML stabel 2.3 and copied it over, then added eosm_202.fir + nightly files.
Seems to work OK now, except for the shutter bug.
Did I do something wrong?

Now to the task of getting to know the EOS M canon FW + ML extensions

Thanx for your hard work, and if I can contribute any info on this bug I will, just ask what you need.

edit: 18-55 EF-M Zoom lense used.

PS: Any special support for PQI Aircard/Transcend WiFi SD??
I like those ... being root on your own SD card is somehow nice!

edit2: Latest 2 nightlies are broken and could not be compiled pn eos m.

[scottfrey]

My EOS-M arrives tomorrow, so I am getting ready. In preparation, I have have read through this and the entire 96 pages of the Tragic Lantern for EOS M thread. I am in no way a programmer, but I am a professional troubleshooter (i.e. computer consultant).

What jumps out at me from this thread is that there is no good data on the problem. There seems to be a trend that points to the biggest culprit being the SD card, with some other variables contributing (I love multiple trigger-point problems). What don't have is a statistically significant dataset.

I have two questions for those who have encountered the bug.

1) What brand and model cards have been tied to the bug?

2) Did you use EOScard or Macboot to set the flags?  (which would depend on Mac or PC or Virtual Machine) Are there other choices?

There are vast differences between brands of cards, plus the industry is awash with counterfeiting. There could be a significant difference in how cards behave and between read speeds.

EOScard or Macboot (or both) could have a bug or simply a difference in how they set the flags. I know from experience that there are places that can be written to on a drive that reformatting will not touch.

It would be helpful to narrow down or eliminate this variable (say, the problem goes away with Sandisk Extreme cards, for example)

I will be using a 16GB Sandisk Extreme 45MB/sec card (that came with my 6D). I'll report back

(edited for typos)

[gary2013]

My EOS-M arrives tomorrow, so I am getting ready. In preparation, I have have read through this and the entire 96 pages of the Tragic Lantern for EOS M thread. I am in no way a programmer, but I am a professional troubleshooter (i.e. computer consultant).

What jumps out at me from this thread is that there is no good data on the problem. There seems to be a trend that points to the biggest culprit being the SD card, with some other variables contributing (I love multiple trigger-point problems). What don't have is a statistically significant dataset.

I have two questions for those who have encountered the bug.

1) What brand and model cards have been tied to the bug?

2) Did you use EOScard or Macboot to set the flags?  (which would depend on Mac or PC or Virtual Machine) Are there other choices?

There are vast differences between brands of cards, plus the industry is awash with counterfeiting. There could be a significant difference in how cards behave and between read speeds.

EOScard or Macboot (or both) could have a bug or simply a difference in how they set the flags. I know from experience that there are places that can be written to on a drive that reformatting will not touch.

It would be helpful to narrow down or eliminate this variable (say, the problem goes away with Sandisk Extreme cards, for example)

I will be using a 16GB Sandisk Extreme 45MB/sec card (that came with my 6D). I'll report back

(edited for typos)

There is more than just one thread for EOS-M/TL. There is one just for the shutterbug and another one for the pink dot removal/PDR. Possibly more, but I don't remember at the moment. The shutterbug is not related to certain SDcards. It was random. That was the problem, it was all very random based and hard to nail down to a final fix. I have not seen any talk about the shutterbug for quite awhile. It is for sure related to the EFM STB lenses. As you probably read in all the posts, there are two ways to get rid of the shutterbug, but only for that session. When you reboot, it has reappeared and requires another lens twist or quick power off/on. My third way makes it go away all the time, but I lose the ability to use the EXFAT format. I do the internal Canon reformat/keep ML files and that formats it again back to FAT32. But it gets rid of the shutterbug for me. I have used Komputerbay 128GB card and I now use a Sandisk 32 GB/45 mb/s write card. I have seen on here other people using the Komputerbay cards. I have used eoscard and not used eoscard and it seems to not make a difference for me. I don't know for sure.

I think the shutterbug has something to do with ML/TL when it boots and how it talks to the lens since a lens twist off/on resets something and the bug goes away. Same for the quick power off/on. You do that before that LED flashes and the bug goes away. Something in ML/TL is happening at that time causing the bug. I am not sure why my way of using the Canon reformat gets rid of it. 

[scottfrey]

Malakai summed it up very nicely:

I have been thinking about this bug. Why some have it and some dont. I am swayed to think its something to do with the SD card. Looking at the variables. The camera body is virtually the same between users, so we should see the same results across all EOS M bodies. The same applies for the lenses. However the version of TL we use can be different per user. However most of us test for the bug using the same version. Some folk having the bug and some not having the bug. The one big variable is the SD cards we are using. Ill put money on it that if we all did a poll most of us would be using different cards.

Now, in the light of the fact that I have had this bug from day one and no version of TL or ML has managed to stop it happening. I used a brand new 8gb sandisk card straight from the packet and blam. Bug is non existent. I would say that after all the testing the bug lies with something to do with the SD card. If you experience the bug with either the 18-55 or the 11-22 try a different SD card with the same build. See if the bug goes away.

Admittedly, I have only the reports in this thread to go on, but from reading through this I have to respectfully disagree that "The shutterbug is not related to certain SDcards.", unless you have more data points to offer than I can find here (and you might).

For example, it could have to do with the timing of reading TL from the card at load time. When you format the card in camera, it may copy the files in a linear fashion (whereas your computer may not unless you copy one file at a time) and thus you have a repeatable read time. Difference cards have different read speeds. The same card written to different ways has different effective read speed. I believe one user had the bug without even having TL on the card, but i had previously been on the card (the card had the flags set, which may cause the camera to change it's timing by searching for autoexec.bin). Timig caused bugs are a bitch, and the SD read speed is the only real variable we can effect here.

I think the shutterbug has something to do with ML/TL when it boots and how it talks to the lens since a lens twist off/on resets something and the bug goes away.

Which could easily be the timing of when the firmware lodes and when it first reads the lens.

I'm not saying I'm right and you are wrong, I'm offering an observation as a fresh set of eyes. The data I am suggesting be collected may reveal a pattern

[a1ex]

@Malakai (or anyone else who can reproduce the bug consistently with the minimal autoexec or the minimal FIR):

Can you do a little table with the bug status in the following conditions?

Camera bootflag not set, card bootflag not set, boot from a formatted card => OK (running Canon firmware)
Camera bootflag not set, card bootflag not set, run minimal FIR => ?

Camera bootflag set, card bootflag not set, boot from a formatted card => ?
Camera bootflag set, card bootflag not set, run minimal FIR => ?

Camera bootflag set, card bootflag set, card without autoexec.bin present => lockup?
Camera bootflag set, card bootflag set, run minimal autoexec => bug present (confirmed by previous posts, but only for some users)
Camera bootflag set, card bootflag set, run minimal autoexec followed by minimal FIR => bug present, right? (just double-checking)

The answers to the two middle questions will be essential hints in narrowing down the issue.

Notes:
- to check the card bootflags, use EosCard
- to enable the camera bootflag, use the installation FIR and turn the mode dial until you get green screen
- to disable the camera bootflag, use the installation FIR and turn the mode dial until you get white screen
- the installation FIR might also change the card bootflags, so double-check with EosCard after running this FIR
- if you can't reproduce the bug consistently with the minimal binaries, do a few test runs (around 50) and write down the probability of getting the bug

[gary2013]

I do not recall that poll ever being taken. Most of us just replied with what we have tried for cards. If someone can prove it is the cards, then I think it is important to have many different people reproduce this fix. I can reproduce the problem right now just by reinstalling the fir file. I have used a Komputerbay 128GB, I think it was a 60 mb/s write. That was my first card. Then I bought a Sandisk 32 GB, 45 mbs write. I also have a Micro Center 32 GB 15 mbs card. None of them got rid of the bug.  I did try the minimal autoexec that Alex asked me to try/test back when, I think, Malakai said he had no bug with that minimal version. I reported that the bug still showed up.

I hope someone does come up with a real fix that satisfies all lenses (and cards) on the M. And, as an afterthought, make sure you try using the USB cable with your M to your computer at least once with installing some picture styles or/and transferring files to the computer hard drive. I think someone said they had no shutterbug and they never used the USB. Max said he never used the USB but also had the bug. Go figure. 1% and I had many discussions about the USB also causing the camera to hang and require a battery pull and he said he thinks that the USB problem is maybe somehow also causing the shutterbug or they are tied to some common thing. Nothing was ever resolved on those problems or theories.

[gary2013]

For example, it could have to do with the timing of reading TL from the card at load time. When you format the card in camera, it may copy the files in a linear fashion (whereas your computer may not unless you copy one file at a time) and thus you have a repeatable read time. Difference cards have different read speeds. The same card written to different ways has different effective read speed. I believe one user had the bug without even having TL on the card, but i had previously been on the card (the card had the flags set, which may cause the camera to change it's timing by searching for autoexec.bin). Timig caused bugs are a bitch, and the SD read speed is the only real variable we can effect here.

Which could easily be the timing of when the firmware lodes and when it first reads the lens.

Then why can I get rid of the bug just by performing another Canon format in camera keeping the ML files installed? Logic tells me the ML fir is doing something and the Canon reformat is fixing what was changed by ML. I don't think it is the read speed cus my Sandisk is above the average 37mb/s (some round it off at 40 mb/s write) the M camera can handle with read/write to any card. My card is 45 mb/s read and write, more than what the M can use.

[nanomad]

Gary, quick question....do you run the .fir every time you change a nightly build?

[gary2013]

Gary, quick question....do you run the .fir every time you change a nightly build?

no, if i did i would have to reformat every night to get rid of the shutterbug. I sometimes (not very often) try and do a full install from scratch.

[nanomad]

Ok one more question. When you do a reinstall, do you also disable any of the bootflags before? Camera or card or both

Lastly, can you do the tests suggested by Alex? They would help tremendously

[gary2013]

Ok one more question. When you do a reinstall, do you also disable any of the bootflags before? Camera or card or both

Lastly, can you do the tests suggested by Alex? They would help tremendously

I can try to do the tests. where do I get the minimal fir and minimal autoexc files? what do you or Alex suggest I do for starting out with my current sandisk 32gb card that has the latest TL and I did not use eoscard on it? I would guess a normal windows 7 format to clear it all? Anything else I need to do to start??
 

[nanomad]

They have been posted by Alex a few posts back