starred/photoprism

Fork 0

mirror of https://github.com/photoprism/photoprism.git synced 2026-03-02 22:57:18 -05:00

UX: Auto refresh library to show edits to primary photos, stacks, timestamps, etc. #784

New issue

Open

opened 2026-02-19 23:16:27 -05:00 by deekerman · 8 comments

deekerman commented

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

Owner

Originally created by @inthreedee on GitHub (Feb 12, 2021).

Feature request
After making edits to a photo and returning to the library view, immediately show those edits instead of requiring the user to manually refresh the entire page to see the changes. A manual refresh causes the user to start over at the top of their library each time, having to scroll back down to the spot where they were working.

I've noticed this in the following situations:

Newly unstacked photos do not appear in the library until I manually refresh the page.
When editing date/timestamps, the photo does not automatically move to the corrected position in my library.
When changing the primary photo in a stack, the old primary photo remains displayed until I manually refresh the page.

This can be a frustrating process when making edits to multiple files. It's hard to keep track of which photos I've done and which one is next when the changes are not immediately displayed. Manually refreshing after each edit means losing my place entirely and having to scroll back down to find my place again before I can continue working.

Example repro steps:

Scroll down a few pages deep into your library and select a stacked photo. For example, a photo with an original and a rotated edit.
Unstack the rotated photo.
Close the edit screen to return to the library view. The unstacked photo is not there.
Manually refresh the page.
Now you are at the top of your library. Scroll back down to find the photo you were working on. Find it and you can continue making further edits.

Version

210128-a82061e0-Linux-aarch64

(edited for clarity)

Originally created by @inthreedee on GitHub (Feb 12, 2021). **Feature request** After making edits to a photo and returning to the library view, immediately show those edits instead of requiring the user to manually refresh the entire page to see the changes. A manual refresh causes the user to start over at the top of their library each time, having to scroll back down to the spot where they were working. I've noticed this in the following situations: - Newly unstacked photos do not appear in the library until I manually refresh the page. - When editing date/timestamps, the photo does not automatically move to the corrected position in my library. - When changing the primary photo in a stack, the old primary photo remains displayed until I manually refresh the page. This can be a frustrating process when making edits to multiple files. It's hard to keep track of which photos I've done and which one is next when the changes are not immediately displayed. Manually refreshing after each edit means losing my place entirely and having to scroll back down to find my place again before I can continue working. **Example repro steps:** 1. Scroll down a few pages deep into your library and select a stacked photo. For example, a photo with an original and a rotated edit. 2. Unstack the rotated photo. 3. Close the edit screen to return to the library view. The unstacked photo is not there. 4. Manually refresh the page. 5. Now you are at the top of your library. Scroll back down to find the photo you were working on. Find it and you can continue making further edits. **Version** 210128-a82061e0-Linux-aarch64 (edited for clarity)

deekerman added the

idea

low-priority

labels

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

deekerman commented

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

Author

Owner

@lastzero commented on GitHub (Feb 13, 2021):

Metadata should update already, except the primary image in search results (does update in the edit dialog for confirmation).

@lastzero commented on GitHub (Feb 13, 2021): Metadata should update already, except the primary image in search results (does update in the edit dialog for confirmation).

deekerman commented

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

Author

Owner

@inthreedee commented on GitHub (Feb 13, 2021):

I didn't mean to imply that the edits aren't saved; they are. But date and primary photo changes do not appear in the library view unless the entire page is manually refreshed.

As I mentioned, all this causes some issues with losing your place when editing groups of photos. If this isn't implemented yet, please consider it a feature request.

@inthreedee commented on GitHub (Feb 13, 2021): I didn't mean to imply that the edits aren't saved; they are. But date and primary photo changes do not appear in the library view unless the entire page is manually refreshed. As I mentioned, all this causes some issues with losing your place when editing groups of photos. If this isn't implemented yet, please consider it a feature request.

deekerman commented

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

Author

Owner

