• Content count

  • Joined

  • Last visited


About Jacket

  • Rank
    Founder & Development
  • Birthday 03/31/1984

Profile Information

  • Gender
    Not Telling

Contact Methods

  • Skype

Recent Profile Visitors

2,827 profile views
  1. We are investigating the issue. You can check https://status.inoreader.com/ for details.
  2. It was a global issue. It was an edge case though. First of all this particular counter is off by default, which automatically excludes more than 95% of the users. The actual count was coming from articles saved via IFTTT. At first they were shown as saved web pages (because that's what they are for our backend), but later we excluded them to de-clutter the section - people weren't expecting those articles to be there, but only in their respective tags. However the counter is coming from our bootstrap API method and we forgot to add the same exception there. No one noticed since it's off by default and even when we tested this counter it was actually expected to see numbers on our devices (because we actually have saved web pages), they were just not very accurate
  3. And I really appreciate your detailed feedback! The issue with the unread count should be fixed now.
  4. We will consider your request. Seriously though. Those are a lot of suggestions. Please don't expect that we'll jump straight into implementation, especially since you also added usability into the mix. For each of your bullets we could start an endless discussion about why it's currently implemented like this and why we can't simple change it on a single request. I fully agree that we need to work more on UX and this applies to all our apps, not only the mobile ones. The iOS app needs a complete overhaul to be honest, but we currently lack the resources to start it. When we start, all of those "we'll consider your request" topics will be merged in our tracking and hopefully we'll be able to implement the best of them with a much better UX. The current layout and navigation is so restricting that we can't implement many of the features we like without completely tearing the UX. I hope you understand. About the issue with saved pages, we are checking it and we'll get back to you.
  5. You have a PM.
  6. OK, apologies for the mess. How's that language setting doing?
  7. I understand the issue. We will see what can be done, but no promises at this point... It's not an easy decision to change defaults that all users are used to.
  8. The ticketing system that we launched a month ago was never meant to be accessed by users via the web interface. We needed it to have better internal tracking of feedback, since we were using only emails up until then. The web UI of this software is really outdated and probably has security holes too. Since it should contain sensitive user data to operate, we prefer to keep the web UI secured and inaccessible from outside of our network. You can open tickets from the "Request support" form and we will follow up via email like always, then you can collaborate on the email. I know the default email templates does link to the web UI, but they were changed too recently. If you want to reply to an old ticket, just reply to the email thread.
  9. This feed is returning "Forbidden" to our crawler. I can't even open it in my browser, so it's probably a geo block. If you have contacts of the owners, you can tell them about that. I think you know in which country our servers are. [root@poller1 ~]# curl 'http://www.menofstyle.gr/feed/' --verbose * Hostname was NOT found in DNS cache * Trying * Connected to www.menofstyle.gr ( port 80 (#0) > GET /feed/ HTTP/1.1 > User-Agent: curl/7.38.0 > Host: www.menofstyle.gr > Accept: */* > < HTTP/1.1 403 Forbidden * Server nginx is not blacklisted < Server: nginx < Date: Fri, 17 Mar 2017 18:27:43 GMT < Content-Type: text/html; charset=iso-8859-1 < Content-Length: 274 < Connection: keep-alive < Vary: Accept-Encoding < Vary: Accept-Encoding < <!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN"> <html><head> <title>403 Forbidden</title> </head><body> <h1>Forbidden</h1> <p>You don't have permission to access /feed/ on this server.</p> <hr> <address>Apache Server at www.menofstyle.gr Port 80</address> </body></html> * Connection #0 to host www.menofstyle.gr left intact
  10. The problem was on big screens with resolution larger than Full HD (although on Full HD it was a bit too much too). The embeds were getting so tall, that the content of the article was pushed below the fold. This is bad. However if you use card view or magazine view and press enter twice, the embed will also stretch. We are planning to add option for full width embeds too.
  11. Pinned. Thank you @Firestone. I couldn't have said it better.
  12. I'm not sure that I fully understand the issue, but from your photo I can see that you are not using the "All articles" section. I can't see your browser URL, but I think you are just sitting in a section without unread articles. Is this happening when you are scrolling through "All articles" (Alle Artikel)?
  13. We'll need some time to debug this properly, but if an article is in Inoreader, then it was for sure in the RSS feed. There are no suck "leaks" from side feeds in the system or we should have noticed it a long time ago. Sometimes feeds doesn't look the same to our backend as in your browser because of different user agents, geo location, lack of cookies, etc. Some bigger websites have servers located in different countries and they are not always in sync. We'll dig deeper into this particular case soon, but I'm almost certain that it's something like this.
  14. Unfortunately we are still struggling to find the right solution for this. Many Google blogs are changing links, guis and dates frequently now and this is the cause for duplication. We'll let you know when we have a permanent solution.
  15. Thank you for your suggestions. We will put them into our list for consideration.