Testing some - perhaps many - cams with CHDKPTP - page 7 - General Discussion and Assistance - CHDK Forum
« previous next »
Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 13   Go Down

Testing some - perhaps many - cams with CHDKPTP

  • 122 Replies
  • 71006 Views
*

Offline reyalp

  • ******
  • 14079
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #60 on: 26 / September / 2019, 22:55:06 »
Advertisements
Quote from: koshy on 26 / September / 2019, 18:15:35
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.
I think this is normal. The code inherited from ptpcam does a USB device reset on disconnect, which makes windows do that sound (among other things). I've been meaning to remove this or make it an optional setting, but haven't got around to it.

Quote
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?
The original xferbug_0x1f5 is fixed (on my cams, at least), with code that is enabled for all platforms. It's unclear if the bug you are seeing is triggered specifically by the 0x1f5 size pattern, or just happens to fail that test for other reasons.

Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14079
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #61 on: 27 / September / 2019, 02:49:09 »
Quote from: koshy on 26 / September / 2019, 18:53:16
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?
So if I understand correctly: USB 3, and USB 2 without extender both did not trigger the 0x1f5 crash, or the reconnect bug? And with the extender has them somewhat often?

It might be worth trying ixus110 on direct connection too.
Logged
Don't forget what the H stands for.
*

Offline koshy

  • *****
  • 1096
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #62 on: 29 / September / 2019, 20:16:35 »
Quote from: reyalp on 27 / September / 2019, 02:49:09
It might be worth trying ixus110 on direct connection too.
Turns out the convenience of not doing it with any other hardware but one of my main workstations made a mess of this. Sorry for that. Only got around to do the i110 tests today and on the direct USB 3 hook up there are no crashes with it either.

That rules out the extended USB hookup in its current shape for future tests. What cams shall be re-tested from the ones we already looked at?
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 reyalp

  • ******
  • 14079
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #63 on: 29 / September / 2019, 21:22:44 »
Quote from: koshy on 29 / September / 2019, 20:16:35
Turns out the convenience of not doing it with any other hardware but one of my main workstations made a mess of this. Sorry for that. Only got around to do the i110 tests today and on the direct USB 3 hook up there are no crashes with it either.
It's OK, we learned some things. It's interesting that these models appear to be particularly sensitive to whatever the issues with the extender are.
Also, if you happen to know the brand/model of the extender, that would be good to note for future reference. CHDK gets used in weird applications where others might want to use this sort of thing.

I noticed the 'rec' test failed in the logs, causing all the shooting tests not to run. If you connect to the camera manually and use rec, does that also fail?

Quote
That rules out the extended USB hookup in its current shape for future tests. What cams shall be re-tested from the ones we already looked at?
The only one that comes to mind is ixus200_sd980, using a trunk build (not the test build I posted earlier)

This camera failed the bug 0x1f5 test with the trunk build, which was apparently fixed by enabling the bug 0x23f4 fix.

I think the ones that passed or had issues on reconnect don't need to be re-tested.
Logged
Don't forget what the H stands for.
*

Offline reyalp

  • ******
  • 14079
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #64 on: 02 / October / 2019, 01:11:00 »
Here's a build for ixus30_sd200, to test a workaround for very old vxworks cameras like this which fail on sizes of exactly 52 bytes.
Logged
Don't forget what the H stands for.
*

Offline koshy

  • *****
  • 1096
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #65 on: 10 / October / 2019, 08:02:01 »
Something came up for the past week and now I'll be traveling for 10 days. I'll resume this work upon my return on the 21st. Generally where I left off was being puzzped that the shooting routines did not get actuated in direct hookups. I dug out an unused Samsung NC10 netbook, put a Win XP on it and intend to use its USB 2.0 for subsequent tests. It's small enough to stay on the desk for a few weeks...

Thanks for the Ixus30 build, looking forwards to trying it.
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 koshy

  • *****
  • 1096
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #66 on: 28 / October / 2019, 20:53:39 »
I was back a bit later than I thought but things eventually return to normal. So, where were we?
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 koshy

  • *****
  • 1096
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #67 on: 30 / October / 2019, 11:56:41 »
Quote from: reyalp on 29 / September / 2019, 21:22:44
Quote
What cams shall be re-tested from the ones we already looked at?
The only one that comes to mind is ixus200_sd980, using a trunk build (not the test build I posted earlier)
This camera failed the bug 0x1f5 test with the trunk build, which was apparently fixed by enabling the bug 0x23f4 fix.
This turned out to be interesting. This is the first test done on the Samsung NC10 Win XP with plain vanilla USB 2.0 ports test system I now have on my desk. All subsequent posts will be from that one unless specifically marked otherwise. What happened was there was no problem. Just forcing the issue by looping the test did lead to a crash eventually - on the 7th iteration. So, that it passes once does not seem to be generalizable...
« Last Edit: 30 / October / 2019, 18:21:12 by koshy »
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 koshy

  • *****
  • 1096
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #68 on: 30 / October / 2019, 11:57:37 »
Quote from: reyalp on 02 / October / 2019, 01:11:00
Here's a build for ixus30_sd200, to test a workaround for very old vxworks cameras like this which fail on sizes of exactly 52 bytes.
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 reyalp

  • ******
  • 14079
Re: Testing some - perhaps many - cams with CHDKPTP
« Reply #69 on: 02 / November / 2019, 23:07:39 »
Thanks for the additional tests.
Quote from: koshy on 30 / October / 2019, 11:56:41
This turned out to be interesting. This is the first test done on the Samsung NC10 Win XP with plain vanilla USB 2.0 ports test system I now have on my desk.
XP  :o I think it should fine, but I haven't tested anything on XP in many years and do not intend to support it.

FWIW, a Linux system (including raspberry pi) would be fine, and would save you the need to install camera specific libusb drivers. On linux you might have to disable distro supplied gphoto / automount stuff, but that can be done once for all models. This is just a suggestion, I'm *not* saying you need to switch.  Whatever works for you is fine.

Quote
So, that it passes once does not seem to be generalizable...
The crash was in shooting related code, so it's not the 0x1f5 size bug we saw on the previous USB setup. The MotionVector.c assert may indicate an issue with hook placement we could fix in this port. A few ports have this. It's good to note, but not directly related to the USB issues.

edit:
Just noting for completeness, I checked in the 0x23f4 bug fix (CAM_PTP_USE_NATIVE_BUFFER) for ixus95, ixus100 and ixus110 in trunk r5289
« Last Edit: 03 / November / 2019, 21:04:34 by reyalp »
Logged
Don't forget what the H stands for.
Pages: 1 2 3 4 5 6 [7] 8 9 10 11 12 13   Go Up
« previous next »
 

Related Topics