@lastzero commented on GitHub (Feb 13, 2021):

Just tested changing the date and it works... Only the position isn't changed as that requires sorting which is done server side. This is intentional in case you've made a mistake. Otherwise you have a hard time finding the photo again.

@lastzero commented on GitHub (Feb 13, 2021): Just tested changing the date and it works... Only the position isn't changed as that requires sorting which is done server side. This is intentional in case you've made a mistake. Otherwise you have a hard time finding the photo again.

deekerman commented

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

Author

Owner

@inthreedee commented on GitHub (Feb 13, 2021):

I see, so this is intentional. There are two reasons I believe this behavior should be changed:

I understand the concern about the user making a mistake and then having trouble finding the photo. I would argue that's why photos are automatically tagged and you provide a search function. If a mistake is made, the user can search for the photo.
The current behavior causes too much of an inconvenience for users who are trying to edit multiple photos. Therefore, the search function is a better solution to the problem of mistakes being made.

To elaborate on number 2:

I thought my server was broken because my edits weren't being reflected in my library view. I kept re-editing the file, not knowing that I had to manually refresh for the edits to show up. This is unusual behavior for a photo organizer, so it was unexpected.
If I'm editing a group of, for example, 20 photos and changing dates or primary photos in a stack, I keep losing my place. It's hard to know which photo I need to edit next when the changes/sorting are not immediately displayed in my library.
Manually refreshing means losing my place while editing multiple photos. I have to scroll back down to the group I'm editing every single time. This makes the process more tedious than it needs to be.

I hope that clarifies my request.

@inthreedee commented on GitHub (Feb 13, 2021): I see, so this is intentional. There are two reasons I believe this behavior should be changed: 1. I understand the concern about the user making a mistake and then having trouble finding the photo. I would argue that's why photos are automatically tagged and you provide a search function. If a mistake is made, the user can search for the photo. 2. The current behavior causes too much of an inconvenience for users who are trying to edit multiple photos. Therefore, the search function is a better solution to the problem of mistakes being made. To elaborate on number 2: - I thought my server was broken because my edits weren't being reflected in my library view. I kept re-editing the file, not knowing that I had to manually refresh for the edits to show up. This is unusual behavior for a photo organizer, so it was unexpected. - If I'm editing a group of, for example, 20 photos and changing dates or primary photos in a stack, I keep losing my place. It's hard to know which photo I need to edit next when the changes/sorting are not immediately displayed in my library. - Manually refreshing means losing my place while editing multiple photos. I have to scroll back down to the group I'm editing every single time. This makes the process more tedious than it needs to be. I hope that clarifies my request.

deekerman commented

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

Author

Owner

@lastzero commented on GitHub (Feb 13, 2021):

Check the date field, it is updated. There is no need to think the server is broken unless you don't take a look at the metadata, or don't see it because you're using the Mosaic view.

Note:

We push updates from the server to the client. Sorting requires a server request to be complete and consistent. Thus when multiple users edit photos, all views would continuously reload - maybe more than 1000 results each.
Alternatively, we may implement client-sorting and implement other complex logic to deal with this. This would take a lot of time and may introduce tons of bugs.
Batch edit is already on our roadmap and would be delayed by this.
We thought a lot about the current solution and are willing to improve it further at a later time after getting more feedback. You're the first user who reports this as an issue.

@lastzero commented on GitHub (Feb 13, 2021): Check the date field, it is updated. There is no need to think the server is broken unless you don't take a look at the metadata, or don't see it because you're using the Mosaic view. Note: - We push updates from the server to the client. Sorting requires a server request to be complete and consistent. Thus when multiple users edit photos, all views would continuously reload - maybe more than 1000 results each. - Alternatively, we may implement client-sorting and implement other complex logic to deal with this. This would take a lot of time and may introduce tons of bugs. - Batch edit is already on our roadmap and would be delayed by this. - We thought a lot about the current solution and are willing to improve it further at a later time after getting more feedback. You're the first user who reports this as an issue.

