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