Feature request: "no_reorder" option

[alfonder]

I suggest adding "no_reorder" option to the feed parameters.
This could be helpful when a feed is composed from several sources with different update cycles. Then newly found items would be placed on top of the feed disregarding their timestamp (even if they are older).
Currently new items with older timestamps drown in the existing feed. Therefore an app (like Podcast Republic) ignores them, since it analyses only items newer than the previous head.

[umputun]

Did you mean this part?

In yt feed, new items with the older timestamp do some kind of "reordering" but this is done precisely for what you described above - populate items in the time sequence. Keeping original timestamps have the opposite effect

[alfonder]

I'm not sure. Maybe that code executes only for YT feeds. Or I describe unclear.
What I'm observing now.
Let's assume FM produces rss feed X which is composed from rss feed A and rss feed B.
On update 1 we have.

A         B
--        --
9:20 A3
9:10 A2
9:00 A1   9:05 B1

X
--
A3
A2
B1
A1

On update 2 we have

A         B
--        --
9:40 A5
9:30 A4
9:20 A3
9:10 A2   9:15 B2
9:00 A1   9:05 B1

X
--
A5
A4
A3
B2
A2
B1
A1

Podcast Republic will add A4 and A5 episodes. So B2 episode will be lost.

I would suggest make possible the resulting feed's order:

X
--
A5
A4
B2
A3
A2
B1
A1

[umputun]

I understand your proposal; however, it is not about disabling reordering but rather enforcing a different sorting order.

The system concurrently processes multiple feeds and stores all the information in Boltdb, a key-value store indexed by timestamp, which represents pubDate from the original RSS feed. The only sorting applied here is by the pubDate, which is shown in the "On update 2 we have" diagram.

The mode that you referred to as "no_reorder" is actually a different ordering based on local time, that is, the time the new item is detected. I believe the sorting key we need to use is the feed's DT field. However, because it is not a real database but rather a key-value store, changing the index keys that are persistent is not a simple task. It may require breaking back compatibility, adding migration, and other complicated procedures.

Alternatively, changing the order of items on the fly as part of Server.getFeedCtrl is a much simpler approach. Although it may not be a perfect solution since the store limits are based on pubDate ordering, it may be sufficient.

I hope my explanation makes sense. If you want to submit a PR for this change, it should be relatively easy to implement.