deekerman commented

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

Author

Owner

@inthreedee commented on GitHub (Feb 13, 2021):

Check the date field, it is updated.

Yes, it is. I'm very sorry if I wasn't being clear.

Batch edit is already on our roadmap and would be delayed by this.

Batch edit would certainly help, but only for groups that need the same metadata changes.

If I'm editing a group of photos and correcting the timestamps, for example, each one would have a different timestamp. And then I have this problem of having to refresh to see changes, losing my place, etc. This also happens while fixing primary photos for a group. I know these are changes that only ever have to be done once when making corrections to uploads, but I still find the process to be more tedious than other photo services I have used and am trying to switch away from (google photos, flickr)

If the issue I'm trying to describe is at all confusing, please let me know and I'll provide more detailed reproduction steps. The easiest way to see what I'm talking about is to just go into your stacks list and start changing the primary photos. You'll quickly get lost and forget which photo is next to be edited, meaning you have to refresh the page. Then, if you have a lot of stacks, you have to scroll back down to find your spot. There has to be a more efficient way to do this, no?

We push updates from the server to the client. Sorting requires a server request to be complete and consistent. Thus when multiple users edit photos, all views would continuously reload - maybe more than 1000 results each.

Ah, I can see how that might cause issues if the only way to do it is to refresh everything. What about in a single user environment? I'm having to manually refresh after each edit anyway.

btw, thank you very much for the responses here. And again, I apologize for anything I'm not being super clear on.

@inthreedee commented on GitHub (Feb 13, 2021): > Check the date field, it is updated. Yes, it is. I'm very sorry if I wasn't being clear. > Batch edit is already on our roadmap and would be delayed by this. Batch edit would certainly help, but only for groups that need the same metadata changes. If I'm editing a group of photos and correcting the timestamps, for example, each one would have a different timestamp. And then I have this problem of having to refresh to see changes, losing my place, etc. This also happens while fixing primary photos for a group. I know these are changes that only ever have to be done once when making corrections to uploads, but I still find the process to be more tedious than other photo services I have used and am trying to switch away from (google photos, flickr) If the issue I'm trying to describe is at all confusing, please let me know and I'll provide more detailed reproduction steps. The easiest way to see what I'm talking about is to just go into your stacks list and start changing the primary photos. You'll quickly get lost and forget which photo is next to be edited, meaning you have to refresh the page. Then, if you have a lot of stacks, you have to scroll back down to find your spot. There has to be a more efficient way to do this, no? > We push updates from the server to the client. Sorting requires a server request to be complete and consistent. Thus when multiple users edit photos, all views would continuously reload - maybe more than 1000 results each. Ah, I can see how that might cause issues if the only way to do it is to refresh everything. What about in a single user environment? I'm having to manually refresh after each edit anyway. btw, thank you very much for the responses here. And again, I apologize for anything I'm not being super clear on.

deekerman commented

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

Author

Owner

@inthreedee commented on GitHub (Feb 13, 2021):

Another scenario involves making edits to stacks:

When you unstack a photo and then return to your library, the unstacked photo does not appear. If you want to work on the unstacked photo, you first have to manually refresh the page. This causes you to lose your place in your library and you now have to scroll back down to find the unstacked photo before you can continue working.

@inthreedee commented on GitHub (Feb 13, 2021): Another scenario involves making edits to stacks: When you unstack a photo and then return to your library, the unstacked photo does not appear. If you want to work on the unstacked photo, you first have to manually refresh the page. This causes you to lose your place in your library and you now have to scroll back down to find the unstacked photo before you can continue working.

deekerman commented

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

Author

Owner

@inthreedee commented on GitHub (Feb 14, 2021):

I updated the original post to hopefully clarify the request and better explain why I think it would improve the user experience.

@inthreedee commented on GitHub (Feb 14, 2021): I updated the original post to hopefully clarify the request and better explain why I think it would improve the user experience.