Messages

After updating to the April build from a _much_ older build, I have found that my M doesn't retain movie crop mode on restart. This is kind of important, as one of my use cases is placing the camera where I cannot see the back of it and powering it up (on battery).

I have tried adding crop.enable = 1 to my config file but can't get it to work (everything else seems to work)

This is kind of a big problem for me. Any help?

I believe that the problem was that if you turn on crop mode then switching to a non ML card, you get stuck in crop mode for video. Yep--just tried it. Put camera in crop mode, remove the card, restart the camera and it stays in crop mode.

Would it be possible to turn off crop mode on shutdown then turn it back to the desired state from the configuration file on start up? Of course this wouldn't help if the camera crashes.

from https://www.magiclantern.fm/forum/index.php?topic=9741.msg175596#msg175596 in Dec 2016

Well, it has done 3 tests with erasing images rather than formatting and 2 with formatting and rebooting, all without fail. I also tried to make it fail on a 16GB fard (so not as long a vidoe) and have not been able to trigger the error, so it is either size of card or amount of video files related as well

I always reboot the camera after formatting, though.

and I never have (to be fair, i've never had any problems like this on any other cameras, or EOS M running on battery power either)

e.t.a.: It's entirely possible that the times that it has seemed to "randomly work" have been when the card is formatted at the end of the night (and the camera shut down) vs. when someone forgot and we format right before we start shooting. which intuition tells me is about the same percentage as having format problems. We could be on to something here.

1st test without reboot passed.

OK, disabling all four of those and still corrupting cards.

Is it possible that formatting the card (keep ML enabled) is somehow a cause? We habitually do that. I am going to run some sets without formatting

To clarify:

In this case, I'd say the main suspects are the 1.4 bitrate AND the 3x crop mode.

Do you mean running the combination of the two is most likely (as in either by themselves would be fine) or that either is EQUALLY likely to be the culprit?

OK, Diagnostics away to Apple Engineering.

Since the files seem fine and are viewable before shutdown, I am going to aim at your two shutdown suspects first as more likely.

If you think it has anything to do with shutdown, the suspects would be:
- ML config saving at shutdown (can be disabled)
- module unloading, or the module backend (to exclude both, check Debug->Modules debug->Disable all modules; simply not loading any modules is not enough)

Interesting about the modules, I don't use any, but had not disabled. I have now disabled modules under debug. I have disabled Config Files -> Config Autosave (assuming that is what you meant) and will run a series of 90 minute video tests and see if I can trip the corruption that way. At 90 minuted per test, it takes a long time to accumulate enough results to be confident of success at (roughly) 4 to 1 odds

I assume you are recording H.264, without any bitrate modification; correct? Can you also upload a screenshot of the Modified settings menu?

H.264, bit rate set to 1.4 (our compromise between quality and size). crop mode on or off (depending on lens used, it corrupted on one of each this last time), white balance to 3200K. I think those are all the movie settings (can't actually check right now)

It's a little time-consuming to test: the error doesn't happen when running plain Canon firmware, right?

Indeed, it is, as it only happens about 25% of the time, and only after recording at least an hour of video.

It does not happen with the same card on an M3 (one of our M's was down and I used an M3 to cover for a while, PITA, no AC adapter and needed to restart manually)

If it doesn't, I can prepare a test build, just with the movie restart functionality, to see if it helps. If you have a clear way to reproduce (maybe by leaving the cameras record overnight on the AC power?), we can narrow it down - it will take a long time, but this looks like bug that results in data loss - so I think it's worth the effort.

Let me test without bitrate mod and see if that has any effect. I am a bit delayed as I am waiting for response from Apple Engineering on why Disk Utility can no longer repair and I have a currently unreadable card. After that clears I'll see if I can get it to trip with Bit Rate at default.

I can even automate the testing process a bit - for example, record until card gets full, check if the files are readable, format the card and loop forever.

I doubt that would catch it. I have checked the files in play mode seen they are good, powered down and removed card and inserted it into a reader to find it corrupt. It really seems the act of powering down or removing the card is what triggers it.

Can you shed any insight on the FAQ point on ( http://wiki.magiclantern.fm/install ):

After opening the card door, always wait for LED confirmation (or for 5 seconds) before removing the card, even if your camera is turned off!!!

Which of course, with AC power, power is removed before opening the door. SO if there is any cleanup to be done, it won't be done as there is no power. Could whatever cleanup needs to be done be done with a manual process in ML? Is there a way to reboot back into Canon firmware without formatting or removing the card first?

I have been having an ongoing intermittent issue shooting long amounts of video on my EOS Ms

We run Ms to capture video of science lectures. Cameras are set up on AC power and run unattended with video restart enabled.

Every once in a while, maybe  out of four times a card will become unreadable after shooting 90 minutes of video. Everything appears fine in camera. Camera's are powered down (and wait for the lights to stop blinking before disconnecting power and opening the doors). This has happened across 3 different EOS Ms, four different cards, three different power adapters (both Canon and generic) and multiple versions of Magic Lantern (all the way back to Tragic Lantern). I have been unable duplicate the problem with a short amount of video. The cameras are always shut down cleanly, and wait at lease 5-10 seconds before opening the door

The problem is complicated by the fact that the only way to repair the card is in Mac OS X Diskutility. Simple repair and we have been putting up with it for a long time as it's trivial to repair. Until the most recent version of OS X (10.11) and it's new Disk Utility. Which will not repair it at all, and I have tried all sorts of ways. I have found nothing else that will repair the volume on these.

I found the following in the FAQ:

▪After opening the card door, always wait for LED confirmation (or for 5 seconds) before removing the card, even if your camera is turned off!!!
Right after opening the card door, Canon firmware accesses the card without turning on the LED (yes, with the main switch turned off). If you remove the card too early, the camera will freeze and will drain the battery, or even cause permanent damage! You will be running random code (remember you are loading executable code from the card), and we can't do anything about it without reflashing Canon firmware with our own code.

However, on the EOS M, the AC power plug goes through the door. You literally cannot open the door without removing power first.

Since it was a few seconds to fix, I hadn't been too concerned about it. However, now that it has become un-repairable, it's a bigger concern.

Any help would be appreciated.

There is now a firmware update (for European models anyway) for the M3. Is this helpful?

http://www.canon-europe.com/support/consumer_products/products/cameras/digital_slr/eos_m3.aspx?type=firmware&firmwaredetailid=tcm:13-1286211

M2 was an Asian-market-only product. Never hit shelfs in Europe or the Americas.

Correct. M3 OTOH, is a "whole world except North America" product. It's also easy to get ordering through Amazon.jp http://www.dpreview.com/forums/thread/3798686 or from any Canon dealer in Europe, Australia, etc. Including Africa: http://www.canon.co.za/for_home/product_finder/cameras/digital_slr/eos_m3/. Just not the Americas

Hopefully since the M3 appears to share a significant amount of tech with the new T6i we should get somewhere.  (same sensor, same digic6 processor, similar or same touchscreen)

I'm willing to try mine as a test bed, but I don't even know where to start compiling (I'm am not a coder, never coded anything more complex than HTML)

I'm also willing to try to get funding together for buying an M3 for a dev, if a dev is willing to commit to developing for it.

(I aslo assume its a non starter until we have a downloadable firmware rev for the M3 - correct?)

My M3 has arrived!

Knowing nothing, not even where to get started compiling, I would be willing to help get the ball rolling if someone can hold my hand on the test compile.

I would be ecstatic to just get movie restart mode, self timer and exposure bracketing working

Would it be possible to somehow shutdown the LCD screen (to save power) while shooting video?

Setting the Power Save feature to shut the screen off while shooting video does not work, the assumption being that you need to see what you are shooting I suppose. But if you are shooting on a tripod unattended, you don't.

Perhaps a manual keypress function? Set a timer? (even if you have to reboot the camera to get the screen back, it would be fine, as long as you can stop recording with the record button.

Thanks for being here!

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

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)