per-feed expire time

[ildar]

I have almost 10000 items. That's slow 😠
Looking at my feeds I see that along with usual news feeds injecting lots of items I also have some oldish small feeds to read later.
So for me there's no good choice for "Time interval to keep entries".
To fix this there may be a per-feed setting or
another way to limit entries pollution: by number of entries
What do you think?

[deoren]

+1

[ildar]

​Also, I started to dig the FeedEx.db and found that date (and prbably
fetch_date) are non-standard format in terms of SQLite:
sqlite> select date from entries where feedid=7;
1369383485000
1369894874000
sqlite> select date(date) from entries where feedid=7;
1698789-19650109-20
1698789-19650109-20
sqlite> select date('now') from entries where feedid=7;
2014-06-03
2014-06-03

I wanted to clean my DB manually but seem to stuck. :(

[Urban82]

Hi, the value in the DB is just a unix timestamp with milliseconds (a standard date/time format in many languages, including java!)

in a unix/linux box you can convert it removing the trailing 000 and using the date command as this:
$ date -d '@1369383485'
ven 24 mag 2013, 10.18.05, CEST

[ildar]

@Urban82, thanks and you are right.

So the workaround for this issue:
0. Get into the DB:
sqlite3 /data/data/net.fred.feedex/databases/FeedEx.db

1. Get entries number per feed:
   select feedid,count (*) from entries group by feedid order by count (*);
2. Delete entries older then 2 month that aren't in favorites for
   feedid=FEEDID(substitute):
   delete from entries where favorite is null and datetime(date/1000,'unixepoch') < datetime('now','-2 month') and feedid=FEEDID;

[myrdd]

+1

[ildar]

Need it back in v2

[ildar]

please reopen

[ildar]

Re

[myrdd]

@FredJul any comment on why you closed this issue?
@ildar what about working on a PR on your own?

[ildar]

It was opened and closed for v1. I asked to reopen for v2

[FredJul]

I actually closed all previous issues, the was a lot of fake issues for some pills advertising at that time and since the v2 codebase is totally new some of the previous tickets were obsoletes. So I prefered to start again from a fresh start.

And concerning this issue in particular, I actually wonder if the problem still exists in v2, I believe I have fixed one problem which could help that.

[ildar]

I looked through the latest commits and couldn't find anything related. I suggest the problem still persists and any particular feed doesn't have expiration settings. If you reopen the issue it'll help to avoid forgetting about it as well as issue duplicates. P.S. the about page doesn't show the version

[FredJul]

It was not a recent fix, I did it during the v2 rework.

Today I don't really want to add a time limit per feed. I prefer to keep Flym simple, I have more important feature to do before, and if you want to keep one particular entry, you can still star it. But I believe there was a problem leading to some never-deleted entries in the v1 codebase.

Before reopening this issue I would like to know if people actually still encounter a performance degradation over time. Of course if they decided to select "always" in the time conservation setting then I expect it to be slower and slower. I actually should maybe delete that "always" possibility.

[ildar]

Frédéric, thanks for sharing. 1. On keeping Flym simple: this option doesn't (in v1) add anything to the main setting Settings so it doesn't count :))) 2. Adding items to Fav to keep it alive destroys Fav function 3. On performance: I recently got a new phone with 8-core cpu and 2M of RAM. And I restored my spaRSS 80M database. Performance isn't good. I'd say it's not crucially better then on my previous Grand2 phone. In fact I'm WIP in writing a converter. And soon I'll check if Flym v2 (hopefully) show better UX. 4. Please keep Always option. Let my cite myself as OP:

…

Looking at my feeds I see that along with usual news feeds injecting lots of items I also have some oldish small feeds to read later.

[ildar]

I migrated my 81M database with #378 . I must admin, I LOVE Flym v2! It is MUCH smoother then previous and doesn't crash because of races. It is fast though not instant. I guess some cleanup should be there. Using 8C & 2M RAM device just for the record

[FredJul]

Glad to see you like it!

I understand your previous critics on the UX, even if I disagree for some. But please note that I plan to add back some previous features little by little (light theme, compact view for the lists, sort order setting...). It's just that it's hard to find the time for that.

[ildar]

I agree. Care to reopen? ;) but I don't remember to criticize the UI or UX. hm..

[FredJul]

Reopen this particular issue about per-feed expire time? I'm still not convince on that one, I still believe it will make the UI and the code more complex for a not-so-common use case. One thing is sure: it is not my priority, but if other people manifests their interest or if someone want to code it, then I guess I'm not against it.

And about the UX, sorry I actually misunderstood your previous sentence: "And soon I'll check if Flym v2 (hopefully) show better UX."

[ildar]

allright then! 😉👍 We'll wait for other people's reaction.

[Lachmoewe]

My usecase is also that I have a few news sites punching out news by the minute, and then something like rubikon with only a few articles per month. In order to save space on my phone I had to set the delete time to four days, rendering it impossible to read the slower news sites. Having a per feed or even per folder delete time would help me a lot with this. I guess it wouldnt really complicate the UI if you put a tick box in the feed settings menu with something like "custom delete time", with greyed out time setting if not ticked.