GNOME Bugzilla – Bug 628867
Tracker keeps searching for RSS feeds and Flickr on and on without success
Last modified: 2016-05-14 00:05:48 UTC
Forwarding https://bugzilla.novell.com/show_bug.cgi?id=637227 ===== Tracker keeps searching for RSS feeds and Flickr to index the feeds and images I guess, but is unable to ever find them. As a result the tracker icon in the notification area keeps showing and it keeps using CPU resources. I could not find any way to disable this apart from disabling "Tracker Miner for FLickr" and "Tracker RSS/Atom feeds miner" from start-up applications. ===== For the RSS miner, that's most probably because g_object_set (miner, "progress", 1.0, "status", "Idle", NULL) is called in feed_fetched() only. However, if there's no feed found in feeds_retrieve_cb(), it should be called there too. For Flickr, that's just because the user is not authenticated, so I don't think there's a real bug there.
For the Flickr miner, the bug is actually a feature, progress is set to "undefined" at startup, and it's a design decision. It can be discussed though. The Flickr miner itself won't use any CPU cycle if it's not authenticated (no polling will be done), but the applet will pulse as you say. I could either set the miner to report a progress of 100% at startup (not sure it's very logical), or we could adapt the applet.
(In reply to comment #1) > For the Flickr miner, the bug is actually a feature, progress is set to > "undefined" at startup, and it's a design decision. It can be discussed though. Yep, that's what I thought. > The Flickr miner itself won't use any CPU cycle if it's not authenticated (no > polling will be done), but the applet will pulse as you say. > I could either set the miner to report a progress of 100% at startup (not sure > it's very logical), or we could adapt the applet. Thinking about it, what would probably be best is that the applet reports it's not authenticated and clicking on it would do the right thing (open the url in the web browser). (but that doesn't solve the case where people don't have a flickr account and so will have the pulsing icon forever... hrm)
The applet should report that the miner is not authenticated, I think it did in the status tooltip... If not then it's a bug. Click to authenticate is more complicated, as it requires: 1. A mechanism to add custom actions (other than pause/resume) 2. A gtk frontend for miner management (to associate them), that I didn't write so far (I only have one for meego). People who don't have a Flickr account should disable the Flickr miner in the sessions pref dialog, but that's far from obvious to guess.
(In reply to comment #3) > The applet should report that the miner is not authenticated, I think it did in > the status tooltip... If not then it's a bug. I don't see any tooltip here, so... bug? :-) > Click to authenticate is more complicated, as it requires: > 1. A mechanism to add custom actions (other than pause/resume) > 2. A gtk frontend for miner management (to associate them), that I didn't write > so far (I only have one for meego). Isn't it just a matter of adding a dialog with a "Associate" button that would be opened at the same time as the url in the browser? I have only read http://live.gnome.org/Tracker/Documentation/WebMiners/Association, so I'm just guessing :-) > People who don't have a Flickr account should disable the Flickr miner in the > sessions pref dialog, but that's far from obvious to guess. Yeah, not obvious, unfortunately. An alternative would be to have a Flickr tab in the pref dialog, where all the authentication stuff would happen, and that would also make it easy to disable the miner. And if the miner is changed to report 100% when not authenticated (or on startup, like you suggested earlier), everything would just work.
Detecting web miners from normal miners in the status applet is quite easy, so we could have a special behaviour for them. The association for miners is not always done through a browser, sometimes it's browser based and sometimes you just need to give username/password (eg. GData). There have been talks considering weither such a UI belongs in tracker-preferences, or in a separate tool. Given that we can't share the credentials accross apps since applications need a unique key, I guess we could integrate that panel into tracker-prefs (Martyn, any feedback on that ?).
This no longer applies.