Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

#1003 Liferea does not parse Google Alerts properly

v1.6
open
Lars Windolf
5
2012-07-31
2012-01-21
Patrick Dickey
No

I set up my Google Reader account in Liferea, which includes an alert for Taylor Swift news. However, when Liferea updates, it changes the source of the feed from this url http://www.google.com/reader/atom/user/12013941499883400425/state/com.google/alerts/2759633226522005899 (which I created using the other feed from my Google Reader) to simply /12013941499883400425/state/com.google/alerts/2759633226522005899 and changes the "source" from "URL" to "Local File". When I change it back, it updates fine--until I close Liferea. Upon reopening Liferea, the source is back to local file with the truncated url.

We should be able to change the source property and have it stick (regardless of whether it's a Google Reader account or a regular blog). Or, when it downloads the information from Google Reader, it shouldn't alter the url or location at all (regardless of whether it's a valid feed or not).

While the url that I use won't pass at feedvalidator, it does work in LIferea--as it's the format that Google Reader expects.

Discussion

  • Patrick Dickey
    Patrick Dickey
    2012-01-21

    One correction to my earlier (original) comment. As soon as I click Update or it auto-updates, the file is changed back to local file, and the portion of the source location leading up the the first number (the http://www.google.com/reader/atom/user/ portion) is removed. Lifrerea shouldn't be altering the source location or type without the user initiating it, or the feed changing it.

     
  • Patrick Dickey
    Patrick Dickey
    2012-01-21

    debug log of my updates along with the changes to google alert source.

     
    Attachments
  • Patrick Dickey
    Patrick Dickey
    2012-01-21

    I'm attaching a log file that I created by running liferea --debug-update in my command line. The easiest way to see what's happening is to search for Taylor or Swift (as that's the unique identifier for the problem). The first thing you'll notice is that it removes the old source, and adds a local file. Then you'll see that I changed it to the URL (which I forgot a /, so the url wouldn't update).

    Next, you'll see I fixed the URL and it updates correctly. After that, I run Update All, and it changes the URL back to a local file and mangles the location. Finally, I fix the URL and it updates correctly.

    Also it should be noted that my other feed loses the user ID tag, and becomes a -. So this feed isn't updating properly either.

     
  • Lars Windolf
    Lars Windolf
    2012-07-31

    Could you provide the feed URL for me to add it to my Google Reader test account? I think this is the only way to reproduce this effect.

     
  • Lars Windolf
    Lars Windolf
    2012-07-31

    • assigned_to: nobody --> llando
    • status: open --> pending
     
  • Patrick Dickey
    Patrick Dickey
    2012-07-31

    http://www.google.com/reader/view/user/12013941499883400425%2Fstate%2Fcom.google%2Falerts%2F2759633226522005899 is the feed url that I have when I sign into reader. The feed is titled "Google Alerts - Taylor Swift".

    The main problem that I have is that it drops the portion up to and including the /user/ from the feed URL. So, when Liferea goes to update, it's looking on my hard drive for a folder called 12013941499883400425/state/com.google/alerts/2759633226522005899 which doesn't exist. So it can't update the feed.

    Have a great day:)
    Patrick.

    P.S. To be honest, I haven't used LIferea since I ran into this issue. So it very well could be fixed in an updated version, but I don't know. If you want me to test it out, I can (when you think that a fix is ready).

     
  • Patrick Dickey
    Patrick Dickey
    2012-07-31

    • status: pending --> open
     
  • Lars Windolf
    Lars Windolf
    2012-07-31

    Thanks for the details! I think I know what is causing this.

    Don't worry about retesting.