Testing some - perhaps many - cams with CHDKPTP - page 6 - General Discussion and Assistance - CHDK Forum

Testing some - perhaps many - cams with CHDKPTP

  • 65 Replies
  • 1357 Views
*

Offline koshy

  • *****
  • 912
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #50 on: 22 / September / 2019, 11:16:03 »
Advertisements
... so I re-tested i110 and the second time it crashed again

*

Offline koshy

  • *****
  • 912
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #51 on: 22 / September / 2019, 11:16:40 »
... tried a third time and it crashed once more

*

Offline koshy

  • *****
  • 912
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #52 on: 22 / September / 2019, 11:22:14 »
Finally, with stock trunk build, can you test the following on both ixus95 and ixus110
Code: [Select]
chdkptp -c -e='exec require"extras/msgtest".test{noscript=true,size=442357,sizeinc=512,count=600,verbose=0}'
That does not work.
Code: [Select]
connected: Canon DIGITAL IXUS 95 IS, max packet size 512
ERROR: unrecognized argument requireextras/msgtest.test{noscript=true,size=442357,sizeinc=512,count=600,verbose=0}'
ERROR: bad input ''exec'
Simple mishap I think, when reversing single and double quotes like so it works:
Code: [Select]
chdkptp -c -e"exec require'extras/msgtest'.test{noscript=true,size=442357,sizeinc=512,count=600,verbose=0}"
I did that with both cams using trunk build 5273 "tt" meant "trunk test"...

*

Offline koshy

  • *****
  • 912
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #53 on: 22 / September / 2019, 11:29:11 »
The result so far are confusing
Thanks for the summary. It's good to see you are keeping track of things. I thought maybe we should pause and regroup and see where things are at with half of the lot that were tested and you did that after a fashion. I'll go on as I find the time. There will be a slow down this week I think.

That's true, and would be good for other reasons too. Though OTOH in general, it's unreasonable to expect chdkptp file operations to always happen in temp
Don't worry I'll just keep the window closed. I'm not "expecting" anything from chdkptp - beyond the miraculous little things it does as is. You'll figure out if there is anything useful in the stray thought on temp folders. A stray thought was all it was...


*

Offline koshy

  • *****
  • 912
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #54 on: 22 / September / 2019, 12:40:25 »
Only when reviewing the i95 stuff I realized what just happened. No idea why it failed so badly before and then passed all tests just fine today. I would have guessed I had the wrong build but
Code: [Select]
platform:ixus95_sd1200-100c version:1.5.0-5272 built:Sep 18 2019 21:08:09in both cases and that's your test build alright... Anything to follow up on this or do we just file it under the smaller mysteries of the universe? I think I'll just test i95 again two or three times tomorrow or Tuesday...

*

Offline reyalp

  • ******
  • 12102
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #55 on: 22 / September / 2019, 13:35:11 »
That does not work.
...
Simple mishap I think, when reversing single and double quotes like so it works:
Oops, that's my fault. I test these things before I post them, but I generally use a msys shell and didn't think about quoting differences.

Thanks for the summary. It's good to see you are keeping track of things.
I have a giant spreadsheet, and the logs sorted into directory tree, and it's still hard to keep track of.

Quote
I thought maybe we should pause and regroup and see where things are at with half of the lot that were tested and you did that after a fashion. I'll go on as I find the time. There will be a slow down this week I think.
I was thinking about a pause too. If the i95/i110 issues need code changes, having the remaining tests on the final code would be better, and I have some other changes to do to support files larger than 2gb. But going slowly through more cams is OK too.

The other takeaway I didn't mention in the summary is that most of the ports work great :)

Quote
Only when reviewing the i95 stuff I realized what just happened. No idea why it failed so badly before and then passed all tests just fine today. I would have guessed I had the wrong build but
The underlying cause of these size specific issues seems to be bugs/quirks in the Canon USB layer so it wouldn't be totally surprising if it were intermittent or sensitive to timing or something. That might explain why I can't reproduce it on D10, but I have run the tests a bunch of times.

I'll need to think a bit about what next steps for testing. The fact one crashes and the other seems to stall is also weird.
Don't forget what the H stands for.

*

Offline koshy

  • *****
  • 912
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #56 on: 26 / September / 2019, 17:31:01 »
Quote
I think I'll just test i95 again two or three times tomorrow or Tuesday...
I figured that with no failures on i95 I'd batch test it until something interesting happened like this in a batch file

Code: [Select]
chdkptp -e"exec require'camtests'.runbatch{bench=true,xfersizebugs=true,shoot=true,filexfer=true}" > r_i95_07.txt 2>&1
@ping -n 10 localhost> nul
chdkptp -e"exec require'camtests'.runbatch{bench=true,xfersizebugs=true,shoot=true,filexfer=true}" > r_i95_08.txt 2>&1
@ping -n 10 localhost> nul

Well, the first interesting thing was that it never again completed all tests in the attepts I had. So reconnect failed and even after 10 seconds "sleep" via ping no way to re-connect. So, I'd edit the batch file, keep the run that completed and one subsequent connection failure, restart the camera an d started anew. On the fourth run the "interesting" happened and i95 crashed. So, I could get a Romlog after all and we now know that the crash is not exclusive to i110...

*

Offline reyalp

  • ******
  • 12102
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #57 on: 26 / September / 2019, 17:41:38 »
Well, the first interesting thing was that it never again completed all tests in the attepts I had. So reconnect failed and even after 10 seconds "sleep" via ping no way to re-connect.
FWIW, you could skip the reconnect test by editing lua/camtests.lua and changing
Code: [Select]
m.run('reconnect')
to
Code: [Select]
-- m.run('reconnect')
The reconnect issue seems like it's worth investigation too, but I'm not sure what to test at this point. It would be interesting to know if it happens without the USB extenders you are using.

You could also just run the test that triggers the crash
Code: [Select]
chdkptp -c -e"exec require'camtests'.run('xferbug_0x1f5')"
Don't forget what the H stands for.


*

Offline koshy

  • *****
  • 912
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #58 on: 26 / September / 2019, 18:15:35 »
The reconnect issue seems like it's worth investigation too, but I'm not sure what to test at this point. It would be interesting to know if it happens without the USB extenders you are using.
Did not unhook it all, so this is not the same USB 2.0 connector as before but a USB 3.0 on an additional card. The reconnect stuff did not occur in three complete tests. To speed up matters I then put in what you provided to see if anything crashes. Thus far it didn't in close to 20 runs. One interesting aspect is that I happened to have sound on and in the course of each use of your code test I got two "device plugged out" / "new device plugged in" kind of sounds in short sequence I'd otherwise get in the course of the reconnect test.

So, is all of this chasing ghosts or phrased differently did my special USB setup put me in the position to spot the xferbug_0x1f5 reported by others before in the first place? Well, maybe I should re-test with a direct hookup to the same USB 2.0 socket the extender would end up in... Another day though.

*

Offline koshy

  • *****
  • 912
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #59 on: 26 / September / 2019, 18:53:16 »
The unplug-replug device thing was odd but may be about the USB 3 connector. I have not used it in a while and I think there may have been something like one of the two being flaky. So curiosity got the better of me and I did try the same USB 2.0 connector the extender usually comes in on. No such sound. Still the 18 completions. Then about the reconnect thing, three runs (09-11), no problems.

OK, so via the USB Extender again (42/43) can't connect on the second run. Not going on right now, do we need aditional crashes / romlogs or is this good enough?

 

Related Topics