TeamNewPipe
Refactor internal Progress/busy Reporting
Checklist
- [x] I made sure that there are no existing issues - open or closed - which I could contribute my information to.
- [x] I have read the FAQ and my problem isn't listed.
- [x] I'm aware that this is a request for NewPipe itself and that requests for adding a new service need to be made at NewPipeExtractor.
- [x] I have taken the time to fill in all the required details. I understand that the feature request will be dismissed otherwise.
- [x] This issue contains only one feature request.
- [x] I have read and understood the contribution guidelines.
Feature description
current behavior
- one global feed State
-
- only shown on Feed Tabs (and the Device notifications) tho
- very similar Events
- Event states
-
- IDLE
-
- Progress
-
- Success
-
- Error
- The concept only applies to Feed update
- The concept only knows the one (Main)Feed, no regard for groupId
- Every Feed shows the progress of the one current update progress, despite being initiated from a diffrent Feed
desired behavior
- still global e.g The Main Page should be able to recognize that some work is being done
-
- should not be tied to a certain type of tab e.g. blank tab could know of updates being processed
- Add Cancel state/event so future features would be able to cancel a job and report that to the GUI
- Other work should be able to be plugged into the Reporting system in the future(maybe kiosk data, downloads, etc.) -> maybe enum of types of progress
- append an identifier as a sub category -> for FeedUpdating that would be the groupId, allowing for a certain group feed to only react to progress intended for it.
Why do you want this feature?
Required for future-proof GUI / Process change
- I have multiple feedGroups to update.
- I have >100 subscriptions to update at a time
- There's plans or is even potentially required to update subscriptions more asynchronously in the future as to not be blocked by the services
- I want my UX eventually to be less blocked by updating jobs
- I ideally want to see a global indicator of work being done in the background
- I only want to see feed progress on the specific feed it applies to
- I intend on future ability to cancel a certain job by either User request or by process logic
Additional information
I was & am tinkering with it from my interest in the FeedGroups. I think it is a refactoring topic. Throwing it out here for people to consider if they might already work on refactoring in this area or are faster than me.
Open for discussion, suggestions and comments.
Also related to matrix talk about updating
https://matrix.to/#/!vnsDQotAJWVaEcyzMl:matrix.newpipe-ev.de/$AuPgky9HWNJgz_RRDvgW1o4A6ZNHEbU9lDOKAxopzr8?via=matrix.newpipe-ev.de&via=matrix.org&via=tchncs.de
Hello everyone - I just found out that Google has lowered the "bot detection" parameters again - newpipe subscription updates have started to get the user temp-blocked again (I'm getting "please log in" prompt after updating subscriptions)... the whole update mechanism likely needs a change to async (and with some kind of sheduler to distribute calls and to update seldomly updating channels less often). Also noticed that Google now seems to also limit streamed time and blocks access after a certain amount of watched videos in a row (a few hours).
https://matrix.to/#/!vnsDQotAJWVaEcyzMl:matrix.newpipe-ev.de/$618Wp7QUi3lkTvwviDAuZGJjOgNt1QUOCAg7JaDduTw?via=matrix.newpipe-ev.de&via=matrix.org&via=tchncs.de
Well I'm also rather new here(no authority) but to me that sounds like it will go partially into rewrite theritory. I suggest one looks into rewriting the internal updating status/progress reporting too. It is currently still geared towards only one feed being updated sequentially. I'd prefer if there is a global indication of "work being done"(like the feed updating notification) maybe a spinner in the header bar, while the progress bar would 1. be limited to the specific page(/feed/tab) being updated and 2. be "cancelable" (e.g swipe uf for it going away and return back to interactability on the old feed list prior to completion), since blocking user-gui interaction is not actually required for updating We currently have a change in thge dev branch with the Option to have multiple custom feeds("Feed groups" or "Channel groups") in the main page. Updating a smaller set of subscriptions individually will likely also alleviate some of the over the top update request frequency leading to temp-blocking
