[Bug]: When sorted by Relevance, infinite loading seems to be wrong

[toperichvania]

Checklist

• I have updated to the latest available Frigate version.
• I have cleared the cache of my browser.
• I have tried a different browser to see if it is related to my browser.
• I have tried reproducing the issue in incognito mode to rule out problems with any third party extensions or plugins I have installed.

Describe the problem you are having

When searching similar, sorting by default is on Relevance. First 25 results are loaded and sorted by score, and then when scrolling down, infinite loading will send a new API request that would include ID of similar object and before=time_stamp of the last of those 25 received objects. Would one not expect to get then results with lower score then?

I might be missing the concept though.

Steps to reproduce

...

Version

0.15.0

In which browser(s) are you experiencing the issue with?

No response

Frigate config file

-

docker-compose file or Docker CLI command

-

Relevant Frigate log output

-

Relevant go2rtc log output

-

Operating system

Other Linux

Install method

Docker Compose

Network connection

Wired

Camera make and model

Panasonic

Screenshots of the Frigate UI's System metrics pages

Any other information that may be helpful

{
"id": "1743672660.518226-hfgh84",
"camera": "PTZ",
"label": "car",
"sub_label": null,
"zones": [],
"start_time": 1743672660.518226,
"end_time": 1743672672.51286,
"has_clip": true,
"has_snapshot": true,
"top_score": null,
"plus_id": null,
"thumb_path": "/media/frigate/clips/review/thumb-PTZ-1743655442.924149-6nynlw.webp",
"data": {
"score": 0.9638845920562744,
"top_score": 0.96484375,
"type": "object"
},
"search_distance": 0.09235836565494537,
"search_source": "thumbnail"
}

before=1743672660.518226


{
    "id": "1743656574.544879-sdlt5p",
    "camera": "PTZ",
    "label": "car",
    "sub_label": null,
    "zones": [],
    "start_time": 1743656574.544879,
    "end_time": 1743656585.554547,
    "has_clip": true,
    "has_snapshot": true,
    "top_score": null,
    "plus_id": null,
    "thumb_path": "/media/frigate/clips/review/thumb-PTZ-1743655442.924149-6nynlw.webp",
    "data": {
        "score": 0.9458270072937012,
        "top_score": 0.96728515625,
        "type": "object"
    },
    "search_distance": 0.09582187980413437,
    "search_source": "thumbnail"
}

before=1743656574.544879

[NickM-27]

it's not really clear what you mean, it is loading objects in order of similarity to the image that was originally searched on

[toperichvania]

For the first 25 results, ordering is set by "search_distance" in descending. Then when another 25 are requested, request sent to API is including "before" which has a value of start_time of the last of the above 25 received objects with a lowest "search_distance". Now I would expect that next 25 results are continuing in relevance to the "search_distance" but they are new search, that takes ID and timestamp and then next 25 results that come will have "search_distance" that is similar to first 25 results. But sorting is on relevance so shouldn't that be criteria for those next 25 results. I might be misunderstanding the search_distance and how it is calculated though...

[NickM-27]

Because the results are sorted by similarity, the vast majority of good matches will come in the first 25 results. The search API already has a full list of events that match, sorted by distance, so using the before date is the easiest way to pull a new page of objects. Technically, there is some chance that matching events are excluded, but paginating directly on the search distance will greatly complicate the APIs implementation.

[toperichvania]

Thank you for clarification