Multiple services

[ghost]

I've started to implement multiple services support for NewPipe. At the moment you could select a service with a setting, since I didn't have time to mess around with adding a drawer.

• Another layout for audio-only streams as per Other Services UI #650 (comment)
  • Hide video quality selector
• Drawer for selecting services as per Other Services UI #650 (comment)
  • Move the things from the ⋮ menu to the drawer
  • Show which one is selected
  • Change the primary color (i.e. red for YouTube and orange for SoundCloud)
  • Make the kiosk selection working
• Add intents for opening SoundCloud links (can those be automatically generated?)

[theScrabi]

👌 tho can you make the triangle for selecting multiple streams disappear when only one stream is available.

[ghost]

@theScrabi: That's what 442290d was for, but I didn't test it yet, so the screenshot is still from a6eb871. I also think we should use another play icon. Besides that, the upvotes and downvotes are always displayed as 0 for SoundCloud, while the downvotes should be hidden for SoundCloud (the extractor should return -1 instead of 0) and the upvotes should say the actual number of likes. It also asks a lot if I want to report a crash.

[theScrabi]

I remember, I once implemented it in a way that if you return invalid values form the extractor the corresponding widget will get hidden. I don't know if that still applies.

[ghost]

@theScrabi: There's an if-statement that checks if both the upvotes and downvotes are -1 and then hides them.

[mauriciocolli]

@theScrabi yes, it still applies.

@wb9688 actually, it checks individually, so returning -1 should do it.

[ghost]

@mauriciocolli: Then I've looked at the wrong place. Btw I've changed the base to dev. But since I'm working on PipeCast (and kinda hate Android's layout stuff), I probably won't be able to continue with this PR, so could you (or @theScrabi) finish it please? Thanks!

[theScrabi]

I'll take a look at it.

[ghost]

@mauriciocolli: After updating NewPipeExtractor, the likes are still incorrect:

It also still gives an NullPointerException on com.grock.nanojson.JsonObject.getArray in org.schabi.newpipe.extractor.services.soundcloud.SoundCloudChannelExtractor.getBannerUrl.

I think I can fix them if you want.

Edit: I've fixed the NullPointerException.

Edit 2: I've also fixed the likes count, please merge TeamNewPipe/NewPipeExtractor#32.

[ghost]

So I've started working on a really simple drawer. It looks like the following:

However, I should still do a few things:

• Move the things from the ⋮ menu to the drawer
• Show which one is selected
• Remove the service setting from the settings
• Change the primary color (i.e. red for YouTube and orange for SoundCloud)
• Fix the merge conflict
• Make the kiosk selection working

[ghost]

@theScrabi: Like I've said before, I'm a n00b with Android layouts and views and stuff. What stuff do I need for that UI from #650 (comment)? And how would I add the correct intents? Thanks!

[karyogamy]

Assuming you are wrapping the existing FrameLayout with DrawerLayout. The drawer button should be automatically created for you. You can then substitute the ListView drawer with a custom view (or layout), where the top and bottom are the stationary header and footer (for settings and such) and the original ListView in the middle. Take a look at how the view for channel fragment is built.

I'm not sure what you meant by adding intents though.

[ghost]

@karyogamy: 'Assuming', well… you could check what I've done in my last commit. ;) With intents, I mean those Android-specific things that allow you to open links in an app. NewPipe already has intents for YouTube, but I wanna add them for SoundCloud, but I don't know how that works.

[karyogamy]

Ah sorry, my bad. I did pull your repo, just that I forgot to change the branch and thus saw no change =P

For the drawer header and footer, maybe this answer can help you out. Though, adding a footer like in #650 might not look material design.

As for the share intents, go down the rabbit hole of RouterActivity and RouterPopupActivity. Or just debug through getIntentByLink(Context context, StreamingService service, String url) on NavigationHelper.

[ghost]

@karyogamy: Oh, OK, it happens to all of us. ;) Won't I also have to do some stuff in the manifest? Btw thanks!

[karyogamy]

No problem. Yeah, you will also need to add soundcloud to the manifest if you want to open direct links (not from share) in the app.

[theScrabi]

@karyogamy could you cherry pick the drawer into a seperate branch? Id like to work on it to.

[ghost]

@theScrabi: Why would we? Iirc GitHub has a checkbox to allow the maintainers access to your fork (which I had checked iirc). And else I'd also be able to push this to another branch here.

[ghost]

I was looking at adding SoundCloud intents, but I discovered I don't have support for m.soundcloud.com in NewPipeExtractor.

[theScrabi]

@wb9688 I honestly tried out this changes for the first time, and depside there are many things that don't quite work perfectly yet, I really like it already. It's really usable :)

So my plan would be to release the beta app soon, so we can make the soundcloud service available in the beta version. In the normal version I would still keep multyservice back until it's releasable.

Also I merged your changes into a branch here:
https://github.com/TeamNewPipe/NewPipe/tree/multyservice
I did this so I can add some changes. You could also switch to that branch since you have write access to this repo now.

[karyogamy]

Just my 2 cents, but wouldn't doing this make it really easy for copycats to just remove the Youtube part of the app and release it on Play store? Without the Youtube part, Google would likely lose any incentive to pull copycats off the store since NewPipe is open source after all.

[theScrabi]

@karyogamy
You are right, I haven't thought of this.

