[gnome-photos/wip/rishi/collection: 1/44] item-manager: Log the URIs that are being watched for updates

[Debarshi Ray <debarshir src gnome org>]

commit 5c27bbca20ced12504aca146bdea2327d616db93
Author: Debarshi Ray <debarshir gnome org>
Date:   Sat Feb 10 00:28:55 2018 +0100

    item-manager: Log the URIs that are being watched for updates
    
    Trying to detect when the metadata for a URI has been inserted or
    updated in Tracker's database by looking for relevant GraphUpdated
    emissions seems fragile. When files are copied in bulk, sometimes, a
    GraphUpdated goes missing, or is apparently emitted so early that the
    entry in the database doesn't yet have a URI, which means that the URN
    can't be matched to its URI.
    
    The reasons are not known, but one can imagine that variations in
    timing and possible software bugs across the multiple layers involved
    in this mechanism contribute to this problem. Having some logging makes
    it easier to debug when this happens.
    
    https://gitlab.gnome.org/GNOME/gnome-photos/issues/29

 src/photos-item-manager.c | 4 ++++
 1 file changed, 4 insertions(+)
---
diff --git a/src/photos-item-manager.c b/src/photos-item-manager.c
index 1fab4770..67602505 100644
--- a/src/photos-item-manager.c
+++ b/src/photos-item-manager.c
@@ -344,6 +344,8 @@ photos_item_manager_check_wait_for_changes (PhotosItemManager *self, const gchar
   g_return_if_fail (id != NULL && id[0] != '\0');
   g_return_if_fail (uri != NULL && uri[0] != '\0');
 
+  photos_debug (PHOTOS_DEBUG_TRACKER, "Detected changes to %s", uri);
+
   tasks = (GList *) g_hash_table_lookup (self->wait_for_changes_table, uri);
   for (l = tasks; l != NULL; l = l->next)
     {
@@ -1259,6 +1261,8 @@ photos_item_manager_wait_for_changes_async (PhotosItemManager *self,
   tasks = g_list_prepend (tasks, g_object_ref (task));
   g_hash_table_insert (self->wait_for_changes_table, g_strdup (uri), tasks);
 
+  photos_debug (PHOTOS_DEBUG_TRACKER, "Waiting for %s", uri);
+
  out:
   return;
 }