Skip to content

Query for most recent photos returns wrong data #3764

Open
Open
Query for most recent photos returns wrong data#3764
Labels
0. Needs triagePending approval or rejection. This issue is pending approval.bugSomething isn't working

Description

@svenb1234
svenb1234
opened on Aug 18, 2026

Describe the bug
The photos app queries for the last modified photos and gets a wrong answer, i.e. not the most recent pictures, but older ones.

To Reproduce
Steps to reproduce the behavior:

  1. Go to the photos app
  2. See old pictures

Expected behavior
The most recent pictures sorted by creation date.

Desktop (please complete the following information):

  • OS: Windows 11
  • Browser Firefox
  • Version 153.0.4

Nextcloud 33.0.7 AIO on Linux

Browser log

Request:

<?xml version="1.0" encoding="UTF-8"?>
		<d:searchrequest xmlns:d="DAV:"
			xmlns:oc="http://owncloud.org/ns"
			xmlns:nc="http://nextcloud.org/ns"
			xmlns:ns="https://github.com/icewind1991/SearchDAV/ns"
			xmlns:ocs="http://open-collaboration-services.org/ns">
			<d:basicsearch>
				<d:select>
					<d:prop>
						<d:getcontentlength /> <d:getcontenttype /> <d:getetag /> <d:getlastmodified /> <d:creationdate /> <d:displayname /> <d:quota-available-bytes /> <d:resourcetype /> <nc:has-preview /> <nc:is-encrypted /> <nc:mount-type /> <oc:comments-unread /> <oc:favorite /> <oc:fileid /> <oc:owner-display-name /> <oc:owner-id /> <oc:permissions /> <oc:size /> <nc:metadata-photos-exif /> <nc:metadata-photos-ifd0 /> <nc:metadata-photos-gps /> <nc:metadata-photos-place /> <nc:metadata-photos-size /> <nc:metadata-files-live-photo /> <nc:metadata-blurhash /> <nc:metadata-photos-original_date_time />
					</d:prop>
				</d:select>
				<d:from>
					
			<d:scope>
				<d:href>/files/username/Familienfotos</d:href>
				<d:depth>infinity</d:depth>
			</d:scope>
				</d:from>
				<d:where>
					<d:and>
						<d:or>
							
		<d:eq>
			<d:prop>
				<d:getcontenttype/>
			</d:prop>
			<d:literal>image/png</d:literal>
		</d:eq>
	
		<d:eq>
			<d:prop>
				<d:getcontenttype/>
			</d:prop>
			<d:literal>image/jpeg</d:literal>
		</d:eq>
	
		<d:eq>
			<d:prop>
				<d:getcontenttype/>
			</d:prop>
			<d:literal>image/heic</d:literal>
		</d:eq>
	
		<d:eq>
			<d:prop>
				<d:getcontenttype/>
			</d:prop>
			<d:literal>image/webp</d:literal>
		</d:eq>
	
		<d:eq>
			<d:prop>
				<d:getcontenttype/>
			</d:prop>
			<d:literal>video/mp4</d:literal>
		</d:eq>
	
		<d:eq>
			<d:prop>
				<d:getcontenttype/>
			</d:prop>
			<d:literal>video/quicktime</d:literal>
		</d:eq>
	
						</d:or>
						
						
						
					</d:and>
				</d:where>
				<d:orderby>
					<d:order>
						<d:prop><nc:metadata-photos-original_date_time/></d:prop>
						<d:descending/>
					</d:order>
					<d:order>
						<d:prop><d:getlastmodified/></d:prop>
						<d:descending/>
					</d:order>
				</d:orderby>
				<d:limit>
					<d:nresults>200</d:nresults>
					<ns:firstresult>200</ns:firstresult>
				</d:limit>
			</d:basicsearch>
		</d:searchrequest>

Question, why <d:href>/files/username/Familienfotos</d:href> instead of username/files/Familienfotos as the real path is.

RESULT (part):

