Return if photo was uploaded but not yet processed about librephotos HOT 13 CLOSED

I closed the accompanying UhuruPhotos ticket. Happy with this as is so feel free to close it unless you feel there should be more work done

from librephotos.

Will thumbnail existence be enough of a proof the item is ready to be fetched by the /api/photos/{id}/summary/ endpoint?

That is the thing that is ultimately needed by clients like UhuruPhotos to mark the uploaded item as synced and display the remote data for it on the item details page.

from librephotos.

An alternative would be to get the api/photos/{id}/summary/ endpoint itself return some pending status so there is no need for multiple api calls but the /exists endpoint would work too

from librephotos.

There is now a new field called "processing" in the response of the api/photos/{id}/summary/. If it is true, the file was successfully uploaded, but has not finished processing yet.

Currently we only check for the existence of the thumbnails, testing if that is enough would be great :)

from librephotos.

Hm so this is interesting. In the latest dev, after uploading a rather large video, right after the complete call is made, so before the video has finished processing, calling the above api returns a 200 with the following body:

{
    "photo_summary": {
        "id": "1cb3322d5f9e38f03080e3a6c5b0bc2c1",
        "dominantColor": "",
        "url": "1cb3322d5f9e38f03080e3a6c5b0bc2c1",
        "location": "",
        "date": "",
        "birthTime": "",
        "aspectRatio": null,
        "type": "video",
        "video_length": "",
        "rating": 0,
        "owner": {
            "id": 1,
            "username": "kurosavvas",
            "first_name": "Savvas",
            "last_name": "Dalkitsis"
        }
    },
    "album_date_id": null,
    "processing": false
}

Notice that processing is false, there is a body for the photo_summary but things like album date, aspect ratio, etc is missing. The client would not be able to process this response properly :/

Calling the api again after a while returns the full response:

{
    "photo_summary": {
        "id": "1cb3322d5f9e38f03080e3a6c5b0bc2c1",
        "dominantColor": "#ccb69f",
        "url": "1cb3322d5f9e38f03080e3a6c5b0bc2c1",
        "location": "",
        "date": "2024-01-28T22:51:47+00:00",
        "birthTime": "2024-01-28T22:51:47Z",
        "aspectRatio": 0.56,
        "type": "video",
        "video_length": "19.8198",
        "rating": 0,
        "owner": {
            "id": 1,
            "username": "kurosavvas",
            "first_name": "Savvas",
            "last_name": "Dalkitsis"
        }
    },
    "album_date_id": 1633,
    "processing": false
}

from librephotos.

Also note that calling the api with a completely made up hash returns a 404 with an empty body, not a response with 'processing = false` as i would expect if my assumption was correct that for a processing item we'd get a 404 with the field true but for a truly missing item, we'd get a 404 with the processing field = false

from librephotos.

I am not sure why the check is not working for videos. I use now aspect_ratio instead, which is calculated after creating thumbnails, which should also work.

Not sure if I agree, that an photo, that does exist should return 404.

My mental model is that 404 means the image does not exist at all and should be uploaded, 200 with processing = true means, it was uploaded but not yet processed, 200 with processing=false means was uploaded and processed.

from librephotos.

Hm it seems I am getting the same behaviour unless the dev image hasn't updated yet?

{
    "photo_summary": {
        "id": "4521bdd19748a9b63786a95916c3792a1",
        "dominantColor": "",
        "url": "4521bdd19748a9b63786a95916c3792a1",
        "location": "",
        "date": "",
        "birthTime": "",
        "aspectRatio": null,
        "type": "video",
        "video_length": "",
        "rating": 0,
        "owner": {
            "id": 1,
            "username": "kurosavvas",
            "first_name": "Savvas",
            "last_name": "Dalkitsis"
        }
    },
    "album_date_id": null,
    "processing": false
}

As far as the code goes, I don't have strong feelings either way tbh. I only assumed a 404 cause, semantically, until the media has finished processing, the summary of the media is not found so 404 🤷 But like i said, don't mind either way

from librephotos.

According to docker hub the new image was uploaded and should be available. I uploaded a couple of videos, while preventing them from getting processed and it returned this, which looks correct.

{
  "photo_summary": {
    "id": "7c2b8fab486bfcebd2dd9355c72ae3101",
    "dominantColor": "",
    "url": "7c2b8fab486bfcebd2dd9355c72ae3101",
    "location": "",
    "date": "",
    "birthTime": "",
    "aspectRatio": null,
    "type": "video",
    "video_length": "",
    "rating": 0,
    "owner": {
      "id": 1,
      "username": "admin",
      "first_name": "Niaz",
      "last_name": "Faridani-Rad"
    }
  },
  "album_date_id": null,
  "processing": true
}

from librephotos.

Very weird. I still cannot get this to report processing true. I guess I could just use the album_date_id being not null as an indicator as that is the main key the app is using to assing the media into the user's feed as well as the processing field and it should cover all cases

from librephotos.

I added some automated testing in this class here and all the tests pass and return true or false based on the aspect ratio property:

https://github.com/LibrePhotos/librephotos/blob/dev/api/tests/test_photo_summary.py

I found a bug, where non admin users e.g. a second user could not reach the summary endpoint and would get a 403 error instead. Could that explain, why it did continuously upload for some users?

from librephotos.

Hm that could perhaps also be contributing. Would be nice to fix that alongside with this

from librephotos.

Alright, added a fix for the 403 error too :)

from librephotos.