#955 gp_camera_wait_for_event blocks indefinitely using ptpip if connection is lost

closed-fixed
None
5
2014-08-17
2013-06-03
gKlimaDurst
No

Using gphoto2 or sample-tethered (adapted to ptpip) with ptpip results in an indefinite blocking if the connection is lost. If the connection is back on again it exits with following error (and doesn't recover):

3.594716 ptpip/generic_read(3): Hexdump of 6 = 0x6 bytes follows:
0000 01 20 2a 00 00 00 - . *...

3.594784 ptpip/oprequest(3): Hexdump of 18 = 0x12 bytes follows:
0000 12 00 00 00 06 00 00 00-01 00 00 00 c7 90 2b 00 ..............+.
0010 00 00 - ..

6.571023 ptpip/generic_read(3): Empty hexdump of empty buffer
6.571045 ptpip(0): End of stream after reading 0 bytes of ptpipheader
6.571066 context(0): PTP General Error

Error
PTP General Error
6.571090 gphoto2-camera(2): Operation failed!
Error (-1: 'Unspecified error')

6.571739 gp-camera(2): Freeing camera...
6.571746 gphoto2-camera(2): Exiting camera ('PTP/IP Camera')...
6.571756 ptpip/generic_read - enter(3): No hexdump (NULL buffer)
6.571763 ptpip/generic_read(3): Empty hexdump of empty buffer
6.571767 ptpip(0): End of stream after reading 0 bytes of ptpipheader
6.571773 ptpip/oprequest(3): Hexdump of 18 = 0x12 bytes follows:
0000 12 00 00 00 06 00 00 00-01 00 00 00 03 10 2c 00 ..............,.
0010 00 00

The cause of this behaviour can be found in ptpip.c:ptp_ptpip_generic_read where the read functions are blocking on the command channel (cmdfd).

At least inserting a select would get rid of the blocking although depending on the camera used the connection may not be recoverable at all and must be established again (camera_init).

I'm using a Nikon D800E with WT-4.

BTW the event channel uses select already!

Georg

Discussion

  • gKlimaDurst

    gKlimaDurst - 2013-06-04

    Reflecting on this situation we came to the conclusion that inserting a select with a greater timeout (10-60 seconds) in ptpip.c:ptp_ptpip_generic_read could solve at least the problem of blocking indefinitely.

    Recovering from a broken connection is another topic which is far more complex since it depends on the camera too.
    The Nikon D800E/WT-4 for example changes the state to disconnected if the lan cable is pulled (what seems clear since the physical connection is detectable broken and not the route that may only be delayed)

    Our workaround for now:

    Insert a select in ptpip.c:ptp_ptpip_getdata with a big enough timeout so that at least wait_for_events returns with a upper bound, and init the camera afterwards.

     
  • gKlimaDurst

    gKlimaDurst - 2013-06-04

    Our solution for the moment:

    :::c
    uint16_t ptp_ptpip_getdata (PTPParams params, PTPContainer ptp, PTPDataHandler *handler) {

    PTPIPHeader     hdr;
    unsigned char       *xdata = NULL;
    uint16_t        ret;
    unsigned long       toread, curread;
    int         xret;
    
    fd_set      infds;
    struct timeval  timeout;
    
    FD_ZERO(&infds);
    FD_SET(params->cmdfd, &infds);
    timeout.tv_sec = 10;
    timeout.tv_usec = 0;
    if (1 != select (params->cmdfd+1, &infds, NULL, NULL, &timeout))
        return PTP_RC_GeneralError; //PTP_RC_OK
    
    ret = ptp_ptpip_cmd_read (params, &hdr, &xdata);
    if (ret != PTP_RC_OK)
        return ret;
    
     
    Last edit: gKlimaDurst 2013-06-04
  • Marcus Meissner

    Marcus Meissner - 2013-06-30

    i am applying this patchm, that checkes the return values of select correctly

     
  • Marcus Meissner

    Marcus Meissner - 2013-06-30
     
  • Marcus Meissner

    Marcus Meissner - 2013-06-30
    • status: open --> pending-fixed
    • assigned_to: Marcus Meissner
     
  • Marcus Meissner

    Marcus Meissner - 2014-08-17

    should be in a release meanwhile

     
  • Marcus Meissner

    Marcus Meissner - 2014-08-17
    • status: pending-fixed --> closed-fixed
     

Log in to post a comment.