Date not recognized / Date from picture name

deekerman commented

2026-02-19 23:05:00 -05:00

Owner

Originally created by @don-sh on GitHub (May 13, 2020).

Originally assigned to: @lastzero on GitHub.

Hi there,
Thanks for this great project!

I have a problem with the application not picking up the correct date for some pictures.
E.g. I have a picture (2011-07-19 11.36.39.jpg) which was taken on 2011-07-19.
From the import logs I can see the date recognized as 2018-07-20.
But in the gui the taken date is the import date (May 13, 2020).

But where does the 2018 come from? And shouldn't the name of the picture be used if there is no other information available?

Same with pictures from WhatsApp, Signal and screenshots from Android. There is no information about the date but from the naming:
WhasApp
2014-08-25_17.15.33.jpg
IMG-20161224-WA0014.jpg
Signal
signal-2018-08-21-100217.jpg
Android screen capture
Screenshot_20190201-212530_Fennec_F-Droid.png

2020-05-13 17:19:57 INFO import completed in 0 s
2020-05-13 17:19:57 INFO index: updating photo counts
2020-05-13 17:19:57 INFO import: updated main jpg file 2018/07/20180720_235036_8226A657.0002.jpg
2020-05-13 17:19:57 INFO photo: changed photo title to “Lakeside / 2020”
2020-05-13 17:19:56 INFO index: no latitude and longitude in metadata
2020-05-13 17:19:56 INFO mediafile: no new thumbnails created for 20180720_235036_8226A657.0002 [3.044932ms]
2020-05-13 17:19:56 INFO import: moving main jpg file “2011-07-19 11.36.39.jpg” to 2018/07/20180720_235036_8226A657.0002.jpg
2020-05-13 17:19:56 INFO mediafile: taken at 2018-07-20 23:50:36.704232 +0000 UTC
2020-05-13 17:19:56 INFO import: no .ppignore file found
2020-05-13 17:19:56 INFO copying files from import
2020-05-13 17:19:54 INFO settings saved
2020-05-13 17:19:53 INFO settings saved
2020-05-13 17:19:53 INFO settings saved

