mirror of
https://github.com/narrrl/proton-drive-linux.git
synced 2026-11-04 16:56:59 +01:00
fix(core,fuse,gui,cli): read only the photos a refresh has not read
A timeline refresh resolved every photo's node to learn its name, media type, favourite tag, content hash and photo relation — 63 round-trips for a 12,445-photo library, minutes of work, repeated every time the timeline went stale sixty seconds later. None of that metadata changes on its own, and when it does change the event feed names the node it changed. `photos.resolved_at` (schema v31) records that a photo's node was read. The refresh resolves the photos without that mark: the ones it has never read, and the ones a remote event marked stale. An existing timeline is backfilled as resolved, so upgrading does not re-read the library once. Remote changes now name what they changed instead of asking for everything. `classify_photo_events` turns a `NodeUpdated` into `photos_mark_unresolved(uid)`, so a favourite toggled on a phone costs one node read rather than the whole library; a local toggle is claimed as our own echo, because the feed replays it and a `NodeUpdated` carries nothing that says what changed. A continuity loss and `refresh photos --full` drop every mark, which is the way back to a whole-library read. Along the way: `photos_replace` never kept a photo's name, so a photo the SDK could not decrypt was renamed to nothing on every refresh — and the tab split and the RAW+JPEG grouping are both derived from the name. It is kept now, and a row that *was* resolved is authoritative instead, so a photo unlinked from its main elsewhere finally loses its `main_uid`. `TIMELINE_ENRICH_CHUNK` is 150, matching the SDK's own `MAX_BATCH_COUNT`: a chunk of 200 was split there into a full request and a 50-uid tail.
This commit is contained in:
1 parent
376f3edb28
commit
6cc8f72bab
12 files changed
+634
-69
No files matched your search
@@ -848,7 +848,7 @@ fn reload_current_page(ui: &Rc<Ui>) {
|
||||
}
|
||||
// One scope covers the whole photos view, so Refresh reloads whichever of
|
||||
// the two — album grid or timeline/album — is actually on screen.
|
||||
Some("gallery") => refresh_then(ui, RefreshScope::Photos, |ui| {
|
||||
Some("gallery") => refresh_then(ui, RefreshScope::Photos { full: false }, |ui| {
|
||||
if ui.gallery.content.visible_child_name().as_deref() == Some("albums") {
|
||||
load_albums(ui);
|
||||
} else {
|
||||
@@ -886,7 +886,7 @@ fn refresh_then(ui: &Rc<Ui>, scope: RefreshScope, load: fn(&Rc<Ui>)) {
|
||||
// A photos refresh answers as soon as it has started, because re-reading a
|
||||
// large library takes minutes. The page is therefore loaded twice: once from
|
||||
// what the daemon already holds, and again when the refresh has landed.
|
||||
let follow = scope == RefreshScope::Photos;
|
||||
let follow = matches!(scope, RefreshScope::Photos { .. });
|
||||
let rx = spawn_request(ui.dirs.control_socket(), Request::Refresh { scope });
|
||||
let ui = ui.clone();
|
||||
glib::spawn_future_local(async move {
|
||||
|
||||
Reference in new issue
Block a user