Remote shooting issues - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: [1] 2 3 4   Go Down

Remote shooting issues

  • 35 Replies
  • 14176 Views
*

Offline srsa_4c

  • ******
  • 4451
Remote shooting issues
« on: 04 / May / 2014, 18:08:53 »
Advertisements
It's time to open a separate thread for this feature.

There are various open issues affecting many ports which claim to have remote shooting support. Nafraf has created a table for easier overview: http://chdk.wikia.com/wiki/User:Nafraf/RemoteShootIssues

When we conducted the first remote shooting experiments, it looked like we can get away with stealing the fresh jpeg files without any major issues.
Recent bug reports indicate this is not always the case.
I suspect that cameras which crash or hang after a remote shooting session (after going back to play mode) may miss the physical files on the card.
I'm currently experimenting on DvlpSeqTask which seems to initiate things like creating a new "file object", starting JPEG development and saving the file. Unfortunately, the code is rather complicated. I'm currently thinking about modifying the file name inside that "file object" to point to an existing file on card - not sure if it's possible (or if I'll be able to find that "object" at all).

Another issue which makes remote shooting unusable on several cameras is discussed here and the followup posts - there's no complete solution yet.
Logged
*

Offline srsa_4c

  • ******
  • 4451
Re: Remote shooting issues
« Reply #1 on: 19 / July / 2014, 17:27:21 »
Quote from: srsa_4c on 04 / May / 2014, 18:08:53
I suspect that cameras which crash or hang after a remote shooting session (after going back to play mode) may miss the physical files on the card.
I may have found a workaround for this issue (based on my experiments on the a3200).
There is an event procedure named "PT_EraseAllFile". Its argument is a pointer to a callback function (if I'm not mistaken, it will be called when the operation is finished, only criteria is that it has to return 0). This eventproc locks up in playback mode, but succeeds in rec mode. If it's called after remote shooting (prior to returning to play mode), it clears all files and all file objects from the cam's memory. The eventproc is registered by SS.Create (on this cam), but it can be executed directly without registration.
Newest cameras don't have an eventproc with this name (didn't check for replacements yet).

The only problem with this is that it really clears all files known to the firmware (under DCIM/)
Logged
*

Offline koshy

  • *****
  • 1096
Re: Remote shooting issues
« Reply #2 on: 25 / July / 2014, 12:06:48 »
Quote from: srsa_4c on 19 / July / 2014, 17:27:21
The only problem with this is that it really clears all files known to the firmware (under DCIM/)
This might be a naive thought but here it is anyway...
Could you temporarily rename DCIM into TCIM or whatever on the card, fire the PT_EraseAllFile and after that rename the folder back?
Logged
Koshy had a little ELPH which wasn't white as snow but everywhere that Koshy went the ELPH was sure to go. (actually an SD, but that detail ruins the rhyme...)
*

Offline srsa_4c

  • ******
  • 4451
Re: Remote shooting issues
« Reply #3 on: 25 / July / 2014, 14:03:58 »
Quote from: koshy on 25 / July / 2014, 12:06:48
Could you temporarily rename DCIM into TCIM or whatever on the card, fire the PT_EraseAllFile and after that rename the folder back?
The idea is not bad, but the firmware's rename function may not work as expected on non-empty dirs (see for example this).

PT_EraseAllFile could work for those who only use the camera for remote shooting.
The ability to erase "camera objects" one by one would be better of course, but the related firmware code is too complicated for me.

Logged
*

Offline reyalp

  • ******
  • 14125
Re: Remote shooting issues
« Reply #4 on: 02 / August / 2014, 18:48:23 »
Spent some time looking at this on elph130, which does not have the PT_EraseAllFile eventproc or anything obviously related.

I started by logging the messages received by MetaCtg task in various situations. The message seems to be a structure and the code is fairly complicated, but I only ever saw a message sent when the camera was switch to play mode either by powering on, or after being in rec and in both cases it seemed to be identical. Shooting and deleting in the canon menu did not seem to send a message.

I decided to try making MetaCtg just consume the messages and ignore them. Unfortunately, different branches of the code may call GiveSemaphore on two semaphores associated with the task, depending on conditions I don't understand. In my hack, I just give both of them.

This code by itself would cause the camera to sit with the activity LED blinking after MetaCtg received a message. The camera isn't exactly hung, but if you try to switch to rec or shut down it really hangs, and you can't access the play UI. If you do click'menu' it shows "busy" for a second and doesn't show the play menu.

Looking at my camera logs from normal behavior, I tried posting the levents that appeared immediately after a MetaCtg message. Sure enough, posting 0x3220,0,0 makes the activity LED stop, and the camera seem to operate normally again. A hint for this was the fact the first two members of the message structure seem to be call backs that use PostLEvent (sub_FF0CE9C8 and FF0CD020). It's not clear to me where they would be called in the normal flow.