Originally created by @don-sh on GitHub (May 13, 2020). Originally assigned to: @lastzero on GitHub. Hi there, Thanks for this great project! I have a problem with the application not picking up the correct date for some pictures. E.g. I have a picture (2011-07-19 11.36.39.jpg) which was taken on 2011-07-19. From the import logs I can see the date recognized as 2018-07-20. But in the gui the taken date is the import date (May 13, 2020). ![Screenshot from 2020-05-13 19-30-57](https://user-images.githubusercontent.com/63861925/81845293-ad8f6680-9550-11ea-9b57-f15a1b3383e4.png) But where does the 2018 come from? And shouldn't the name of the picture be used if there is no other information available? Same with pictures from WhatsApp, Signal and screenshots from Android. There is no information about the date but from the naming: **WhasApp** 2014-08-25_17.15.33.jpg IMG-20161224-WA0014.jpg **Signal** signal-2018-08-21-100217.jpg **Android screen capture** Screenshot_20190201-212530_Fennec_F-Droid.png ``` 2020-05-13 17:19:57 INFO import completed in 0 s 2020-05-13 17:19:57 INFO index: updating photo counts 2020-05-13 17:19:57 INFO import: updated main jpg file 2018/07/20180720_235036_8226A657.0002.jpg 2020-05-13 17:19:57 INFO photo: changed photo title to “Lakeside / 2020” 2020-05-13 17:19:56 INFO index: no latitude and longitude in metadata 2020-05-13 17:19:56 INFO mediafile: no new thumbnails created for 20180720_235036_8226A657.0002 [3.044932ms] 2020-05-13 17:19:56 INFO import: moving main jpg file “2011-07-19 11.36.39.jpg” to 2018/07/20180720_235036_8226A657.0002.jpg 2020-05-13 17:19:56 INFO mediafile: taken at 2018-07-20 23:50:36.704232 +0000 UTC 2020-05-13 17:19:56 INFO import: no .ppignore file found 2020-05-13 17:19:56 INFO copying files from import 2020-05-13 17:19:54 INFO settings saved 2020-05-13 17:19:53 INFO settings saved 2020-05-13 17:19:53 INFO settings saved ```

deekerman

2026-02-19 23:05:00 -05:00

closed this issue
added the
released

bug
labels

deekerman commented

2026-02-19 23:05:01 -05:00

Author

Owner

@machetto commented on GitHub (May 14, 2020):

I have the same problem. I pulled latest docker image today and imported a few older photos. They were captured in 2003 however they are displayed as made in year 2020.

Update: "Create Date" attribute in EXIF contains correct date. However "GPS Date/Time" attribute contains incorrect date. It is probably because I set GPS coordinates using "GeoSetter" tool and it set the attribute incorrectly. So basically the question is what EXIF attribute is used to determine a photo's date?

Update 2: I fixed the "GPS Date/Time" attribute however the photos still got imported with the 2020 year in their date. Below is an output from exiftool.

W:\photos>exiftool -time:all -s CRW_0267.jpg

FileModifyDate : 2020:05:14 20:51:39+10:00

FileAccessDate : 2020:05:14 21:09:24+10:00

FileCreateDate : 2020:05:14 20:51:39+10:00

ModifyDate : 2003:12:07 17:51:51

GPSTimeStamp : 11:51:51

GPSDateStamp : 2003:12:07

CreateDate : 2003:12:07 17:51:51+06:00

MetadataDate : 2003:12:07 17:51:51+06:00

GPSDateTime : 2003:12:07 11:51:51Z

@machetto commented on GitHub (May 14, 2020): I have the same problem. I pulled latest docker image today and imported a few older photos. They were captured in 2003 however they are displayed as made in year 2020. Update: "Create Date" attribute in EXIF contains correct date. However "GPS Date/Time" attribute contains incorrect date. It is probably because I set GPS coordinates using "GeoSetter" tool and it set the attribute incorrectly. So basically the question is what EXIF attribute is used to determine a photo's date? Update 2: I fixed the "GPS Date/Time" attribute however the photos still got imported with the 2020 year in their date. Below is an output from exiftool. W:\photos\>exiftool -time:all -s CRW_0267.jpg FileModifyDate : 2020:05:14 20:51:39+10:00 FileAccessDate : 2020:05:14 21:09:24+10:00 FileCreateDate : 2020:05:14 20:51:39+10:00 ModifyDate : 2003:12:07 17:51:51 GPSTimeStamp : 11:51:51 GPSDateStamp : 2003:12:07 CreateDate : 2003:12:07 17:51:51+06:00 MetadataDate : 2003:12:07 17:51:51+06:00 GPSDateTime : 2003:12:07 11:51:51Z

deekerman commented

2026-02-19 23:05:01 -05:00

Author

Owner

@lastzero commented on GitHub (May 14, 2020):

Can you test again with today's build after you've set PHOTOPRISM_SIDECAR_JSON to "true"?

This will automatically create JSON sidecar files using exiftool so that we can extract additional metadata we can't find in common Exif headers (like in Videos and XMP).

You can also provide us with test files, either attached to this issue or via email to hello@photoprism.org!

Guessing the date from the filename is not implemented yet, not sure if this is a "must have" for our first release!? Problem is that there are MANY time and date formats and sometimes it might look like a date, but it's not. There is not one single standard like in Exif.

@lastzero commented on GitHub (May 14, 2020): Can you test again with today's build after you've set `PHOTOPRISM_SIDECAR_JSON` to "true"? This will automatically create JSON sidecar files using `exiftool` so that we can extract additional metadata we can't find in common Exif headers (like in Videos and XMP). You can also provide us with test files, either attached to this issue or via email to hello@photoprism.org! Guessing the date from the filename is not implemented yet, not sure if this is a "must have" for our first release!? Problem is that there are MANY time and date formats and sometimes it might look like a date, but it's not. There is not one single standard like in Exif.

deekerman commented

2026-02-19 23:05:02 -05:00

Author

Owner

@don-sh commented on GitHub (May 14, 2020):

With this method it almost works. Within the application the correct date is shown but it gets named wrong and consequently put in the wrong directory in the Originals folder.
Picture I used (2011-07-19 11.36.39.jpg)

2020-05-14 16:49:35 INFO import completed in 6 s
2020-05-14 16:49:35 INFO index: updating photo counts
2020-05-14 16:49:35 INFO import: added related json file 2018/07/20180720_235036_62DCAC23.json
2020-05-14 16:49:35 INFO import: added main jpg file 2018/07/20180720_235036_62DCAC23.jpg
2020-05-14 16:49:34 INFO photo: changed photo title to “Unknown / 2011”
2020-05-14 16:49:34 INFO index: no latitude and longitude in metadata
2020-05-14 16:49:32 INFO convert: 2018/07/20180720_235036_62DCAC23.jpg -> 2018/07/20180720_235036_62DCAC23.json
2020-05-14 16:49:32 INFO mediafile: 11 thumbnails created for 20180720_235036_62DCAC23 [541.901209ms]
2020-05-14 16:49:31 INFO import: moving main jpg file “2011-07-19 11.36.39.jpg” to 2018/07/20180720_235036_62DCAC23.jpg
2020-05-14 16:49:31 INFO mediafile: taken at 2018-07-20 23:50:36.704232 +0000 UTC
2020-05-14 16:49:31 INFO import: no .ppignore file found
2020-05-14 16:49:31 INFO tensorflow: loading classification labels from labels.txt
2020-05-14 16:49:28 INFO tensorflow: loading image classification model from nasnet
2020-05-14 16:49:28 INFO copying files from import
2020-05-14 16:49:22 INFO settings saved

Guessing the date from the filename is not implemented yet, not sure if this is a "must have" for our first release!? Problem is that there are MANY time and date formats and sometimes it might look like a date, but it's not. There is not one single standard like in Exif.

Well, it could be a quick win; I think many people have whatsapp/signal pictures in their galleries.

Thanks for your effort!

@don-sh commented on GitHub (May 14, 2020): With this method it almost works. Within the application the correct date is shown but it gets named wrong and consequently put in the wrong directory in the Originals folder. [Picture I used (2011-07-19 11.36.39.jpg)](https://user-images.githubusercontent.com/63861925/81962800-9023d080-9614-11ea-9ba3-5c5bdef98c08.jpg) ``` 2020-05-14 16:49:35 INFO import completed in 6 s 2020-05-14 16:49:35 INFO index: updating photo counts 2020-05-14 16:49:35 INFO import: added related json file 2018/07/20180720_235036_62DCAC23.json 2020-05-14 16:49:35 INFO import: added main jpg file 2018/07/20180720_235036_62DCAC23.jpg 2020-05-14 16:49:34 INFO photo: changed photo title to “Unknown / 2011” 2020-05-14 16:49:34 INFO index: no latitude and longitude in metadata 2020-05-14 16:49:32 INFO convert: 2018/07/20180720_235036_62DCAC23.jpg -> 2018/07/20180720_235036_62DCAC23.json 2020-05-14 16:49:32 INFO mediafile: 11 thumbnails created for 20180720_235036_62DCAC23 [541.901209ms] 2020-05-14 16:49:31 INFO import: moving main jpg file “2011-07-19 11.36.39.jpg” to 2018/07/20180720_235036_62DCAC23.jpg 2020-05-14 16:49:31 INFO mediafile: taken at 2018-07-20 23:50:36.704232 +0000 UTC 2020-05-14 16:49:31 INFO import: no .ppignore file found 2020-05-14 16:49:31 INFO tensorflow: loading classification labels from labels.txt 2020-05-14 16:49:28 INFO tensorflow: loading image classification model from nasnet 2020-05-14 16:49:28 INFO copying files from import 2020-05-14 16:49:22 INFO settings saved ``` > Guessing the date from the filename is not implemented yet, not sure if this is a "must have" for our first release!? Problem is that there are MANY time and date formats and sometimes it might look like a date, but it's not. There is not one single standard like in Exif. Well, it could be a quick win; I think many people have whatsapp/signal pictures in their galleries. Thanks for your effort!

deekerman commented

2026-02-19 23:05:02 -05:00

Author

Owner

@lastzero commented on GitHub (May 14, 2020):

@don-sh Thanks! Maybe I can have a look at this tomorrow :)

@lastzero commented on GitHub (May 14, 2020): @don-sh Thanks! Maybe I can have a look at this tomorrow :)

