RSS Part 21: RSS Guard in Production

I recently started using RSS Guard as my primary RSS reader. This blog entry is an update to my previous RSS Part 13: RSS Guard and RSS Part 20: RSS Guard Revisited blog entries.

Even though QuiteRSS is dead, the still-maintained AUR quiterss package allowed me to continue using it. Every update to ICU resulted in time-consuming rebuilds of Qt and Qt WebKit in order to rebuild QuitRSS, however. After an ICU update last month, QuiteRSS no longer builds on my primary system. It still builds on a different system, but I decided to go ahead and put down my shovel.

Of the RSS feed readers that I have considered, RSS Guard best matches my client requirements. A recent HN discussion about RSS illustrates how different people use RSS in different ways. Most of my reasons for using RSS is related to productivity.

• I can check for new content across a wide range of websites within a single application. I do not have to load many new tabs in my browser. I do not have to scroll through pages of full content.
• I can quickly look through hundreds of new entries per day and open the relative few that I want to investigate further.
• I can choose when to check for new content. I do not get notifications throughout the day, as those destroy productivity.
• I can reasonably expect to see all new articles on sites that I care about, relatively soon after they are published, without having to worry about missing things. The lack of a constant desire to check sites in fear of missing something helps productivity.

I have been using RSS Guard for about two weeks now, and I have been keeping notes for this blog entry.

Praise

There are a number of reasons why I plan to use RSS Guard over QuiteRSS, even disregarding the QuiteRSS build issues.

• RSS Guard is very well maintained.
• RSS Guard stability is great. It has not crashed on me yet.
  • One of my feeds frequently has entries that crashes QuiteRSS. I suspect that the crashes are caused by inappropriately huge banner images in the articles. RSS guard handles that feed without issue.
• RSS Guard performance is great.
  • RSS Guard now provides great speed, but it also has delay settings, so that you can throttle multiple requests to servers. For example, separate Reddit feeds all use the same server. Recently, it seems that Reddit implemented stricter throttling, and I often got errors when using QuiteRSS. With RSS Guard configured to delay requests to the same server, I no longer see Reddit feed errors.
• RSS Guard works with all of my feeds.
  • One of my feeds stopped working with QuiteRSS, but it works fine with RSS Guard.
• I really like that feed status information is easily viewable, in the browser pane when clicking on the feed.

UI/UX Notes

The previous RSS Guard blog entries have some UI/UX notes, but here are some new notes.

• I need to adjust table configuration every time I use the application. This is annoying, but I do not mind it too much. After starting the application and pressing the button to fetch all feeds, I perform the following steps while the feeds are being fetched.
  1. Resize the feed count column - By default, the width of the feed column is very narrow while the width of the feed count column is very wide. Resizing allows me to see the feed titles, and the feed count does not need much space.
  2. Disable the “Important” column - This column is useless with the way that I use RSS. I do not keep entries in the RSS reader.
  3. Enable the “Feed” column - My feeds are organized into groups so that I can process them quickly. I process feeds in some groups separately, by opening the group and selecting specific feeds. I process related sparse feeds in bulk, however, by selecting the group. In this case, I want to see which feed each entry is coming from.
  4. Resize the “Date” column - After adding the feed column, the date is given almost no space. I resize the column so that I can see the date again.
  5. Resize the “Author” column - This column is too narrow by default, so I give it some more space.
  6. Resize the “Title” column - This column is too narrow by default, so I give it a lot more space. Note that columns need to be resized from right to left.
  7. Change the “Date” sort order - Items are sorted by date/time with newer entries at top by default. This is my preferred sort order. I process entries from old to new, so I processed entries from bottom to top when using QuiteRSS. This does not work in RSS Guard, however, because the delete key only works from top to bottom. I therefore sort with older entries at top and process entries from top to bottom.
• Table configuration applies to all feeds; the application does not have separate configurations per feed. This is fortunate, because adjusting table configurations per feed would be too much. It also applies to the recycle bin, however, which is a bit unfortunate. I process feeds quickly, and I occasionally hit delete too quickly and need to find the deleted entry in the recycle bin to check something. In QuiteRSS, the recycle bin shows entries in order of insertion, so the entry that I just deleted is at the top. In RSS Guard, the recycle bin is ordered the same as the feeds (by date in my case), so I have to search for the entry that I just deleted. This is not a big issue, though I indeed process feeds more slowly because the cost of premature deletion is higher.
• I often need to copy the URL of a podcast audio file from the browser pane at the bottom. I later want to delete the article, which is still highlighted in the entry pane at the top, but pressing delete does not work since the bottom pane has focus. There is no visual indication of focus, so I have made this mistake many times. It is not a big issue, though; I just need to click on the item in the top pane and press delete.
• I like the delay option used to throttle connections to the same server. I configured it during initialization, but I am unable to find the option in the settings.
• Occasionally, a feed will be highlighted in blue, but I am not sure what that means. The status is “has new articles” but none are displayed, and the count for the feed is zero. Perhaps the lastBuildDate for the feed is newer than than that of the previous fetch but there are no new entries?
• I would appreciate even more information for feeds, such as the following.
  • Time of the latest entry as specified in the RSS feed
  • Time of the last fetch
  • Status for the last fetch: failure/success, number of new entries
  • If the last fetch failed, time of the last successful fetch
  • If no new entries, time of the last fetch with new entries

Storage Space

In the issues section of my last blog entry on RSS Guard, I talked about database size concerns. Thunderbird gets really slow as the size of the database increases, so you have to regularly “compact folders” to mitigate the issue. The RSS Guard database cleanup functionality resets all feeds, so my plan is to only do it if/when performance gets bad.

I have only been using RSS Guard for about two weeks, but I have some data points.

These values are measured using du -sh ~/.config/RSS\ Guard\ 4/ and du -sh ~/.cache/RSS\ Guard/. (I am sure that I have already expressed my dislike for spaces in filenames…) The database is in the XDG config directory, so that is the one that I am concerned with. I decided to keep an eye on the cache directory as well, though.

As of today, performance is (still) great!