In the attached patch, calling set_skip_metactg(1) allows switching back to play after shooting with rs. I see "unknown image" for each of the shots taken with rs

This isn't a good solution, since it requires another task hook, and seems very likely to have adverse side effect. I haven't tested it exhaustively.

The message structure seems to look like
Code: [Select]
0x00 ff0ce9c8
0x04 ff0cd020
0x08 0000020d
0x0C 00000000
0x10 00000000
0x14 00000000
0x18 00000000
0x1c e1cd702c
but I'm not sure how big it is. Offset 0x14 is checked in the code, but it was always zero in my logs.

edit:
The original patch (-work-3) accidentally defaulted set_skip_metactg on. Updated.
« Last Edit: 02 / August / 2014, 21:28:26 by reyalp »
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: Remote shooting issues
« Reply #5 on: 02 / August / 2014, 19:57:30 »
Interesting.
The two callbacks are referenced right after "PB.S_Meta" gets logged to the camera log. The function that takes them as argument takes 0x41 as first argument (the letter 'A', returned by a function that is used to return the only drive letter that exists on the camera). Could be something like "search the drive for (new) meta-data".

Quote from: reyalp on 02 / August / 2014, 18:48:23
Spent some time looking at this on elph130, which does not have the PT_EraseAllFile eventproc or anything obviously related.
Oh, looks like I forgot about an important detail: That eventproc simply calls taskcreate_FileManMarkAllTask with certain parameters. I believe there still is an equivalent function in newer cameras, but it's no longer exported as eventproc: sub_ff416944 in your fw. It's referenced in one of the jumptables.
Logged
*

Offline reyalp

  • ******
  • 14125
Re: Remote shooting issues
« Reply #6 on: 02 / August / 2014, 20:50:55 »
Quote from: srsa_4c on 02 / August / 2014, 19:57:30
Interesting.
The two callbacks are referenced right after "PB.S_Meta" gets logged to the camera log. The function that takes them as argument takes 0x41 as first argument (the letter 'A', returned by a function that is used to return the only drive letter that exists on the camera). Could be something like "search the drive for (new) meta-data".
Yes, that eventually calls a function which calls PostMessageQueue to the MetaCtg queue

Quote
Oh, looks like I forgot about an important detail: That eventproc simply calls taskcreate_FileManMarkAllTask with certain parameters. I believe there still is an equivalent function in newer cameras, but it's no longer exported as eventproc: sub_ff416944 in your fw. It's referenced in one of the jumptables.
Thanks for that. taskcreate_FileManMarkAllTask also seems to take some callbacks that post levents.

From your description, it seems like there must be something in that process that gets rid of whatever file objects MetaCtg uses. Finding a way to that without actually deleting the files might be a viable approach.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: Remote shooting issues
« Reply #7 on: 03 / August / 2014, 13:42:36 »
Some more info on FileManMarkAllTask: it's called whenever image/video deletion is requested from the Playback menu. I haven't seen any input parameters carrying information about which files need to be gone, so the task has to figure that out somehow. I think that files selected for deletion carry a flag in their internal object descriptor.
Deletion of single images does not invoke the task.
Logged
*

Offline reyalp

  • ******
  • 14125
Re: Remote shooting issues
« Reply #8 on: 03 / August / 2014, 16:49:15 »
Quote from: srsa_4c on 03 / August / 2014, 13:42:36
Some more info on FileManMarkAllTask: it's called whenever image/video deletion is requested from the Playback menu. I haven't seen any input parameters carrying information about which files need to be gone, so the task has to figure that out somehow. I think that files selected for deletion carry a flag in their internal object descriptor.
Deletion of single images does not invoke the task.
A thought:
There's usually a shortcut for deleting an image in rec review immediately after shooting (press trash while still holding the shutter in non-continuous mode.) Testing on my D10, the image file is already written at this point. so it must remove whatever thing that trips up MetaCtg task when you switch to play.

If we could do the same thing for remoteshoot, that would seem ideal. I haven't looked for this code yet.
Logged
Don't forget what the H stands for.
*

Offline srsa_4c

  • ******
  • 4451
Re: Remote shooting issues
« Reply #9 on: 03 / August / 2014, 18:40:31 »
Quote from: reyalp on 03 / August / 2014, 16:49:15
There's usually a shortcut for deleting an image in rec review immediately after shooting (press trash while still holding the shutter in non-continuous mode.) Testing on my D10, the image file is already written at this point. so it must remove whatever thing that trips up MetaCtg task when you switch to play.
That brings up the same UI as pressing trash over an image in playback mode.
On the a3200 there are references to "SingleEraseController.c" which is UI code. I believe nearby CreateDialogBox call(s) are related to that UI. CreateDialogBox takes a function pointer as its third argument, which is likely the event handler procedure for the "dialog". In this case it's also very complex...
Logged
Pages: [1] 2 3 4   Go Up
« previous next »
 

Related Topics


SimplePortal © 2008-2014, SimplePortal