the photo which in photo scope the display time don't accordance with the device time of it was took

[Relly]

system-image-cli -i
current build number: 120
device name: krillin
channel: ubuntu-touch/devel-proposed/krillin.en
last update: 2015-06-25 10:05:25
version version: 120
version ubuntu: 20150624
version device: 20150529-8e13c5f
version custom: 20150528-722-29-15-vivid

reproduce steps:
1.Navigate to the Photos scope
2.Tap on a photo you took with the phones camera
3.check the display time and date.the
expected result:
1.the display time should be accordance with the device time of it was took
actually result:
the photo which in photo scope the display time don't accordance with the device time of it was took

[Yuan-Chen Cheng (ycheng-twn)]

I can reproduce on

phablet@ubuntu-phablet:~$ system-image-cli -i
current build number: 48
device name: krillin
channel: ubuntu-touch/rc-proposed/bq-aquaris.en
last update: 2015-06-24 16:56:07
version version: 48
version ubuntu: 20150624
version device: 20150529-8e13c5f
version custom: 20150528-722-29-15-vivid

time to take picture: 11:22 am +8
Time show on My Photo Scope: 1:22:55pm CST

As I do `adb shell date`, the CST time is correct.

As I copy the file to ubuntu desktop, and check exif, the time is correct (in CST)

[Yuan-Chen Cheng (ycheng-twn)]

I verified it's been fixed and released in another bug.

[Jean-Baptiste Lallement (jibel)]

This is still a problem on krillin #108.

[Yuan-Chen Cheng (ycheng-twn)]

krillin: ubuntu-touch/rc-proposed/bq-aquaris.en r108: bug exists
krillin: ubuntu-touch/rc-proposed/bq-aquaris.en r110: bug exists
arale: ubuntu-touch/rc-proposed/meizu.en r99: bug NOT exists

I guess this is the most interesting bug that Hit me this year !

[John McAleely (john.mcaleely)]

Sounds like this belongs in barajas. I'll move it there.

[Yuan-Chen Cheng (ycheng-twn)]

set to triage in savilerow (means we tracking it in savilerow only)

[Kyle Nitzsche (knitzsche)]

This may be the same issue discussed here but never actually resolved: https://bugs.launchpad.net/mediascanner2/+bug/1418639

[Alan Pater (alan-pater)]

If you run the following command on a image that has this issue, what is the result?

$ exiv2 -pa image.jpg | grep DateTime

[Kyle Nitzsche (knitzsche)]

@Alan, I previously placed the exiv2 data in the first bug to mention this problem: https://bugs.launchpad.net/mediascanner2/+bug/1418639

Cheers

[Kyle Nitzsche (knitzsche)]

I (still) think the issue is that the mediastore.db contains the wrong time (off by one hour), because the image's exiv2 data is correct.

Here's "proof".

System info [1]

1) I took a photo at 11:27 on Nov2 2015.

2) Here's the datetime a couple minutes later:
phablet@ubuntu-phablet:~/Pictures/com.ubuntu.camera$ date
Mon Nov 2 11:31:32 EST 2015

3) exiv2 Image timestamp is correct for the device timezene:
$ exiv2 image20151102_112746056.jpg | grep -i timestamp
Image timestamp : 2015:11:02 11:27:47

4) mediastore.db contains image but has time off by on hour:
sqlite> select date from media where filename='/home/phablet/Pictures/com.ubuntu.camera/image20151102_112746056.jpg';
2015-11-02T17:27:47

5) My Photos shows that ^ time, which is off by an hour

5A) scopregistry.log:
"======== media_date: 2015-11-02T17:27:47"
==== MS url: "image://thumbnailer/file:///home/phablet/Pictures/com.ubuntu.camera/image20151102_112746056.jpg"
==== media_date: "2015-11-02T17:27:47"
==== mDataTime_utc: "Mon Nov 2 17:27:47 2015 GMT"
==== mDataTime_local: "Mon Nov 2 12:27:47 2015"
5B) Screenshot of photo preview with off-by-one time.

Note: the code My Photos uses to get date is quite simple here: ihttps://bazaar.launchpad.net/~hanloon-team/hanloon/photos-local/view/head:/src/query.cpp#L139

I think this shows the problem is that the mediastore.db has the wrong timestamp for the photo.

[1] phablet@ubuntu-phablet:~$ system-image-cli -i
current build number: 547
device name: krillin
channel: ubuntu-touch/rc-proposed/bq-aquaris.en-proposed

[Alan Pater (alan-pater)]

Would the DateTime guidelines from the MWG help on this issue?

    http://www.metadataworkinggroup.org/pdf/mwg_guidance.pdf#page=37

[James Henstridge (jamesh)]

I was looking into this with Kyle at the sprint today. He had his krillin set to UTC time zone and took a photo which produced the following metadata:

    $ exiv2 print -PE image20160122_182840970.jpg | grep Date
    Exif.Image.DateTime Ascii 20 2016:01:22 19:28:42
    Exif.Photo.DateTimeOriginal Ascii 20 2016:01:22 18:28:42
    Exif.Photo.DateTimeDigitized Ascii 20 2016:01:22 18:28:42

My arale was set to Australia/Perth time zone (UTC+8), and took a photo:

    $ exiv2 print -PE image20160123_030314442.jpg | grep Date
    Exif.Image.DateTime Ascii 20 2016:01:22 19:03:15
    Exif.Photo.DateTimeOriginal Ascii 20 2016:01:23 03:03:15
    Exif.Photo.DateTimeDigitized Ascii 20 2016:01:23 03:03:15

It looks like DateTime is being stored with a different time zone to DateTimeOriginal/DateTimeDigitized, which seems like a bug. For my arale, the 8 hour difference looks like DateTime is in UTC and the others in local time.

I'm not sure where the DateTime value from Kyle's krillin comes from: it isn't UTC and since local time is UTC, so it isn't that either.

Whatever is going on, the root cause appears to be the inconsistent dates that the camera is writing to the images it produces.

[James Henstridge (jamesh)]

Some of the strings in the EXIF tags (e.g. the Exif.Image.Software value) appear to come from /android/system/lib/libcam.exif.so.

It sounds like this is device specific on Android, which explains the different behaviour on different devices:

https://code.google.com/p/android/issues/detail?id=40916

Unless we have source code to this, it might be up to BQ to fix.

[James Henstridge (jamesh)]

I've got code in silo 75 at the moment that switches the order of EXIF tags checked for the date. Picking DateTimeOriginal as first preference should avoid this bug on krillin, and seems closer to the semantic meaning we place on the field for other media types.

[Launchpad Janitor (janitor)]

This bug was fixed in the package mediascanner2 - 0.111+16.04.20160225-0ubuntu1

---------------
mediascanner2 (0.111+16.04.20160225-0ubuntu1) xenial; urgency=medium

  [ James Henstridge ]
  * Batch index updates during the initial scan in 10 second intervals
    (the same rate as invalidation notifications go out). This greatly
    reduces the IO overhead on initial startup, and is fairly safe now
    we have out of process metadata extraction.
  * Don't emit the InvalidateResults signal if a file was opened for
    writing and then closed, but not actually modified (LP: #1542175)
  * Favour the EXIF DateTimeOriginal tag over DateTime when extracting
    metadata from photos. (LP: #1468585)
  * Use taglib to extract metadata from Vorbis, Opus, Flac, MP3 and MP4
    audio files. Other formats will fall back to the existing GStreamer
    code path. (LP: #1536832)

  [ CI Train Bot ]
  * debian/libmediascanner-2.0-3.symbols: update to released version.

 -- James Henstridge <email address hidden> Thu, 25 Feb 2016 01:53:33 +0000