This app is great, and I would love to have it on my Windows PC, especially with some features that do not officially exist on the browser version, such as shuffling all videos on a single channel and playback without loading the video (as to not waste data).
I have this idea my self, I guess it's on everyone's mind. @theScrabi IDK how you wrote the code for parsing and all, I believe it is not generic and can be applied to non-Android applications, why can't we go ahead and build one for the desktop using JavaFX or SwingX?
I just thought it would not be possible but I miss an application like that, especially because the official website of YouTube is very slow for old computers (like the one I have). Now, the problem is if in case they manage to carry this application to the desktop, will require low resources?
anyway I think we should first think about this when newpipe for android is already mature enough and with all the promising features that are yet to come (including subtitles, livestream, etc) to think of something even bigger, and enough bugs there is here to think about developing more bugs 😂
I just thought it would not be possible
It is possible. In fact NewPipe is designed to work on multiple systems.
This is an example of a CLI app that graps the stream link out of a youtube link. It works on any device that has network and java.
What you would need to do is embedet the NewPipeExtractor in your code.
think we should first think about this when newpipe for android is already mature enough
If someone is willing to develop it than develop it :D. Just because some people fix the bugs it does not mean all have to do it.
This is an example of a CLI app that graps the stream link out of a youtube link
I saw that example before, but I was thinking about literally the same application of newpipe into a computer, that may cost a bit more?
Or is it easier to think about developing a gui for np-cli from scratch with qt or something similar?
Just because some people fix the bugs it does not mean all have to do it.
It's true, I take it back 😂
@speednroll To answer your question "Now, the problem is if in case they manage to carry this application to the desktop, will require low resources?"
The answer can't be straight and it's highly subjective. If you see a Slack desktop application which is built on Electron framework, if we had built it using JavaFX it will be significantly faster, but, JavaFX applications have long start time due to JVM, as it is said so.
Another option was of cource to write a NewPipe WebApplication. That works with a REST frontend for the NewPipeExtractor.
@phly95 There's already an app for desktops. It's called Youtube-dl and it has a GUI frontend. I personally use it with a player called mpv to play videos directly on my screen but its mostly for downloading the video and/or audio. It's a lot more mature than Newpipe and thus works more reliably.
I know about youtube-dl :D I took it code examples from it to write NewPipe. But as you said yt-dl is mostly for downloading. NewPipe is or should be a full blown client.
There is an app called SMplayer that does youtube, though newpipe has far surpassed it in terms of features, as SMtube has little to no integration with playlists and audio streams etc.
Meybe minitube can be tweaked by us
Hi there everyone! If posts like this aren't allowed, please let me know and I'll gladly remove it.
I've been keeping an eye on the topic of a desktop YouTube client from various places and I've noticed the demand for something like this (especially since I've been wanting something like this myself).
I wanted to wait a little bit longer before I mentioned anything, but since the topic is fresh, I'd like to show a few things to everybody. I'm currently working on a privacy minded YouTube client for desktop that aims to accomplish a similar goal to NewPipe. I've decided to call it FreeTube and my plan is to Open Source it once the core functionality is finished.
The app is built using Electron and uses the YouTube API to acquire data. It doesn't look like the NewPipe Extractor supports Electron but I would be interested in implementing it in the future if I'm wrong.
Here are a few pictures with some information as a proof of concept:
https://imgur.com/a/53Ahu
I hope that anyone interested in making a desktop client would like to help me out when I get this released. The plan is to have it ready for initial release in a few weeks.
Thanks!
in my opinion, Electron is slow, it is reserved only for computers with mid and high resources. in that case I prefer to use the official YouTube page instead, since both would require the same amount of resources.
one of my first reasons why I search alternatives like newpipe is how lightweight it is.
I can't argue with that too much. I understand that a few people have issues running Electron on their machines due to the resources that it uses. While I am trying to keep it as fast as possible, my main goal with this application is privacy. If my application runs at about the same speed as YouTube, but delivers a more private browsing experience, then I feel like I was successful. I hope to do better than that of course but I'll have to see what happens when I get there.
Regardless, I respect your opinion and I understand why you think that.
@PrestonN isn't electron just some reshaped chrome browser? So what you are working on is essentially a website that is running as a desktop app? Am I right?
So point is @speednroll is right when he says that electorn is slow. However I thought about having some sort of NewPipe website. Maybe then what you are working on could be interesting. Honestly I like it already :D
For the connection betwean FreeTube and the NewPipeExtractor we could use the REST Api for the NewPipeExtractor that I suggested erlyer, and which I'm willing to implement once multyservice turns out to work well :)
@theScrabi you are right in that Electron is a desktop wrapper based on Chromium. I do believe that they remove a few things from base Chromium in order to help it run faster, but I'm not 100% certain.
The main reason I'm using Electron versus a website is that the audience that I'm targeting will most likely remove cookies from their browsers fairly often, if they save them at all. This will make it difficult for them to save their subscriptions without creating some sort of account. I'd assume that this is a big reason as to why similar websites such as HookTube do not include such a feature.
Electron allows me to save data such as subscriptions to the user's local storage without having to store cookies through the browser. This helps keep it separate from their browsing history and prevents any trackers that may occur.
Using the REST API for the NewPipeExtractor sounds promising. I'll definitely want to take a look at it once it's ready on your end. My plan for an initial release is to keep going in my current direction but I'd love to take a look at it later in the future.
Maybe the Linux version could be built as an Appimage. @probonopd might know
Is there a Linux version @Serkan-devel? Where can we get it?
@probonopd it should be packaged as one first
But, if you think about it... what's the whole point of building a desktop version... we use NewPipe cause we can play it in background and pop-up player... No tracking. I don't think it'll pan out good, it's better if we keep making this app better just my thought guys.
@Hashik-Donthineni you may use it this way. I'm not, so I was happy to see a desktop/web version however we need more developer. So that the once that develop the android app can continue to make it better. I agree to U on that point :)
@probonopd it should be packaged as one first
I am a little bit confused since I was under the impression that this was a native Android (Java) app. I don't know how to package Android apps for Linux desktops (besides shipping a full Android emulator/VM, which I'd consider overkill).
@theScrabi would it be feasible to package the Newpipeextractor with a cross-platform qt-frontend for desktop use?
yes, in fact I've been working on embedeting java into cpp applications. However I would recomend to use it as a seperate programm.
Here this gist will create an executable with included openjdk and avian JVM, however I think atm its failing because I couldn't get proguard running. On an x86_64 linux machine with java8 installed you may want to run make
https://gist.github.com/theScrabi/5aeb06b1669243e270c8f705716265bc
Here's a link to FreeTube because it wasn't linked so far. Gonna give it a try :)
@PrestonN FreeTube is ultra awesome :heart_eyes:. I Would love to see a NewPipe version of it :D.
@theScrabi thanks for the kind words, it means a lot coming from you. :)
There's still a ton a work that needs to be done with it. It's missing a few key features that people would expect something like FreeTube to have if it was a stable release. Regardless, the features it does have seem to work well and I've been very pleased with the response it has had so far.
I would love to get the NewPipe Extractor working on FreeTube as I'm currently stuck with the YouTube API for now. Let me know if there's anything I can do to help/test with it.
FreeTube IMO feels little unfinished, don't get me wrong it's amazing and a lot of work is put into it, I mean couldn't they just copy YouTube's theme? Feels weird using it. The idea and the implementation are excellent, but the UI feels humm.. unfinished is the word.
Semi-OT, you may also be interested in https://hooktube.com/.
If you guys remember how NewPipe looked in the beginning you would support freetube further. It even looked a bit like freetube now.
@PrestonN As I mentioned, my plan is to wrap the extractor with a REST/Json API, so it can easily be accessed from any device/os/lang. I guess that was perfect for freetube. You could easily reduce bloat, since you wouldn't need ytdl anymore.
We can talk about how to implement it :)
So for the rest api this would be a good starting point:
https://jersey.github.io/
After I'm done fixing the search engine and documenting the extractor for multi service. I think this would be a cool task to do :D
Isn't there a java API for qt?
The reason why i thin REST is good is because with that wed me more flexiple than only exposing the extractor to c++
What about GraphQL? I did work with REST but not with GraphQL, heard it's good. The GitHub API v4 is GraphQL.
Well i through about god old ugly JSON, because it's good supported by many platforms, and simple to debug.
But if we want to discus about other protocols we can do that. Maybe we also want to consider Protocoll buffers
@TheAssassin @PrestonN what is your opinion about this?
@Hashik-Donthineni Though I must say, that I kind of like the idea of how GraphQL does things :D :
https://www.quora.com/When-should-I-use-GraphQL-for-my-web-application
@theScrabi what do you need feedback for?
GraphQL
GraphQL is overkill in my opinion.
@theScrabi Using REST would work better only because FreeTube is already structured around that and I'd be able to work on implementing the extractor quicker. GraphQL should work though if that's the route you go with.
A standard JSON RESTful API will probably suffice, yes. I doubt that the extra level of control (i.e., data filtering) etc. that GraphQL allows is needed. And querying is easier, too.
I don't know, the way you query with GraphQL is also quite strait forward. I quite like it.
However what really matters is what someone implements, and if the implementation is good we'll take it.
There is this Google Functions ( or Firebase Functions, I don't remember) in Firebase it's still in beta I think we can use it for the API?
No firebase.
The reason is that NewPipe should be crept google independent. Therefore we should try to use as less google services as possible.
They are working on a universal web push api instead but it's just a draft by now https://developer.mozilla.org/en-US/docs/Web/API/Push_API
Yes, I understand. I think it's about time someone starts on this, I think NewPipe is good enough on the mobile. I think it's hard to find people who work on the desktop version.
@Hashik-Donthineni thats why I am open to any whay of implementaton. @PrestonN already has something. That's a beginning.
I think once we have a working prototype people will come. And help.
I heard Hooktube is going to die out which was a good way to watch YouTube videos with privacy from Google. But desktop app of NewPipe would be better than a website since there will be costs to hosting a website. I would suggest using Electron or something similar so you are able to easily able to develop the desktop app for Windows, Mac and Linux.
If there is a desktop a needed feature is syncing subscriptions, and playlists between your phone and desktop device. Syncing through a cloud would be best. There will be some challenges for the video player and a video player. I know Plyr is a good video player which is what Bitchute uses.
Also you could work with the guys at FreeTube and come togeather. There making a YouTube app for the desktop which is just like NewPipe (But NewPipe is still better!)
Electron wouldn't be a good option due to the immense overhead of memory consumption while running.
Newpipe is anyway written in Java, maybe it would be better to write the UI in qt and use a native desktop player, like vlc?
and use a native desktop player, like vlc?
That would be something I'd like to propose anyway.
However for me it does not matter it which language it is written, as long as someone does it.
(Hint: We still need a REST or GraphQL frontend for the extractor ;D )
@theScrabi have you looked into a GraphQL frontend instead?
I did. I like it.
(Hint: We still need a REST or GraphQL frontend for the extractor ;D )
I'm guessing this means that there hasn't been too much work towards this? I'd be more than happy to use the extractor with FreeTube when it's ready. The recent stuff with HookTube has definitely made me eager to get started and get rid of YouTube's API. I have plenty of things to do in the mean time until it's ready though so no rush. :)
Well at the moment I'm still more concernet about the stability of the Android app, and the Multyservice project. I don't have the time and the resources to also make a desktop project at the moment. If we want to make this happen Someone had to take care about the interface.
(Hint: We still need a REST or GraphQL frontend for the extractor ;D )
Why would we need that for a desktop app? We could just directly use NewPipeExtractor (or through JNI from C/C++), right?
QT and java in the same executable can be done but I'd see pain in it.
I mean we can do it that way, but I wanted to put a rest Api to it anyway, since it'll add more flexibility. Say if we want to do a kody plugin, or a web version.
*kodi
@theScrabi: And from Python (or most other languages) you could call C/C++
code (which could call the Java code with JNI), there are libraries like
PyJNIus for that, but I don't know how good they work. Also not neccessary
Qt, GNOME (GTK+, GStreamer, etc.) is also an option, or even WxWidgets
(which uses GTK+/Win32/Cocoa depending on the OS) Or we could use a GUI
wrapper for Java, like java-gnome (which doesn't support Windows, so that
wouldn't be a good option). Btw a web version of NewPipe would be
impossible to do legally, because of CORS.
>
For Python applications, Jython might help, as it has _direct_ access to the functions.
Any sort of "API bindings" is usually a PITA to maintain. I'm with @theScrabi here, it makes more sense to provide some sort of standalone API application that can be called via subprocesses, this is easier for everyone. All the data is then properly serialized (e.g., to JSON), and can be deserialized by consuming applications.
@TheAssassin: Like D-Bus (does that work on non-Linux platforma though?)?I
totally agree, I was just listing other options. I do think calling a HTTP
API isn't the best option for the desktop app though.
Op za 28 jul. 2018 19:58 schreef TheAssassin notifications@github.com:
For Python applications, Jython might help, as it has direct access to
the functions.Any sort of "API bindings" is usually a PITA to maintain. I'm with
@theScrabi https://github.com/theScrabi here, it makes more sense to
provide some sort of standalone API application that can be called via
subprocesses, this is easier for everyone. All the data is then properly
serialized (e.g., to JSON), and can be deserialized by consuming
applications.—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/TeamNewPipe/NewPipe/issues/1051#issuecomment-408624835,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AJU76cDtQ__yKVjG-eMQheJBmfGlLAfyks5uLKY0gaJpZM4Ry9bM
.
No, just by creating a subprocess that provides an HTTP API. This is very simple, and works fine cross-platform.
OCS-Store, the client application for https://opendesktop.org stores, works like that. See https://www.opendesktop.org/p/1175480/.
Possible workflow:
bind()
to it to see whether it's free for use)fork()
s (and gets the forked process's ID)setenv("PORT", "12345")
)exec()
s NewPipe Extractor API processhttp://localhost:port
, and can monitor and manage subprocess@TheAssassin: So if I understand you correctly, you want something like the following example?
Well, "want", it's just a proposal. But yeah, this is pretty much what I suggested, conceptually.
The magical part is the negotiation of the port that is used for the API. This is the most crucial part in such an architecture. Using fixed ports basically prevents using multiple instances.
No, just by creating a subprocess that provides an HTTP API. This is very simple, and works fine cross-platform.
Excactly. :)
And from Python (or most other languages) you could call C/C++ code (which could call the Java code with JNI)
Which means you have to use 3 Languages in one ... process or executable. It sounds cool, but it's probably not easy to compile, complicated to understand, and hard to maintain. So two executable would be the way to go, and since we would use a network protocol you could think of even more like dockerising the extractor, or running it on another machine or what ever. Your just more flexible.
A related aside for Linux users only - Anbox, which allows one to run Android applications on any GNU/Linux operating system.
How about a complete port to Qt? You can compile to all major platforms.
I think that has been suggested earlier
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
The problem with a port is that someone will need to maintain it. Youtube changes things that break extraction. Writing a scraper for youtube is trivial in most languages with mature scraping infrastructure, the maintenance is the problem ergo the value is in reusing something that's already being maintained.
@paulie-g the extractor itself was extracted to be able to further reduce the amount of dependencies. It's quite portable, AFAIK. I suppose the frontend might be a bit of an issue (I guess a desktop version is pretty much a separate code base), so I guess someone should take care of that as a project separate from NewPipe.
As the assasine said. The NewPipr extractor is written independent from Android. Actually for testing we already let it running on a PC. So if you want to write a Desktop app you only have to call the functions provided by the Extractor, and dont need to take care about Youtube at all.
ill look into this subject on my own, but im not sure how far ill get
@TheAssassin @theScrabi You've either misunderstood me or misdirected your reply.
I am aware that Extractor has been made modular specifically to make it available for use in other projects. I think this is fantastic and shows that the devs cared enough to think ahead and put in the work so others could reuse their code in future - this is commendable. I think the NewPipe app itself is great, and the Extractor is the best full-scale youtube scraper (ytdl is limited to what is needed for downloads, everything else I've found works badly - especially yt api clients).
I, too, was interested in a desktop client, specifically a lightweight one - I often have dozens of videos open and paused at a time and don't want to pay for that in webengine memory usage. mps-youtube works well for music and I'd love to have a similar terminal client that has the features one needs for subscriptions, playlists, and so on. This is how I ended up reading this issue.
The point I was trying to make is that the value of Extractor is not just in the work that went into getting it to this point, but in the work the devs do in keeping it up to date. You can port it to [insert language here] at a given point in time, but even if you're able to make a very literal port - and that's not a foregone conclusion - you would still need to commit to continue porting all the updates in a timely manner to keep your client working. Therefore, unless that is a time commitment someone wants to make, it would be better to find a way to reuse the Extractor as is. That's all I was saying.
Incidentally - other than a compact, well-maintained port to something lightweight more in keeping with my own desires (c/rust/go) - I think packaging Extractor as-is in a server that can be fork()ed and talked to via a pipe is the best option. This way, whatever happens, any clients that use it will keep working as long as the NewPipe devs keep the original extractor up to date. Whether that can be made lightweight is another matter, and java is java, but that's not a requirement for most people (they may not want a 1+GB PSS of electron, but if QT is acceptable to them, so will running a jvm be).
Incidentally, the recommendation of using Avian (a lightweight jvm alternative w minimal class lib) seems reasonable for those who'd like to attempt this. I just submitted a PR for Avian that fixes compilation issues on modern Linux systems, so anyone who wants to play with it for this purpose can now do so (apply PR first - it won't be merged as Avian isn't actively maintained, but it works just fine).
Recently, YouTube gets more and more annoying, even with lots of ads and JS blockers. I think there's more and more potential for a desktop version of NewPipe...
I think freetube serves the purpose so there is no need for the desktop version of new pipe.
https://freetubeapp.io
but it relies on a 3rd-party service called invidious to function https://github.com/FreeTubeApp/FreeTube#how-does-it-work . If that service goes down but youtube doesn't, that client won't be usable
Also NewPipe is more than just an youtube client. One can also fetch content from soundcloud and from the ccc-library with it
Freetube is still in beta ,if you want new features you can contact the developer and freetube relies on invidious to avoid the problem of updating the app (like in newpipe) every time youtube changes there api
Also you can import new pipe subscriptions in freetube
I wanted to post the same issue also). And tryed to find some desktop app and didn't find it so comfortable like NewPipe! Wait for desktop version of NewPipe so much! Is it built of java, yes?
Is it possible to place it in todo list, please?
Many thanks in advance!
@DI555, check out FreeTube or MiniTube.
Just a thought. If I were Google, I wouldn't like an open source stand alone YT player which destroys my business plan. I would try to change things that bypass commercials would be impossible. They did this on web browsers already.
I like the idea to have a newpipe on pc, but I'm afraid of waking up a sleeping dog, which would kill Newpipe on android as a side effect too.
@isayso I truly doubt YouTube is actively trying to do any of that, considering a simple adblocker can bypass ads for the millions of Firefox users who way outnumber NewPipe users. Anyways, FreeTube already exists and has not had any such issues.
I hope you are right. Lets enjoy Newpipe.
But you must add the Kodi users. I see the fight of the Video Kodi addons, they work often only a few weeks, Kodi itself fights against illegal streaming addons. Lawsuits from media companies against adblockers, new chrome development with less blocking capabilities. We will see.
Kodi only has legal issues because the videos there are paid videos. NewPipe doesn't provide any paid videos. If it started giving access to YouTube Premium videos, then it would get shut down fairly quickly.
i would love a PC version that syncs with the Android app!
Another option was of cource to write a NewPipe WebApplication. That works with a REST frontend for the NewPipeExtractor.
this is a great idea!! means a lot less extra development. + i would really love something that syncs my android playlists and favs to my laptop
Hi there! What about a PWA then? @theScrabi
Or maybe people would rather a standalone app like a Qt or Go app (which would be ironic)?
@rkyoku as a web app you can already use https://invidio.us
@Stypox thanks for that! However, we are talking about expanding NewPipe here, and I thought I understood that theScrabi was hyped about that cross-platform app idea.
@Stypox thanks for that! However, we are talking about expanding NewPipe here, and I thought I understood that theScrabi was hyped about that cross-platform app idea.
yes i agree, i use invidious too, but it would be great to have one of these video-watching applications (newpipe is my fav) be cross-platform and able to sync favourite videos and channels across devices. Also i think invidiou.us is only for Youtube, the great thing about NewPipe is that it is potentially for ANY video- or audio-sharing website. Atm it also includes Soundcloud and Peertube will also be included in the future!
Yeah, I see what you mean
PWA
to add to this: i think a PWA is a really good idea. It appears to rapidly become the future for apps. + it takes less time to develop + cross-platform by design
Btw, PeerTube was included very recently in 0.18.0 ;-)
ah great! i hadn't seen that yet
PWA
to add to this: i think a PWA is a really good idea. It appears to rapidly become the future for apps. + it takes less time to develop + cross-platform by design
My point exactly :)
No promises here, but I might be able to allocate some time to lend a hand if this is the decided way to do it (and if help is needed @theScrabi ).
Existing solutions:
Note: all above effectively require playlist/video url.
@theScrabi
I just thought it would not be possible
It is possible. In fact NewPipe is designed to work on multiple systems.
This is an example of a CLI app that graps the stream link out of a youtube link. It works on any device that has network and java.What you would need to do is embedet the NewPipeExtractor in your code.
Where is the np-cli repository now ? Has been removed ?
Big +1 for a Linux client
Where is the np-cli repository now ? Has been removed ?
There seems to be a fork/mirror but not sure how up-to-date it is. I'm also curious why it was removed.
@yardenac: It's not up-to-date at all, plus np-cli was never really useful.
Hi, I like do big +1 to this and I happily contribute some Bitcoin to crowdfund NewPipe as Desktop App.
Uhm what about chatting with desktop client devs and making a standard output file and a option to sync over cloud (maybe nextcloud) that way people could sync newpipe with freetube and others could just join in and use the foundation for more applications like those?
Most helpful comment
Hi there everyone! If posts like this aren't allowed, please let me know and I'll gladly remove it.
I've been keeping an eye on the topic of a desktop YouTube client from various places and I've noticed the demand for something like this (especially since I've been wanting something like this myself).
I wanted to wait a little bit longer before I mentioned anything, but since the topic is fresh, I'd like to show a few things to everybody. I'm currently working on a privacy minded YouTube client for desktop that aims to accomplish a similar goal to NewPipe. I've decided to call it FreeTube and my plan is to Open Source it once the core functionality is finished.
The app is built using Electron and uses the YouTube API to acquire data. It doesn't look like the NewPipe Extractor supports Electron but I would be interested in implementing it in the future if I'm wrong.
Here are a few pictures with some information as a proof of concept:
https://imgur.com/a/53Ahu
I hope that anyone interested in making a desktop client would like to help me out when I get this released. The plan is to have it ready for initial release in a few weeks.
Thanks!