deekerman commented

2026-02-19 23:05:02 -05:00

Author

Owner

@lastzero commented on GitHub (May 15, 2020):

@don-sh It should work now, although there's a potential issue with the JPEG parser. Created an issue for this, maybe @dsoprea can help.

@lastzero commented on GitHub (May 15, 2020): @don-sh It should work now, although there's a potential issue with the JPEG parser. Created an issue for this, maybe @dsoprea can help.

deekerman commented

2026-02-19 23:05:02 -05:00

Author

Owner

@dsoprea commented on GitHub (May 15, 2020):

I'll take a look at this tonight.

@dsoprea commented on GitHub (May 15, 2020): I'll take a look at this tonight.

deekerman commented

2026-02-19 23:05:03 -05:00

Author

Owner

@don-sh commented on GitHub (May 15, 2020):

@lastzero Yes, works now. Thanks!

@don-sh commented on GitHub (May 15, 2020): @lastzero Yes, works now. Thanks!

deekerman commented

2026-02-19 23:05:03 -05:00

Author

Owner

@dsoprea commented on GitHub (May 15, 2020):

@lastzero It's not clear what the fix was. Are you using exiftool? It'd be odd that ExifTool would recognize it since these names exist in the standard but not in the file. In the raw EXIF data, tags are represented as IDs, and CreateDate is not a standard name so there's no standard ID for it. So, it's unclear where that' would be coming from and how. CreateDate looks to be a valid property in XMP, but, then, we're dealing with JPEGs, not XMPs...