<?xml version="1.0"?>
<d:multistatus xmlns:d="DAV:" xmlns:s="http://sabredav.org/ns" xmlns:oc="http://owncloud.org/ns" xmlns:nc="http://nextcloud.org/ns"><d:response><d:href>/remote.php/dav/files/username/Familienfotos/Name%20Telefon/Camera/PXL_20260711_140315297.jpg</d:href><d:propstat><d:prop><d:getcontentlength>3646264</d:getcontentlength><d:getcontenttype>image/jpeg</d:getcontenttype><d:getetag>&quot;4a567cbeead8d91223046b42667847cd&quot;</d:getetag><d:getlastmodified>Sat, 11 Jul 2026 14:03:17 GMT</d:getlastmodified><d:creationdate>2026-07-11T14:03:17+00:00</d:creationdate><d:displayname>PXL_20260711_140315297.jpg</d:displayname><d:resourcetype/><nc:has-preview>true</nc:has-preview><nc:mount-type></nc:mount-type><oc:comments-unread>0</oc:comments-unread><oc:favorite>0</oc:favorite><oc:fileid>2477002</oc:fileid><oc:owner-display-name>Username</oc:owner-display-name><oc:owner-id>username</oc:owner-id><oc:permissions>RGDNVW</oc:permissions><oc:size>3646264</oc:size></d:prop><d:status>HTTP/1.1 200 OK</d:status></d:propstat><d:propstat><d:prop><d:quota-available-bytes/><nc:is-encrypted/><nc:metadata-photos-exif/><nc:metadata-photos-ifd0/><nc:metadata-photos-gps/><nc:metadata-photos-place/><nc:metadata-photos-size/><nc:metadata-files-live-photo/><nc:metadata-blurhash/><nc:metadata-photos-original_date_time/></d:prop><d:status>HTTP/1.1 404 Not Found</d:status></d:propstat></d:response><d:response><d:href>/remote.php/dav/files/username/Familienfotos/Extern%202025/Name%20in%20Frankfurt/20250531_121624.jpg</d:href><d:propstat><d:prop><d:getcontentlength>3145313</d:getcontentlength><d:getcontenttype>image/jpeg</d:getcontenttype><d:getetag>&quot;9f1d87b9e5109943a8ba34d02ed9a4bb&quot;</d:getetag><d:getlastmodified>Sun, 01 Jun 2025 18:35:25 GMT</d:getlastmodified><d:creationdate>1970-01-01T00:00:00+00:00</d:creationdate><d:displayname>20250531_121624.jpg</d:displayname><d:resourcetype/><nc:has-preview>true</nc:has-preview><nc:mount-type></nc:mount-type><oc:comments-unread>0</oc:comments-unread><oc:favorite>0</oc:favorite><oc:fileid>674368</oc:fileid><oc:owner-display-name>Username</oc:owner-display-name><oc:owner-id>username</oc:owner-id><oc:permissions>RGDNVW</oc:permissions><oc:size>3145313</oc:size></d:prop><d:status>HTTP/1.1 200 OK</d:status></d:propstat><d:propstat><d:prop><d:quota-available-bytes/><nc:is-encrypted/><nc:metadata-photos-exif/><nc:metadata-photos-ifd0/><nc:metadata-photos-gps/><nc:metadata-photos-place/><nc:metadata-photos-size/><nc:metadata-files-live-photo/><nc:metadata-blurhash/><nc:metadata-photos-original_date_time/></d:prop><d:status>HTTP/1.1 404 Not Found</d:status></d:propstat></d:response><d:response><d:href>/remote.php/dav/files/username/Familienfotos/Extern%202025/Name%20in%20Frankfurt/20250531_121151.jpg</d:href><d:propstat><d:prop><d:getcontentlength>3520748</d:getcontentlength><d:getcontenttype>image/jpeg</...

Querying the DB directly:

SELECT f.fileid, f.name, f.mtime, fe.creation_time
FROM oc_filecache f
LEFT JOIN oc_filecache_extended fe ON f.fileid = fe.fileid
WHERE f.path LIKE 'files/username/Familienfotos/%'
ORDER BY fe.creation_time DESC NULLS LAST, f.mtime DESC;

Does not return anything. Correcting the path to files/Familienfotos.

SELECT f.fileid, f.name, f.mtime, fe.creation_time
FROM oc_filecache f
LEFT JOIN oc_filecache_extended fe ON f.fileid = fe.fileid
WHERE f.path LIKE 'files/Familienfotos/%'
ORDER BY fe.creation_time DESC NULLS LAST, f.mtime DESC;

returns the correct pictures.

SELECT f.fileid, f.path, f.mimetype, fe.creation_time
FROM oc_filecache f
LEFT JOIN oc_filecache_extended fe ON f.fileid = fe.fileid
WHERE f.name = 'PXL_20260814_093203988.jpg';
 fileid  |                                path                                | mimetype | creation_time
---------+--------------------------------------------------------------------+----------+---------------
 2481338 | files/Familienfotos/Name Telefon/Camera/PXL_20260814_093203988.jpg |        4 |    1786699926

SELECT
    f.fileid,
    f.name,
    f.mtime,
    fe.creation_time,
    fe.upload_time