1. But unless they don't violate the GPL we can still have them removed.
2. Now in case someone puts a copy into it and make it GPL aligned we'll have a problem.
   The question now is why would a copy cat want to put a copy of NewPipe into Playstore?
   Probably to put ads into the app and earn money with that.

Could we still find a way to legally prevent that?
Probably by changing the license. :/ @TheAssassin Would you know another way?

3. If someone is selling a copy of NewPipe (or NewPipe itself) without ads in the PlayStore it would be the most dangerous thing that can happen. GPL does not prevent that.

Another way would be to sell/distribute NewPipe on the PlayStore ourself, but I wouldn't want to do that with a not releasable version.

[karyogamy]

Another way would be to sell/distribute NewPipe on the PlayStore ourself, but I wouldn't want to do that with a not releasable version.

This is what I was thinking as well. Though Google has a tendency to shot (i.e. pull questionable apps down without reason) first and ask questions later, so even doing this might not be our safest bet.

As for it being unreleasable, I guess under the worst circumstances we still can develop version 2 internally on BitBucket under a different license, and then migrate the code over here again once we are ready to release on Play.

[TheAssassin]

Any free software license grants anyone a perpetual(!) usage right, including modifications, redistribution with/without modifications etc. That's the spirit of free software. Without picking one of those "we publish the source, but don't allow modifications and also don't want you to redistribute it" licenses, it's impossible (and undesirable) to prevent people from making use of the source code. You can't do anything about it legally. And most measures you guys suggested are totally against the spirit of free software in a similar way the rebranding self-entitled "app developers" are.

Developing in secret doesn't solve any of these issues, especially when releasing the source code after publishing the app first.
Not being a fan of Google Play etc., I'm always critic to publishing software, and especially free software, on such platforms (you never know in what ways they modify the binaries).
Another problem is Android, as being mostly proprietary, is a difficult platform for free software anyway. You're always subject of misuse, and even if the illegal copies are just online for a few days or weeks, they might generate enough revenue for the publisher, hence rendering any takedown pretty useless.

Here's a few options I thought about:

• We could add a constraint to the license forbidding any publishing on Google Play (and those Asian and Arabic app stores) without consent of Team NewPipe's administrative board. This would be a measure that you could enforce legally, especially on Google Play (because suing someone in Arab countries is difficult, extremely expensive, and these states might not even acknowledge local copyright laws). However, that also means we'd have a proprietary custom license, which leads to a lot of issues with other systems such as F-Droid, and eliminates our status as free software project. It might even prevent further inclusion there.

• You could also add a constraint that adding any kind of advertising would be a violation of the license. But this has the same implications as the above suggestion.

• Protect the term NewPipe as a trademark (expensive and difficult). Then you also have the power of trademark protection, and could enforce legal actions if the rebranded apps work and look like the original, etc.

People are free to sell copies of NewPipe, yes, even after rebranding (but they must always show who's written the original source code). The "danger" you mentioned is probably in us performing the entire development, while someone else takes all the credit. Well, I wouldn't be happy with that either, but before we'd sell NewPipe ourselves or adding proprietary clauses to the licenses, I'd rather try to accept and tolerate that. If you're working on free software only because it'd look good in your CV, what's the point of developing free software then, right? Just make it proprietary and you're good to go. And I'm pretty sure that's not the way @theScrabi would want to put things.

Another option to keep as many pieces as free software while preventing illegal forks etc. would be to keep core components such as the extractor in separate projects, while making only the frontend code proprietary in the ways @karyogamy suggested.

But please rethink your ideas. They're strongly opposed to the idea of free(!) software and even open source (in the way that you publish source code with a proprietary license). I personally think you should stop worrying about code being stolen or rebranded so much. It's sad, but you can't really do much about it, and should invest your time in more useful tasks. Instead, try to gain more publicity, tell people about the issues we experience as a popular free software app, and make sure people add negative votes to bad copies. That'll increase the visibility of NewPipe as the original project, and as soon as people start acknowledging NewPipe as a thing, they'll recognize the illegal rebrandings, and their business will go down. (They'll probably find another target anyway, but well...)

P.S.: Maybe (and that's a big maybe) we can even sue some of the rebranding assholes (offensive language, but that's just the sad truth...) for abusing our error reporting service by setting up some Terms of Service document which we also publish in this repository. But I'm pretty certain the costs (talking about time and money here) outweigh the benefits by far, as with any other legal action. Furthermore, I think the users (who most likely don't know any better) would be the ones to put legal claims upon in most non-EU/US countries, and you can't really punish them for being spoofed by some bad guys.

[theScrabi]

All right, I agree to most of @TheAssassin way of thinking, and after sleeping a night upon all this I think that we surely shouldn't worry to much about copys at the moment.

[TobiGr]

@theScrabi As you already merged, where should we collect all issues and bugs regarding SoundCloud?
There are some issues left like:

• I can't go back to search/main page after selecting a video from the SoundCloud search.
• incomplete / wrong / missing music meta data (e.g. website says music was published on 15th September and app says 8th September.)

[ghost]

@TobiGr: The last case is because, that track has a different create and release date and NewPipeExtractor always uses the create date. Since NewPipe uses api for streams and api doesn't have the complete release date, unlike api-v2, we'll have to change the code to use api to resolve, but not redirect (like we do currently), replace api with api-v2 in the URL and then fetch that page. It looks like the time is 00:00 anyway, so it'd be easy then. But do we want to use the release date (that's always without time)?

[theScrabi]

Well multyservice will not be part of release, and it had to be done anyway.