Re: FILE_ADDED events getting lost
Marcus Meissner <[email protected]> Tue, 6 Oct 2020 19:36:34 +0200
| Newsgroups | gmane.comp.multimedia.gphoto.user |
|---|---|
| Organization | SUSE Software Solutions Ger many GmbH, Maxfeldstr. 5, 90409 Nuernberg, Germany , GF: Felix Imendörffer, HRB 36809, AG Nürnber g |
| Message-ID | <[email protected]> |
On Tue, Oct 06, 2020 at 09:39:37AM -0700, Dave Taylor wrote: > On Mon, Oct 5, 2020 at 10:54 PM Marcus Meissner <[email protected]> wrote: > > > > Hi, > > > > - Is this libgphoto2 using libusb1 or libusb0? > > > > If you are using libusb0, it is possible to lose USB interrupts if you are not > > waiting for events actively. > > Not sure how I would find out for the version that came with Debian > buster. I did an ldd on my executable, and it doesn't appear to be > referencing libusb as a dynamically loaded library. How would I tell > which version was compiled in? gphoto2 --version will list either libusb0 or libusb1 in its output. > > - just to check, you are polling with gp_camera_wait_for_event until GP_EVENT_TIMEOUT > > is returned? > > > > There might be multiple events buffered. > > Yes. I fetch all the buffered events, and the timeout is always below > 10ms for each call, but the actual elapsed time for some reason can > vary widely. There might be waits of 150ms in the function, so a bit more coarse grained waiting might be better. > > When did you see this change of reliability happen? When you passed > > longer times to gp_camera_wait_for_event? > > I never pass more than 10ms as a timeout, but it gets really slow > sometimes, on the order of 100ms to 1s. I haven't correlated why/when > it happens yet, but when it does, I'm definitely not going to get a > GP_EVENT_FILE_ADDED, but this isn't the only time it happens. It can > respond in normal time and still not return FILE_ADDED. > > Please let me know if there's anything I can do to help isolate the issue. Hmm. weird :/ Ciao, Marcus