Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[FR]: Problem with synchronizing unread mesages on Reedah #382

Closed
cocowash opened this issue Mar 19, 2021 · 7 comments
Closed

[FR]: Problem with synchronizing unread mesages on Reedah #382

cocowash opened this issue Mar 19, 2021 · 7 comments
Assignees
Labels
Status-Fixed Ticket is resolved. Type-Defect This is BUG!!!
Milestone

Comments

@cocowash
Copy link

cocowash commented Mar 19, 2021

#### Brief description of the issue.
Rss Guard syncs already read messages but can't reach to unread messages.

#### How to reproduce the bug?

  1. add a Google Reader API account (Reedah) and select download all messages. Have 400 or more feeds on the account. Set only download newest X messages per feed on 50.

#### What was the expected result?
The Program syncs fully with Reedah in seconds.

#### What actually happened?
It took me 2 days to have an unread message

#### Other information

  • OS: win 10
  • RSS Guard version: 3.9.0

I contacted Reedah support and they kindly wrote me back:

I took a quick look at what RSS Guard is doing and made these observations.

  1. Fetching data is a bit slow compared to our web interface. We can
    probably improve this some on our end.

  2. RSS Guard is logging in and getting a security "token" for every feed
    it checks. With Reedah this is unnecessary and may add around 4 seconds
    per feed. It is valid and will work, just slower.

Our servers are running below capacity at the moment (like 10% utilized)
so there is not an issue with things being overloaded.

Obviously the first time RSS Guard (or any other software) syncs will be
the slowest because it is loading X days worth of articles.

We are happy to work on making things faster for RSS Guard users in the
future. But for immediate actions, most things are outside your
control. The best advice I can give you right now is (a) confirm whether
sync works for you at all or is it just slow - you are welcome to create
a temporary account in Reedah with fewer feeds to test it; (b) try to
mark all articles as read in the web browser before sync; (c) limit RSS
Guard to the most recent X articles for the first sync, e.g. X=25; and
(d) be patient - simply the token requesting for 400 feeds could take
400x4 = 1600 seconds so I would not be surprised if a complete sync is 1
hr+ at the moment.

According to the Google Reader API (which Reedah copies), the
ClientLogin token expires after two weeks. What RSS Guard should be
doing is logging in when the app starts and getting the token, then
storing it and re-using the same token for each request until it expires
(or at least for a few hours).

Instead it appears to login and get a token before every request (e.g.
sync of each individual feed). This creates a new "session" for the
user in Reedah. So instead of having a few (1-2) sessions per user, we
quickly end up with 1,000 per user.

It is not a particularly big problem for us, but the unnecessary steps
do slow things down for the user.

@cocowash cocowash added the Type-Defect This is BUG!!! label Mar 19, 2021
@cocowash cocowash changed the title [BUG]: Problem with synchronizing unread mesages on Reedah [FR]: Problem with synchronizing unread mesages on Reedah Mar 20, 2021
@martinrotter
Copy link
Owner

Wow, this seems like some major clusterfuck from my side. Will investigate.

@martinrotter
Copy link
Owner

5a7c06b

OK, I fixed a couple of Reedah-related bugs. Will continue fixing the rest of it tomorrow.

@martinrotter martinrotter modified the milestones: 4.0.0, 3.9.1 Mar 21, 2021
@martinrotter
Copy link
Owner

@cocowash OK, I fixed the part with repeated unnecessary obtaining of token which is now obtained correctly only once.

Updates should be now much much much faster, please check with latest development build, please.

https://github.com/martinrotter/rssguard/releases/tag/devbuild

@martinrotter
Copy link
Owner

martinrotter commented Mar 21, 2021

I tested with devbuild, added 100 feeds and initial sync of messages took 25 seconds with 70 messages per feed and 1 minute with all messages per feed.

@martinrotter martinrotter modified the milestones: 3.9.1, 4.0.0 Mar 21, 2021
@martinrotter martinrotter added the Status-Fixed Ticket is resolved. label Mar 21, 2021
@cocowash
Copy link
Author

cocowash commented Mar 21, 2021

With the newest Development build all syncs a lot faster. Nonetheless, for me now its evident that none of the YouTube feeds are working. (no read or unread messages) [As an example this is the regular structure I use for YouTube feeds on Reedah https://www.youtube.com/feeds/videos.xml?channel_id=UCJHA_jMfCvEnv-3kRjTCQXw] any of the YouTube feed is visible in Reedah but empty on RSS Guard. Could you make a test with a YouTube feed in your account pls?

Edit: Also I found certain feeds that remain empty (no read or unread messages) during these tests on RSS Guard. All have in common that download a xml file if they are pasted on a browser. These are some examples of this issue:
http://redderol.blogspot.com/feeds/posts/default?alt=rss
https://rssbox.herokuapp.com/mixcloud/podcastpueblafm/Puebla%20FM%20%7C%20105.9
https://easygerman.squarespace.com/podcast/episodes?format=rss
https://www.thinklikeagamedesigner.com/podcast?format=rss
http://jugandoconlosabuelos.blogspot.com/feeds/posts/default?alt=rss
http://vetustosdelrol.blogspot.com/feeds/posts/default?alt=rss

@martinrotter
Copy link
Owner

Thank you, I will test them. :)

martinrotter pushed a commit that referenced this issue Mar 22, 2021
@martinrotter
Copy link
Owner

Fixed with fd7e43a.

The error was that "id" of the feed was not properly encoded in request URL so the query failed for all feed "id"s which contained "?". Should now work.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Status-Fixed Ticket is resolved. Type-Defect This is BUG!!!
Projects
None yet
Development

No branches or pull requests

2 participants