Problem with exiftool and geosync, possibly related to daylight saving time

The name of the pictureThe name of the pictureThe name of the pictureClash Royale CLAN TAG#URR8PPP








up vote
0
down vote

favorite












I wanted to geotag all my vacation photos with exiftool as follows:



exiftool -geotag "*.gpx" 
-geosync "19:25:42Z@IMG_7882.jpg"
-geosync "09:16:34Z@IMG_9798.jpg"
-ext .jpg .


where IMG_7802.jpg is a photo of my computer clock displaying 20:25:42 MEZ on 01 March 2018 (=19:25:42 Zulu), and similarly IMG_9798.jpg is a photo of my computer clock displaying 11:16:34 MESZ on 31 March 2018 (=09:16:34 Zulu). I used two such (bracketing) reference images in order to account for drift (and, indeed, the camera clock seems to have gained 26 seconds during that month).



The adjustment went fine for the reference images:



$ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg 
Date/Time Original : 2018:03:01 20:25:42
GPS Date/Time : 2018:03:01 19:25:42Z
$ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
Date/Time Original : 2018:03:31 10:17:00
GPS Date/Time : 2018:03:31 09:16:34Z


But for intermediate images, the computed GPS time is significantly off, e.g. by about half an hour in the following example (a GPS time of approximately 14:32Z is what I'd expect)



$ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
Date/Time Original : 2018:03:17 15:32:22
GPS Date/Time : 2018:03:17 15:04:13.45312997Z


Accordingly, the computed longitudes and latitudes are quite far off as well.



My educated guess is that the problem is related to the daylight saving time that started in Germany between the two reference images. Apparently, exiftool interpretes DateTimeOriginal in local time (so first MEZ = +0100 and later MESZ = +0200) whereas the camera clock just keeps on ticking (approximately with a +0100 offset throughout).



Q: How can I tell exiftool to not assume that the camera clock (DateTimeOriginal) follows any daylight saving time rules?










share|improve this question

























    up vote
    0
    down vote

    favorite












    I wanted to geotag all my vacation photos with exiftool as follows:



    exiftool -geotag "*.gpx" 
    -geosync "19:25:42Z@IMG_7882.jpg"
    -geosync "09:16:34Z@IMG_9798.jpg"
    -ext .jpg .


    where IMG_7802.jpg is a photo of my computer clock displaying 20:25:42 MEZ on 01 March 2018 (=19:25:42 Zulu), and similarly IMG_9798.jpg is a photo of my computer clock displaying 11:16:34 MESZ on 31 March 2018 (=09:16:34 Zulu). I used two such (bracketing) reference images in order to account for drift (and, indeed, the camera clock seems to have gained 26 seconds during that month).



    The adjustment went fine for the reference images:



    $ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg 
    Date/Time Original : 2018:03:01 20:25:42
    GPS Date/Time : 2018:03:01 19:25:42Z
    $ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
    Date/Time Original : 2018:03:31 10:17:00
    GPS Date/Time : 2018:03:31 09:16:34Z


    But for intermediate images, the computed GPS time is significantly off, e.g. by about half an hour in the following example (a GPS time of approximately 14:32Z is what I'd expect)



    $ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
    Date/Time Original : 2018:03:17 15:32:22
    GPS Date/Time : 2018:03:17 15:04:13.45312997Z


    Accordingly, the computed longitudes and latitudes are quite far off as well.



    My educated guess is that the problem is related to the daylight saving time that started in Germany between the two reference images. Apparently, exiftool interpretes DateTimeOriginal in local time (so first MEZ = +0100 and later MESZ = +0200) whereas the camera clock just keeps on ticking (approximately with a +0100 offset throughout).



    Q: How can I tell exiftool to not assume that the camera clock (DateTimeOriginal) follows any daylight saving time rules?










    share|improve this question























      up vote
      0
      down vote

      favorite









      up vote
      0
      down vote

      favorite











      I wanted to geotag all my vacation photos with exiftool as follows:



      exiftool -geotag "*.gpx" 
      -geosync "19:25:42Z@IMG_7882.jpg"
      -geosync "09:16:34Z@IMG_9798.jpg"
      -ext .jpg .


      where IMG_7802.jpg is a photo of my computer clock displaying 20:25:42 MEZ on 01 March 2018 (=19:25:42 Zulu), and similarly IMG_9798.jpg is a photo of my computer clock displaying 11:16:34 MESZ on 31 March 2018 (=09:16:34 Zulu). I used two such (bracketing) reference images in order to account for drift (and, indeed, the camera clock seems to have gained 26 seconds during that month).



      The adjustment went fine for the reference images:



      $ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg 
      Date/Time Original : 2018:03:01 20:25:42
      GPS Date/Time : 2018:03:01 19:25:42Z
      $ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
      Date/Time Original : 2018:03:31 10:17:00
      GPS Date/Time : 2018:03:31 09:16:34Z


      But for intermediate images, the computed GPS time is significantly off, e.g. by about half an hour in the following example (a GPS time of approximately 14:32Z is what I'd expect)



      $ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
      Date/Time Original : 2018:03:17 15:32:22
      GPS Date/Time : 2018:03:17 15:04:13.45312997Z


      Accordingly, the computed longitudes and latitudes are quite far off as well.



      My educated guess is that the problem is related to the daylight saving time that started in Germany between the two reference images. Apparently, exiftool interpretes DateTimeOriginal in local time (so first MEZ = +0100 and later MESZ = +0200) whereas the camera clock just keeps on ticking (approximately with a +0100 offset throughout).



      Q: How can I tell exiftool to not assume that the camera clock (DateTimeOriginal) follows any daylight saving time rules?










      share|improve this question













      I wanted to geotag all my vacation photos with exiftool as follows:



      exiftool -geotag "*.gpx" 
      -geosync "19:25:42Z@IMG_7882.jpg"
      -geosync "09:16:34Z@IMG_9798.jpg"
      -ext .jpg .


      where IMG_7802.jpg is a photo of my computer clock displaying 20:25:42 MEZ on 01 March 2018 (=19:25:42 Zulu), and similarly IMG_9798.jpg is a photo of my computer clock displaying 11:16:34 MESZ on 31 March 2018 (=09:16:34 Zulu). I used two such (bracketing) reference images in order to account for drift (and, indeed, the camera clock seems to have gained 26 seconds during that month).



      The adjustment went fine for the reference images:



      $ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg 
      Date/Time Original : 2018:03:01 20:25:42
      GPS Date/Time : 2018:03:01 19:25:42Z
      $ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
      Date/Time Original : 2018:03:31 10:17:00
      GPS Date/Time : 2018:03:31 09:16:34Z


      But for intermediate images, the computed GPS time is significantly off, e.g. by about half an hour in the following example (a GPS time of approximately 14:32Z is what I'd expect)



      $ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
      Date/Time Original : 2018:03:17 15:32:22
      GPS Date/Time : 2018:03:17 15:04:13.45312997Z


      Accordingly, the computed longitudes and latitudes are quite far off as well.



      My educated guess is that the problem is related to the daylight saving time that started in Germany between the two reference images. Apparently, exiftool interpretes DateTimeOriginal in local time (so first MEZ = +0100 and later MESZ = +0200) whereas the camera clock just keeps on ticking (approximately with a +0100 offset throughout).



      Q: How can I tell exiftool to not assume that the camera clock (DateTimeOriginal) follows any daylight saving time rules?







      camera clock timezone exiftool






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked Apr 1 at 13:54









      Hagen von Eitzen

      4211




      4211




















          1 Answer
          1






          active

          oldest

          votes

















          up vote
          0
          down vote



          accepted










          Yes, the problem ultimately comes from the DST switching and the fact that the DateTimeOriginal is interpreted as local time (hence subject to DST changes). There seem to be several ways to workaround the problem



          A) change the local time zone



          I.e., change the locale settings so that your system is in a time zone that does not switch DST during the time interval and then invoke exiftool as in the OP.



          However, I won't recommend this. You'd also have to be careful that the selected DST-less time zone is not too far off or else exiftool might be off by a full day with some of its guesses. It seems that West Africa Time (as used in Nigeria) would have worked in my specific situation.



          B) Add Time zone information to DateTimeOriginal first



          I.e., first run



          exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' -ext .jpg .


          as +01:00 was effectively the camara's time zone all along.
          This might have been advisable anyway to prevent future confusion about the time the images were taken. Then again, we are about to add the unambiguous and adjusted GPS time anyway.



          I ended up doing



          C) Use -geotime and explicit reference times with time zone specification



          ... as in



          exiftool -geotag "*.gpx" 
          -geosync "19:25:42Z@2018:03:01 20:25:42+01:00"
          -geosync "09:16:34Z@2018:03:31 10:17:00+01:00"
          '-geotime<$DateTimeOriginal+01:00'
          -ext .jpg .


          This tells exiftool to use DateTimeOriginal with specified time zone instead of interpreted as local time. Unfortunately, this only applies to the times read from the images being modified, not for the times read form the reference images (even if one changes the parameter order), so that the explicit times (with time zone) had to be used instead of file references.




          Actually, since my refernce images had already been assigned correct GPS times from the first experiments, what I really did was a mix of B and C: I did the adjustment suggested in "B" only for the two reference images:



          $ exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' IMG_7882.jpg IMG_9798.jpg


          so that their DateTimeOriginal data had time zone info:



          $ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg
          Date/Time Original : 2018:03:01 20:25:42.00+01:00
          GPS Date/Time : 2018:03:01 19:25:42Z
          $ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
          Date/Time Original : 2018:03:31 10:17:00.00+01:00
          GPS Date/Time : 2018:03:31 09:16:34Z


          After that I could use the reference images by their file names



          exiftool -geotag "*.gpx" 
          -geosync "IMG_7882.jpg"
          -geosync "IMG_9798.jpg"
          '-geotime<$DateTimeOriginal+01:00'
          -ext .jpg .


          produces the desired result for the GPS times (and consequently for the GPS coordinates) also for intermediate images:



          $ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
          Date/Time Original : 2018:03:17 15:32:22
          GPS Date/Time : 2018:03:17 14:32:08.114220008Z





          share|improve this answer




















            Your Answer







            StackExchange.ready(function()
            var channelOptions =
            tags: "".split(" "),
            id: "89"
            ;
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function()
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled)
            StackExchange.using("snippets", function()
            createEditor();
            );

            else
            createEditor();

            );

            function createEditor()
            StackExchange.prepareEditor(
            heartbeatType: 'answer',
            convertImagesToLinks: true,
            noModals: false,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: 10,
            bindNavPrevention: true,
            postfix: "",
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            );



            );













             

            draft saved


            draft discarded


















            StackExchange.ready(
            function ()
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1021063%2fproblem-with-exiftool-and-geosync-possibly-related-to-daylight-saving-time%23new-answer', 'question_page');

            );

            Post as a guest






























            1 Answer
            1






            active

            oldest

            votes








            1 Answer
            1






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            0
            down vote



            accepted










            Yes, the problem ultimately comes from the DST switching and the fact that the DateTimeOriginal is interpreted as local time (hence subject to DST changes). There seem to be several ways to workaround the problem



            A) change the local time zone



            I.e., change the locale settings so that your system is in a time zone that does not switch DST during the time interval and then invoke exiftool as in the OP.



            However, I won't recommend this. You'd also have to be careful that the selected DST-less time zone is not too far off or else exiftool might be off by a full day with some of its guesses. It seems that West Africa Time (as used in Nigeria) would have worked in my specific situation.



            B) Add Time zone information to DateTimeOriginal first



            I.e., first run



            exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' -ext .jpg .


            as +01:00 was effectively the camara's time zone all along.
            This might have been advisable anyway to prevent future confusion about the time the images were taken. Then again, we are about to add the unambiguous and adjusted GPS time anyway.



            I ended up doing



            C) Use -geotime and explicit reference times with time zone specification



            ... as in



            exiftool -geotag "*.gpx" 
            -geosync "19:25:42Z@2018:03:01 20:25:42+01:00"
            -geosync "09:16:34Z@2018:03:31 10:17:00+01:00"
            '-geotime<$DateTimeOriginal+01:00'
            -ext .jpg .


            This tells exiftool to use DateTimeOriginal with specified time zone instead of interpreted as local time. Unfortunately, this only applies to the times read from the images being modified, not for the times read form the reference images (even if one changes the parameter order), so that the explicit times (with time zone) had to be used instead of file references.




            Actually, since my refernce images had already been assigned correct GPS times from the first experiments, what I really did was a mix of B and C: I did the adjustment suggested in "B" only for the two reference images:



            $ exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' IMG_7882.jpg IMG_9798.jpg


            so that their DateTimeOriginal data had time zone info:



            $ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg
            Date/Time Original : 2018:03:01 20:25:42.00+01:00
            GPS Date/Time : 2018:03:01 19:25:42Z
            $ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
            Date/Time Original : 2018:03:31 10:17:00.00+01:00
            GPS Date/Time : 2018:03:31 09:16:34Z


            After that I could use the reference images by their file names



            exiftool -geotag "*.gpx" 
            -geosync "IMG_7882.jpg"
            -geosync "IMG_9798.jpg"
            '-geotime<$DateTimeOriginal+01:00'
            -ext .jpg .


            produces the desired result for the GPS times (and consequently for the GPS coordinates) also for intermediate images:



            $ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
            Date/Time Original : 2018:03:17 15:32:22
            GPS Date/Time : 2018:03:17 14:32:08.114220008Z





            share|improve this answer
























              up vote
              0
              down vote



              accepted










              Yes, the problem ultimately comes from the DST switching and the fact that the DateTimeOriginal is interpreted as local time (hence subject to DST changes). There seem to be several ways to workaround the problem



              A) change the local time zone



              I.e., change the locale settings so that your system is in a time zone that does not switch DST during the time interval and then invoke exiftool as in the OP.



              However, I won't recommend this. You'd also have to be careful that the selected DST-less time zone is not too far off or else exiftool might be off by a full day with some of its guesses. It seems that West Africa Time (as used in Nigeria) would have worked in my specific situation.



              B) Add Time zone information to DateTimeOriginal first



              I.e., first run



              exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' -ext .jpg .


              as +01:00 was effectively the camara's time zone all along.
              This might have been advisable anyway to prevent future confusion about the time the images were taken. Then again, we are about to add the unambiguous and adjusted GPS time anyway.



              I ended up doing



              C) Use -geotime and explicit reference times with time zone specification



              ... as in



              exiftool -geotag "*.gpx" 
              -geosync "19:25:42Z@2018:03:01 20:25:42+01:00"
              -geosync "09:16:34Z@2018:03:31 10:17:00+01:00"
              '-geotime<$DateTimeOriginal+01:00'
              -ext .jpg .


              This tells exiftool to use DateTimeOriginal with specified time zone instead of interpreted as local time. Unfortunately, this only applies to the times read from the images being modified, not for the times read form the reference images (even if one changes the parameter order), so that the explicit times (with time zone) had to be used instead of file references.




              Actually, since my refernce images had already been assigned correct GPS times from the first experiments, what I really did was a mix of B and C: I did the adjustment suggested in "B" only for the two reference images:



              $ exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' IMG_7882.jpg IMG_9798.jpg


              so that their DateTimeOriginal data had time zone info:



              $ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg
              Date/Time Original : 2018:03:01 20:25:42.00+01:00
              GPS Date/Time : 2018:03:01 19:25:42Z
              $ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
              Date/Time Original : 2018:03:31 10:17:00.00+01:00
              GPS Date/Time : 2018:03:31 09:16:34Z


              After that I could use the reference images by their file names



              exiftool -geotag "*.gpx" 
              -geosync "IMG_7882.jpg"
              -geosync "IMG_9798.jpg"
              '-geotime<$DateTimeOriginal+01:00'
              -ext .jpg .


              produces the desired result for the GPS times (and consequently for the GPS coordinates) also for intermediate images:



              $ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
              Date/Time Original : 2018:03:17 15:32:22
              GPS Date/Time : 2018:03:17 14:32:08.114220008Z





              share|improve this answer






















                up vote
                0
                down vote



                accepted







                up vote
                0
                down vote



                accepted






                Yes, the problem ultimately comes from the DST switching and the fact that the DateTimeOriginal is interpreted as local time (hence subject to DST changes). There seem to be several ways to workaround the problem



                A) change the local time zone



                I.e., change the locale settings so that your system is in a time zone that does not switch DST during the time interval and then invoke exiftool as in the OP.



                However, I won't recommend this. You'd also have to be careful that the selected DST-less time zone is not too far off or else exiftool might be off by a full day with some of its guesses. It seems that West Africa Time (as used in Nigeria) would have worked in my specific situation.



                B) Add Time zone information to DateTimeOriginal first



                I.e., first run



                exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' -ext .jpg .


                as +01:00 was effectively the camara's time zone all along.
                This might have been advisable anyway to prevent future confusion about the time the images were taken. Then again, we are about to add the unambiguous and adjusted GPS time anyway.



                I ended up doing



                C) Use -geotime and explicit reference times with time zone specification



                ... as in



                exiftool -geotag "*.gpx" 
                -geosync "19:25:42Z@2018:03:01 20:25:42+01:00"
                -geosync "09:16:34Z@2018:03:31 10:17:00+01:00"
                '-geotime<$DateTimeOriginal+01:00'
                -ext .jpg .


                This tells exiftool to use DateTimeOriginal with specified time zone instead of interpreted as local time. Unfortunately, this only applies to the times read from the images being modified, not for the times read form the reference images (even if one changes the parameter order), so that the explicit times (with time zone) had to be used instead of file references.




                Actually, since my refernce images had already been assigned correct GPS times from the first experiments, what I really did was a mix of B and C: I did the adjustment suggested in "B" only for the two reference images:



                $ exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' IMG_7882.jpg IMG_9798.jpg


                so that their DateTimeOriginal data had time zone info:



                $ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg
                Date/Time Original : 2018:03:01 20:25:42.00+01:00
                GPS Date/Time : 2018:03:01 19:25:42Z
                $ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
                Date/Time Original : 2018:03:31 10:17:00.00+01:00
                GPS Date/Time : 2018:03:31 09:16:34Z


                After that I could use the reference images by their file names



                exiftool -geotag "*.gpx" 
                -geosync "IMG_7882.jpg"
                -geosync "IMG_9798.jpg"
                '-geotime<$DateTimeOriginal+01:00'
                -ext .jpg .


                produces the desired result for the GPS times (and consequently for the GPS coordinates) also for intermediate images:



                $ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
                Date/Time Original : 2018:03:17 15:32:22
                GPS Date/Time : 2018:03:17 14:32:08.114220008Z





                share|improve this answer












                Yes, the problem ultimately comes from the DST switching and the fact that the DateTimeOriginal is interpreted as local time (hence subject to DST changes). There seem to be several ways to workaround the problem



                A) change the local time zone



                I.e., change the locale settings so that your system is in a time zone that does not switch DST during the time interval and then invoke exiftool as in the OP.



                However, I won't recommend this. You'd also have to be careful that the selected DST-less time zone is not too far off or else exiftool might be off by a full day with some of its guesses. It seems that West Africa Time (as used in Nigeria) would have worked in my specific situation.



                B) Add Time zone information to DateTimeOriginal first



                I.e., first run



                exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' -ext .jpg .


                as +01:00 was effectively the camara's time zone all along.
                This might have been advisable anyway to prevent future confusion about the time the images were taken. Then again, we are about to add the unambiguous and adjusted GPS time anyway.



                I ended up doing



                C) Use -geotime and explicit reference times with time zone specification



                ... as in



                exiftool -geotag "*.gpx" 
                -geosync "19:25:42Z@2018:03:01 20:25:42+01:00"
                -geosync "09:16:34Z@2018:03:31 10:17:00+01:00"
                '-geotime<$DateTimeOriginal+01:00'
                -ext .jpg .


                This tells exiftool to use DateTimeOriginal with specified time zone instead of interpreted as local time. Unfortunately, this only applies to the times read from the images being modified, not for the times read form the reference images (even if one changes the parameter order), so that the explicit times (with time zone) had to be used instead of file references.




                Actually, since my refernce images had already been assigned correct GPS times from the first experiments, what I really did was a mix of B and C: I did the adjustment suggested in "B" only for the two reference images:



                $ exiftool '-DateTimeOriginal<$DateTimeOriginal+01:00' IMG_7882.jpg IMG_9798.jpg


                so that their DateTimeOriginal data had time zone info:



                $ exiftool -datetimeoriginal -gpsdatetime IMG_7882.jpg
                Date/Time Original : 2018:03:01 20:25:42.00+01:00
                GPS Date/Time : 2018:03:01 19:25:42Z
                $ exiftool -datetimeoriginal -gpsdatetime IMG_9798.jpg
                Date/Time Original : 2018:03:31 10:17:00.00+01:00
                GPS Date/Time : 2018:03:31 09:16:34Z


                After that I could use the reference images by their file names



                exiftool -geotag "*.gpx" 
                -geosync "IMG_7882.jpg"
                -geosync "IMG_9798.jpg"
                '-geotime<$DateTimeOriginal+01:00'
                -ext .jpg .


                produces the desired result for the GPS times (and consequently for the GPS coordinates) also for intermediate images:



                $ exiftool -datetimeoriginal -gpsdatetime IMG_8888.jpg
                Date/Time Original : 2018:03:17 15:32:22
                GPS Date/Time : 2018:03:17 14:32:08.114220008Z






                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered Apr 1 at 17:54









                Hagen von Eitzen

                4211




                4211



























                     

                    draft saved


                    draft discarded















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function ()
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f1021063%2fproblem-with-exiftool-and-geosync-possibly-related-to-daylight-saving-time%23new-answer', 'question_page');

                    );

                    Post as a guest













































































                    Popular posts from this blog

                    pylint3 and pip3 broken

                    Missing snmpget and snmpwalk

                    How to enroll fingerprints to Ubuntu 17.10 with VFS491