@dsoprea commented on GitHub (May 15, 2020): @lastzero It's not clear what the fix was. Are you using exiftool? It'd be odd that ExifTool would recognize it since these names exist in the standard but not in the file. In the raw EXIF data, tags are represented as IDs, and CreateDate is not a standard name so there's no standard ID for it. So, it's unclear where that' would be coming from and how. CreateDate looks to be a valid property in XMP, but, then, we're dealing with JPEGs, not XMPs...

deekerman commented

2026-02-19 23:05:03 -05:00

Author

Owner

@alxjsn commented on GitHub (May 15, 2020):

Right now, when a file is marked as "unknown" it appears at the top when sorting by newest. Can this behavior be changed to move those photos to the end?

@alxjsn commented on GitHub (May 15, 2020): Right now, when a file is marked as "unknown" it appears at the top when sorting by newest. Can this behavior be changed to move those photos to the end?

deekerman commented

2026-02-19 23:05:03 -05:00

Author

Owner

@lastzero commented on GitHub (May 15, 2020):

@alxjsn That's why we added the quality filter. If we always move them to the end and you have 50k+ photos, like we do, you will never see them in practice.

@lastzero commented on GitHub (May 15, 2020): @alxjsn That's why we added the quality filter. If we always move them to the end and you have 50k+ photos, like we do, you will never see them in practice.

deekerman commented

2026-02-19 23:05:03 -05:00

Author

Owner

@lastzero commented on GitHub (May 15, 2020):

@dsoprea The main bug here was that the JPEG Exif header could not be properly parsed, see issue I created in your repository. The fallback to the "brute force" Exif search method is a temporary fix.

@lastzero commented on GitHub (May 15, 2020): @dsoprea The main bug here was that the JPEG Exif header could not be properly parsed, see issue I created in your repository. The fallback to the "brute force" Exif search method is a temporary fix.

deekerman commented

2026-02-19 23:05:03 -05:00

Author

Owner

@lastzero commented on GitHub (May 15, 2020):

Possible that CreateDate is XMP, can be stored in JPEG headers too. Exiftool can read it, but we didn't have time to directly extract it yet.

@lastzero commented on GitHub (May 15, 2020): Possible that CreateDate is XMP, can be stored in JPEG headers too. Exiftool can read it, but we didn't have time to directly extract it yet.

deekerman commented

2026-02-19 23:05:03 -05:00

Author

Owner

@dsoprea commented on GitHub (May 16, 2020):

Okay, so there's a couple of things. First, the tag is 0x9004, as shown here:

0x9209 Flash                           : Off, Did not fire
0x9004 Create Date                     : 2011:07:19 11:36:38
     - Warning                         : Invalid EXIF text encoding for UserComment
0x9286 User Comment                    : focus:Tut

The proper tag name, per the spec and the go-exif config, is "DateTimeDigitized".

I had checked the segments for XMP data, but there was no extra data there (I know that this was just a suggestion on your part):

$ go run command/js_dump/main.go -f "xmp_in_jpeg_maybe__2011-07-19 11.36.39.jpg"
JPEG Segments:

 0: OFFSET=(0x00000000          0) ID=(0xd8) NAME=[SOI  ] SIZE=(         0) SHA1=[da39a3ee5e6b4b0d3255bfef95601890afd80709]
 1: OFFSET=(0x00000002          2) ID=(0xe1) NAME=[APP1 ] SIZE=(      9961) SHA1=[8b6438e621ef10eb67777818acb566a9f3fe3408]
 2: OFFSET=(0x000026ef       9967) ID=(0xdb) NAME=[DQT  ] SIZE=(       195) SHA1=[f089585c94d9a5fceae3a31052385643fc815f34]
 3: OFFSET=(0x000027b6      10166) ID=(0xc0) NAME=[SOF0 ] SIZE=(        15) SHA1=[460981aa028f49eff5904447a250e39520ea77a5]
 4: OFFSET=(0x000027c9      10185) ID=(0xc4) NAME=[DHT  ] SIZE=(       416) SHA1=[8f8ba97c8f26fdfe46a09f523ee857073bcbc76c]
 5: OFFSET=(0x0000296d      10605) ID=(0xda) NAME=[SOS  ] SIZE=(         0) SHA1=[da39a3ee5e6b4b0d3255bfef95601890afd80709]
 6: OFFSET=(0x0000296f      10607) ID=(0x00) NAME=[     ] SIZE=(   1567089) SHA1=[d30f587551f61c27dac6cffebfeab26021faab35]
 7: OFFSET=(0x001812e0    1577696) ID=(0xd9) NAME=[EOI  ] SIZE=(         0) SHA1=[da39a3ee5e6b4b0d3255bfef95601890afd80709]

@lastzero You have seen XMP data/properties in JPEGs, before? That's interesting. If it was a bit more prevalent, I'd be interested in supporting it, though that did not end-up being the case, here.

When I dumped the EXIF data, it looks like that 9004 tag is being used in a non-standard place (in the IFD0 IFD rather than the EXIF IFD), so we just ignore it:

$ go run exif-read-tool/main.go -filepath 2011-07-19\ 11.36.39.jpg 
WARNING: Unknown tag: [IFD] (a403)
WARNING: Unknown tag: [IFD] (9004)
WARNING: Unknown tag: [IFD] (9286)
IFD-PATH=[IFD] ID=(0x829a) NAME=[ExposureTime] COUNT=(1) TYPE=[SRATIONAL] VALUE=[9/10000]
IFD-PATH=[IFD] ID=(0x0110) NAME=[Model] COUNT=(10) TYPE=[ASCII] VALUE=[GT-I9000]
...

Looking through Phil's code, it looks like it's in a non-standard place for him, too. He must just be backing off to a IFD-agnostic search for the tag within his lookup. This is rare and I don't really like to encourage this kind of behavior (I'm referring to the suites or manufacturers, now), but at least we can provide some help to the poor individual who needs their data at any cost. https://github.com/dsoprea/go-jpeg-image-structure/issues/11

I'll take a look at the header thing, which I don't actually see any mention of, above.

@dsoprea commented on GitHub (May 16, 2020): Okay, so there's a couple of things. First, the tag is 0x9004, as shown here: ``` 0x9209 Flash : Off, Did not fire 0x9004 Create Date : 2011:07:19 11:36:38 - Warning : Invalid EXIF text encoding for UserComment 0x9286 User Comment : focus:Tut ``` The proper tag name, per the spec and the go-exif config, is "DateTimeDigitized". I had checked the segments for XMP data, but there was no extra data there (I know that this was just a suggestion on your part): ``` $ go run command/js_dump/main.go -f "xmp_in_jpeg_maybe__2011-07-19 11.36.39.jpg" JPEG Segments: 0: OFFSET=(0x00000000 0) ID=(0xd8) NAME=[SOI ] SIZE=( 0) SHA1=[da39a3ee5e6b4b0d3255bfef95601890afd80709] 1: OFFSET=(0x00000002 2) ID=(0xe1) NAME=[APP1 ] SIZE=( 9961) SHA1=[8b6438e621ef10eb67777818acb566a9f3fe3408] 2: OFFSET=(0x000026ef 9967) ID=(0xdb) NAME=[DQT ] SIZE=( 195) SHA1=[f089585c94d9a5fceae3a31052385643fc815f34] 3: OFFSET=(0x000027b6 10166) ID=(0xc0) NAME=[SOF0 ] SIZE=( 15) SHA1=[460981aa028f49eff5904447a250e39520ea77a5] 4: OFFSET=(0x000027c9 10185) ID=(0xc4) NAME=[DHT ] SIZE=( 416) SHA1=[8f8ba97c8f26fdfe46a09f523ee857073bcbc76c] 5: OFFSET=(0x0000296d 10605) ID=(0xda) NAME=[SOS ] SIZE=( 0) SHA1=[da39a3ee5e6b4b0d3255bfef95601890afd80709] 6: OFFSET=(0x0000296f 10607) ID=(0x00) NAME=[ ] SIZE=( 1567089) SHA1=[d30f587551f61c27dac6cffebfeab26021faab35] 7: OFFSET=(0x001812e0 1577696) ID=(0xd9) NAME=[EOI ] SIZE=( 0) SHA1=[da39a3ee5e6b4b0d3255bfef95601890afd80709] ``` @lastzero You have seen XMP data/properties in JPEGs, before? That's interesting. If it was a bit more prevalent, I'd be interested in supporting it, though that did not end-up being the case, here. When I dumped the EXIF data, it looks like that 9004 tag is being used in a non-standard place (in the IFD0 IFD rather than the EXIF IFD), so we just ignore it: ``` $ go run exif-read-tool/main.go -filepath 2011-07-19\ 11.36.39.jpg WARNING: Unknown tag: [IFD] (a403) WARNING: Unknown tag: [IFD] (9004) WARNING: Unknown tag: [IFD] (9286) IFD-PATH=[IFD] ID=(0x829a) NAME=[ExposureTime] COUNT=(1) TYPE=[SRATIONAL] VALUE=[9/10000] IFD-PATH=[IFD] ID=(0x0110) NAME=[Model] COUNT=(10) TYPE=[ASCII] VALUE=[GT-I9000] ... ``` Looking through Phil's code, it looks like it's in a non-standard place for him, too. He must just be backing off to a IFD-agnostic search for the tag within his lookup. This is rare and I don't really like to encourage this kind of behavior (I'm referring to the suites or manufacturers, now), but at least we can provide some help to the poor individual who needs their data at any cost. https://github.com/dsoprea/go-jpeg-image-structure/issues/11 I'll take a look at the header thing, which I don't actually see any mention of, above.

deekerman commented

2026-02-19 23:05:03 -05:00

Author

Owner

@lastzero commented on GitHub (May 16, 2020):

The proper tag name, per the spec and the go-exif config, is "DateTimeDigitized".

Added that to our list of fallback values for DateTimeOriginal (TakenAt in our database).

I had checked the segments for XMP data, but there was no extra data there (I know that this was just a suggestion on your part):

Good to know, was on my todo but didn't have time yesterday. Thanks for checking!

@lastzero You have seen XMP data/properties in JPEGs, before? That's interesting. If it was a bit more prevalent, I'd be interested in supporting it, though that did not end-up being the case, here.

Yes, at least Adobe is doing it (probably whenever you edit metadata in Lightroom and maybe even Photoshop): https://github.com/photoprism/photoprism/issues/243#issuecomment-583728781

The ladybug jpeg should contain Exif and XMP data segments: https://github.com/photoprism/photoprism/tree/develop/internal/meta/testdata

@lastzero commented on GitHub (May 16, 2020): > The proper tag name, per the spec and the go-exif config, is "DateTimeDigitized". Added that to our list of fallback values for `DateTimeOriginal` (`TakenAt` in our database). > I had checked the segments for XMP data, but there was no extra data there (I know that this was just a suggestion on your part): Good to know, was on my todo but didn't have time yesterday. Thanks for checking! > @lastzero You have seen XMP data/properties in JPEGs, before? That's interesting. If it was a bit more prevalent, I'd be interested in supporting it, though that did not end-up being the case, here. Yes, at least Adobe is doing it (probably whenever you edit metadata in Lightroom and maybe even Photoshop): https://github.com/photoprism/photoprism/issues/243#issuecomment-583728781 The ladybug jpeg should contain Exif and XMP data segments: https://github.com/photoprism/photoprism/tree/develop/internal/meta/testdata

deekerman commented

2026-02-19 23:05:03 -05:00

Author

Owner

@alxjsn commented on GitHub (May 16, 2020):

@alxjsn That's why we added the quality filter. If we always move them to the end and you have 50k+ photos, like we do, you will never see them in practice.

Can we have that same behavior for videos? Currently videos without dates show up in the main view as well. I uploaded a video to demo as an example.

@alxjsn commented on GitHub (May 16, 2020): > @alxjsn That's why we added the quality filter. If we always move them to the end and you have 50k+ photos, like we do, you will never see them in practice. Can we have that same behavior for videos? Currently videos without dates show up in the main view as well. I uploaded a video to demo as an example.

deekerman commented

2026-02-19 23:05:03 -05:00

Author

Owner

@lastzero commented on GitHub (May 16, 2020):

We currently need exiftool to get the date, so all videos might end up in review with sidecar-json turned off.

@lastzero commented on GitHub (May 16, 2020): We currently need exiftool to get the date, so all videos might end up in review with sidecar-json turned off.

deekerman commented

2026-02-19 23:05:03 -05:00

Author

Owner

@lastzero commented on GitHub (May 20, 2020):

@don-sh Docker build that can read dates from file names is soon available, see https://travis-ci.org/github/photoprism/photoprism/builds/689233399 for current status

Please test, I'm going to the park now and will be back later :)

@lastzero commented on GitHub (May 20, 2020): @don-sh Docker build that can read dates from file names is soon available, see https://travis-ci.org/github/photoprism/photoprism/builds/689233399 for current status Please test, I'm going to the park now and will be back later :)

deekerman commented

2026-02-19 23:05:03 -05:00

Author

Owner

@don-sh commented on GitHub (May 21, 2020):

Great, you actually did it! Thanks.

I will test it next week - after the holidays.

EDIT:
@lastzero I just tested some sample pictures and it worked quite well! I had to delete the docker volumes to make it work though (re-indexing also didn't help).
WhatsApp
2014-08-25_17.15.33.jpg ✓
IMG-20161224-WA0014.jpg ✓
VID-20161223-WA0000.mp4 ✓
Signal
signal-2018-08-21-100217.jpg ✓
signal-2020-05-07-222654.mp4 ✓
Android screen capture
Screenshot_20190201-212530_Fennec_F-Droid.png ✕
This is not really a problem for me as I only have a handful of those.

I will do a new import of my whole library now and report if I find any issues.

EDIT2:
No more issues after re-importing my whole library.

@don-sh commented on GitHub (May 21, 2020): Great, you actually did it! Thanks. I will test it next week - after the holidays. EDIT: @lastzero I just tested some sample pictures and it worked quite well! I had to delete the docker volumes to make it work though (re-indexing also didn't help). **WhatsApp** 2014-08-25_17.15.33.jpg ✓ IMG-20161224-WA0014.jpg ✓ VID-20161223-WA0000.mp4 ✓ **Signal** signal-2018-08-21-100217.jpg ✓ signal-2020-05-07-222654.mp4 ✓ **Android screen capture** Screenshot_20190201-212530_Fennec_F-Droid.png ✕ This is not really a problem for me as I only have a handful of those. I will do a new import of my whole library now and report if I find any issues. EDIT2: No more issues after re-importing my whole library.

deekerman referenced this issue

2026-02-19 23:10:18 -05:00

Show original image when clicking on it #518

deekerman referenced this issue

2026-02-20 00:02:28 -05:00

UX: Add a hybrid Photo/Video Viewer (Lightbox) #953

Rows
Columns

Date not recognized / Date from picture name #247