FROM oc_filecache f
LEFT JOIN oc_filecache_extended fe ON f.fileid = fe.fileid
WHERE f.name = 'PXL_20260814_093203988.jpg';
 fileid  |            name            |   mtime    | creation_time | upload_time
---------+----------------------------+------------+---------------+-------------
 2481338 | PXL_20260814_093203988.jpg | 1786699926 |    1786699926 |  1786699944
(1 row)

So everything should be there to fetch the correct photos.

Activity

  1. svenb1234
    added
    bugSomething isn't working
    0. Needs triagePending approval or rejection. This issue is pending approval.
    on Aug 18, 2026
  2. susnux
    added this to 🧑‍🤝‍🧑 Community triageon Aug 18, 2026
  3. susnux
    moved this to To triage in 🧑‍🤝‍🧑 Community triageon Aug 18, 2026
  4. come-nc
    moved this from To triage to Triaged in 🧑‍🤝‍🧑 Community triageon Aug 20, 2026

  5. come-nc commented on Aug 20, 2026

    @come-nc
    come-nc
    on Aug 20, 2026
    Contributor

    Hello,

    It’s not clear for me, are you saying that the result are in the wrong order or are the wrong photos?
    Regarding the file path, I’m not sure the dav path and the path in DB follow the same logic.

  6. svenb1234 commented on Aug 20, 2026

    @svenb1234
    svenb1234
    on Aug 20, 2026
    Author

    The photos are neither the last ones uploaded nor the ones with the most recent date taken.
    Example, the first picture the Photos app shows is from July 2026, while there are many with a more recent date.
    The next pictures the photo app shows are from June 2025.

  7. svenb1234 commented on Aug 28, 2026

    @svenb1234
    svenb1234
    on Aug 28, 2026
    Author

    FWIW, the android client does show the recently uploaded pictures in its media tab.

  8. drm87 commented on Sep 2, 2026

    @drm87
    drm87
    on Sep 2, 2026

    I can confirm this on my nextcloud instance (34.0.3) and with the iOS nextcloud app.

  9. svenb1234 commented on Sep 24, 2026

    @svenb1234
    svenb1234
    on Sep 24, 2026
    Author

    It seems that only photos are shown which were uploaded manually, i.e. via the web interface or shared with the android app. Those uploaded by the android app automatically, do not show up. Not sure what to make of this.

  10. Termindiego25 commented on Oct 15, 2026

    @Termindiego25
    Termindiego25
    on Oct 15, 2026 – with ChatGPT Codex Connector

    I reproduced a related issue on Nextcloud Server 34.0.4, Photos 7.0.0 and PostgreSQL and isolated an apparent server-side ordering defect with a sanitized HAR analysis. I've filed the full technical analysis at nextcloud/server#65562.

    Evidence: Four consecutive WebDAV SEARCH pages (offsets 0/200/400/600, nresults=200) all returned HTTP 207 and 200 items, but response times were 0.40 s, 0.36 s, 206.64 s, and 71.66 s. Each returned page was ordered by getlastmodified DESC, while the requested primary nc:metadata-photos-original_date_time DESC was not preserved. File IDs 7366 and 7369 appeared on both pages 400 and 600 (800 returned entries, 798 unique). 295 large videos still lacked indexed capture dates at capture time, though >12,600 other media items already had indexed dates.

    Potential code paths:

    • In server's apps/dav/lib/Files/FileSearchBackend.php, SEARCH re-sorts the already paginated results in PHP when !$query->limitToHome(). The comparator's getSearchResultProperty() returns null for indexed custom metadata keys, so its secondary mtime comparison appears to override the primary requested metadata order. The pre-sort database offset/limit and post-sort PHP order may consequently disagree.
    • In Photos' src/composables/useFetchFiles.ts, firstResult: fetchedFileIds.value.length uses the deduplicated list length rather than the number of items returned by the server; overlapping pages can cause the next offset to regress (e.g. 798 instead of 800).

    These observations suggest two interacting issues; the slow responses may have a separate cause. Fixing the client offset will not fix the server-side sort; both should have regression coverage for equal/missing timestamps and page boundaries.

    The screenshot/UI configuration indicates photosSourceFolders=['/'] (all folders). After metadata recovery, individual month filters find hundreds of indexed photos, but the unfiltered All Media timeline skips many months or loads older files only after extensive scrolling. No raw HAR attached because it contains private paths/session information.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    0. Needs triagePending approval or rejection. This issue is pending approval.bugSomething isn't working

    Type

    No type

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions