Bug 2079344
| Summary: | A new album looks empty until app restart | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Kamil Páral <kparal> | ||||
| Component: | gnome-photos | Assignee: | GNOME SIG Unassigned <gnome-sig> | ||||
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | unspecified | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 36 | CC: | awilliam, debarshir, geraldo.simiao.kutz, gnome-sig, lruzicka, robatino, rstrode | ||||
| Target Milestone: | --- | ||||||
| Target Release: | --- | ||||||
| Hardware: | Unspecified | ||||||
| OS: | Unspecified | ||||||
| Whiteboard: | AcceptedBlocker | ||||||
| Fixed In Version: | gnome-photos-42.0-2.fc36 | Doc Type: | If docs needed, set a value | ||||
| Doc Text: | Story Points: | --- | |||||
| Clone Of: | Environment: | ||||||
| Last Closed: | 2022-05-05 18:37:27 UTC | Type: | Bug | ||||
| Regression: | --- | Mount Type: | --- | ||||
| Documentation: | --- | CRM: | |||||
| Verified Versions: | Category: | --- | |||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||
| Embargoed: | |||||||
| Bug Depends On: | |||||||
| Bug Blocks: | 1953785 | ||||||
| Attachments: |
|
||||||
Proposing as a Final blocker: https://fedoraproject.org/wiki/Fedora_36_Final_Release_Criteria#Default_application_functionality Probably the same root cause - when you *remove* a picture from an album (you can do it using the "Add to Album" button, logically), the whole album gets inaccessible (again displaying with three dots) until you restart the app. +5 in https://pagure.io/fedora-qa/blocker-review/issue/787 , marking accepted. Confirmed here, reported upstream. I retested this with the build from bug 2079308 comment 13, but it has no effect on this bug, still broken. Well, for me, the "three dots" problem was still there, but the album did show the photos when I opened it (with the new scratch build). For me, it was still empty, until app restart. Tested twice. *** Bug 2081322 has been marked as a duplicate of this bug. *** so i have a scratch build here going that I think should make the problem go away: https://koji.fedoraproject.org/koji/taskinfo?taskID=86593508 I don't think it's the right fix...more of a workaround. But maybe good enough for now, until the right fix can get worked out upstream. (In reply to Ray Strode [halfline] from comment #9) > https://koji.fedoraproject.org/koji/taskinfo?taskID=86593508 Unfortunately I don't see a difference. Still the same behavior. When creating new albums or adding photos to existing ones, I see these messages in the journal: May 03 23:59:11 fedora gnome-photos[2127]: photos_tracker_collection_view_controller_active_collection_changed: assertion '(PHOTOS_BASE_ITEM (active_collection) && n_items == 0) || (active_collection == NULL && n_items > 0)' failed May 03 23:59:14 fedora gnome-photos[2127]: Unable to create collection icon: Unable to create collection icon May 04 00:00:14 fedora gnome-photos[2638]: photos_item_manager_info_updated: assertion 'updated_item == item' failed May 04 00:00:20 fedora gnome-photos[2638]: photos_view_container_item_activated: assertion '(gpointer) box_item == (gpointer) item' failed weird.do you also see double items too when creating new albums? ahhh I see, the %prep section doesn't do %autosetup so the patch isn't getting applied. new scratch build: https://koji.fedoraproject.org/koji/taskinfo?taskID=86639845 (In reply to Ray Strode [halfline] from comment #13) > new scratch build: > https://koji.fedoraproject.org/koji/taskinfo?taskID=86639845 Ooh, shiny! This fixes this bug and bug 2081291 as well! If I create a new album, it is immediately accessible with the right photos. If I remove a photo from an album it stays accessible [1]. I can organize pictures between albums and the checkboxes work as expected. Great job! Can you please submit an update? [1] There is a minor bug still remaining. If I remove a picture from an already open album, the picture still appears to be present. I have to close the album and open it again, and the picture is finally not there. FEDORA-2022-93063b598b has been submitted as an update to Fedora 36. https://bodhi.fedoraproject.org/updates/FEDORA-2022-93063b598b I do have a fix for the minor bug, but I don't think it's a regression or blocker worthy so not sure if we should sneak it in or not. I already did the build and the RC is running, so I guess we can fix that one with an update :D I confirmed the update fixes both this bug and the other one for me. Thanks a lot for the workaround, Ray. Great, confirmed too that this update https://bodhi.fedoraproject.org/updates/FEDORA-2022-93063b598b fixes this bug here and BZ#2081291 Tested it on Fedora-Workstation-Live-x86_64-36-1.4.iso Just tested Fedora-Workstation-Live-x86_64-36-1.5.iso and Fedora-KDE-Live-x86_64-36-1.5.iso, live-sessions and installed at VMs. And in all cases this bug was FIXED. FEDORA-2022-93063b598b has been pushed to the Fedora 36 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-93063b598b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-93063b598b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. (In reply to Fedora Update System from comment #15) > FEDORA-2022-93063b598b has been submitted as an update to Fedora 36. > https://bodhi.fedoraproject.org/updates/FEDORA-2022-93063b598b Works fine. FEDORA-2022-93063b598b has been pushed to the Fedora 36 stable repository. If problem still persists, please make note of it in this bug report. (In reply to Ray Strode [halfline] from comment #9) > I don't think it's the right fix...more of a workaround. But maybe good > enough for now, until the right fix can get worked out upstream. Just to follow up here for those following along... The "right fix" (versus the "right now fix" we did a couple of days ago) has landed upstream now: https://gitlab.gnome.org/GNOME/tracker/-/merge_requests/511 |
Created attachment 1875353 [details] bug demonstration video Description of problem: If I select some pictures and add them to a new album, the album only shows three dots as its picture, and is empty when opened ("No photos found"). When I restart gnome-photos, suddenly the album is correctly populated. Version-Release number of selected component (if applicable): gnome-photos-42.0-1.fc36.x86_64 How reproducible: always Steps to Reproduce: 1. select some photos, add them to a new album 2. go to Albums, see the new album with three dots instead of thumbnails 3. open the new album, see that it's empty 4. restart gnome-photos 5. open the new album, see that it shows the right images this time Additional info: In the video you can also see a small glitch - when adding a new album name and confirming with Enter, the album name shows twice in the list.