sort playlists from newest to oldest

[KraXen72]

Checklist

• I made sure that there are no feature requests - open or closed - that already cover my request.
• My feature request has a well-defined scope and is described in sufficient detail.
• I understand and accept that my feature request may not be considered unless it can attract significant community support.
• I have read and understood the contribution guidelines.
• I am positive that my feature request meets one of the following criteria, and I have checked the one box that applies to my feature request below:
• My feature request relates to fork-specific functionality that does not exist upstream (e.g., SponsorBlock, Return YouTube Dislike).
• My feature request has already been opened upstream, and it has been declined.

Feature description

please add an option for playlists to be sorted new to old when they're opened.

Why do you want this feature?

right now i have to always scroll to the bottom of my watch later playlist to find recent videos

Why is this feature relevant to this fork?

upstream has frozen feature requests until the rewrite, so we wouldn't see this for a while (several years possibly)

Additional information

No response

[javulticat]

TL;DR

Right now, I'm currently working on making this project available via F-Droid, which I want to complete before starting anything else. Part of that effort includes rebranding the project. As I update the project name/logo in documentation/templates/policies/etc., for the rebrand, I will also update and clarify the mission/policies for the project as I outline below. (Essentially, instead of continuing the policy of relying almost exclusively on improvements made upstream, the project will be much more open to making its own improvements. This will allow the project to continue to progress even while, as you point out, the progress upstream may remain frozen for a long time while they prioritize a major rewrite.)

So, once the F-Droid/rebranding project is completed, I will include this feature request when prioritizing the next batch of things to work on. 👍

---

Hi @KraXen72, thanks for the feature request! This simple request actually gave me a lot to think about 🙃

upstream has frozen feature requests until the rewrite, so we wouldn't see this for a while (several years possibly)

I think you raise a fantastic point here! Our current "feature request policy" (as seen in the form you filled out) was based on the policy used by the previous fork. According to that policy, this feature request should be rejected here and you should be told to make it upstream instead. But that does not really seem like an appropriate response to give when, as you point out, upstream is no longer considering feature requests for the foreseeable future.

In the wake of the previous fork being archived, this project's initial mission was to provide a NewPipe SponsorBlock app that would be actively maintained and kept up-to-date with upstream. I believed that maintaining an up-to-date version of NewPipe SponsorBlock could benefit its community, which, after the previous fork was archived, seemed to be left to choose between a few non-ideal choices - namely either:

• Keep using an archived/unmaintained version of NewPipe SponsorBlock, which was left in a state that contained several upstream bugs and would very likely accumulate more problems as the platforms it interfaced with continued evolving
• Revert to using a more recent version of vanilla NewPipe from upstream, which improved the user experience in various ways via fixed bugs and new features, but also removed the key feature (SponsorBlock) that had led those users to using the NewPipe SponsorBlock fork in the first place

So, the intent was for this project to benefit the NewPipe SponsorBlock community by providing them with another choice that aimed to better serve the community: a version of NewPipe SponsorBlock that also was kept up-to-date with the latest upstream improvements, which was quickly accomplished. But, now that improvements (especially in regards to feature requests) coming from upstream are likely to be very limited for the foreseeable future, continuing on this path is unlikely to add further value to the community. In fact, most of the overall NewPipe ecosystem in general (both upstream and the various forks that rely on upstream to maintain the bulk of their codebase) is likely going to become stuck in a kind of stasis for the duration of upstream's rewrite effort.

So, perhaps the most beneficial way this project can serve the community is to refocus our mission and policies to avoid ending up in this "stasis". That way, we can add features (like this one! 🙃), fix bugs, and otherwise continue development on the current codebase, allowing progress to occur without needing to wait for upstream to complete their rewrite effort. This could not only help to differentiate this project from the previous fork, but it would also allow the project to provide another option for users, like yourself, who may be interested in a variant of NewPipe that continues to add features and improve their user experience, especially as an alternative while upstream's development is frozen to focus on a major rewrite - which, like you said, could last for quite a long time.

[KraXen72]

what a wonderful response! thanks! i hope only the best for this project!

[yoshimo]

The important part would be stating the differences to other forks of NewPipe, like Newpipe x Sponsorblock, PipePipe, BraveNewPipe or Tubular. It became a bit confusing lately.

[DI555]

@javulticat , surely, this FR "sort from newest to oldest" should be optional with others like "sort from oldest to newest", "unsorted"("custom") and "sort alphabetically" with "sort alphabetically revers"!!!
Please, take care of this!
Many thanks in advance!