bbernhard / nextload-client

3 stars 3 forks source link

Android APK #4

Open mateuszdrab opened 4 years ago

mateuszdrab commented 4 years ago

Hi

Is there any chance the Android APK could be published in the releases along with a Windows and Linux variant?

Thanks

bbernhard commented 4 years ago

Hi,

I'll upload the Android APK and the linux AppImage later. I'll have a look, maybe I can also create a Windows build. (need to prepare my windows machine first, so this will probably take a bit longer)

I originally wanted to upload the APK to the Google Play Store, but I am pretty sure that the app will be rejected ;-) It's a pitty...having it on the Play Store would have made updating the Android app way more convenient...

mateuszdrab commented 4 years ago

Don't even bother... Anything that downloads from YouTube is a violation of the t&cs. 😂

Don't you think that perhaps instead of creating a dedicated app for each platform, a simple web page would perform better and would be platform independent.

Would just store the token in cookies and utilise rest API to upload the file to nextcloud.

I actually came up with a completely different process of how this entire process could be achieved - let me know if you want me to explain.

bbernhard commented 4 years ago

The Linux & Android versions are now available here: https://github.com/bbernhard/nextload-client/releases/tag/0.1

Although both versions should work I've tagged them as "pre-release", mainly because it wasn't tested by many people yet. So, it's still possible that there are some "works on my machine" bugs in there ;-)

Don't you think that perhaps instead of creating a dedicated app for each platform, a simple web page would perform better and would be platform independent.

Would just store the token in cookies and utilise rest API to upload the file to nextcloud.

I actually came up with a completely different process of how this entire process could be achieved - let me know if you want me to explain.

Agreed, a UI would definitely be better suited. But I am not sure, if there's much demand for that?

I mean, there's already ocDownloader which is pretty well maintained and has it's established user base. So, I guess most people that want to have a web UI would probably use ocDownloader?

My main motiviation for creating nextload-core was, that I wanted to have a mobile app for downloading YT videos/audios. Unfortunately, ocDownloader was missing some API calls back then, so I couldn't use it as backend. That's why I created nextload-core.

Later, the missing API calls were added to ocDownloader, so I also added the ocDownloader backend to the nextload-client (see https://github.com/bbernhard/nextload-client/issues/1). So, nextload-client is now capable of using either the nextload-core or the ocDownloader as backend.

mateuszdrab commented 4 years ago

Thanks buddy

I installed it and it logged in fine, but the UI is a bit small in considering the big Note 9 screen.

1440-2960-max

I can't seem to be able to select any of the other file format options either, only MP3 is selected however I realised the other day that when I manually create a yml entry in the nextload folder without the type stance, it downloads mp4 files just fine.

Would it not be better to just allow for the file type to be determined by youtube-dl?

I think it selects the best format available and depending on that, the file type might be different.

In regards to ocDownloader, it failed to download completely from a non-youtube source (which is supported by youtube-dl anyway). Which would be related to the fact it uses curl I guess. Either way, that solution was too much for what I needed atm, though, the support for Aria is interesting as I tried Aria before.

bbernhard commented 4 years ago

I can't seem to be able to select any of the other file format options either, only MP3 is selected however I realised the other day that when I manually create a yml entry in the nextload folder without the type stance, it downloads mp4 files just fine.

I just checked in the sourcecode and it looks like as the options were greyed out on purpose by me. But I think it wasn't due to technical restrictions...just laziness on my side. (I only needed mp3 ;-))

I'll have a look :)

Would it not be better to just allow for the file type to be determined by youtube-dl? I think it selects the best format available and depending on that, the file type might be different.

I guess that would also be an option. I think I went with the "explicit file type" approach back then, because I had an old mp3 player which only supports mp3s and nothing else.

In regards to ocDownloader, it failed to download completely from a non-youtube source (which is supported by youtube-dl anyway).

aaah, ok, didn't know that :)

I guess in that case a dedicated web UI would probably make sense :thinking:. Unfortunately, I am pretty busy with all the other open source projects, so I probably won't find enough time to do that. But if you/someone else wants to start something like that I could definitely help a bit.

I think it shouldn't be that hard. Maybe it's not even necessary to create REST API endpoints, but instead create the yml files directly in javascript and use webdav to upload them to the nextcloud instance. (e.g: https://github.com/tentwentyfour/nextcloud-link)

mateuszdrab commented 4 years ago

I just checked in the sourcecode and it looks like as the options were greyed out on purpose by me. But I think it wasn't due to technical restrictions...just laziness on my side. (I only needed mp3 ;-)) I'll` have a look :)

Cool, yeah, what would be good is if you just made it into audio/video type of selection. Where Audio would enforce MP3 and video would just skip the type: stance in the YAML. This so far downloaded my videos into mp4 but I guess it would determine depending on source.

I guess in that case a dedicated web UI would probably make sense 🤔. Unfortunately, I am pretty busy with all the other open source projects, so I probably won't find enough time to do that. But if you/someone else wants to start something like that I could definitely help a bit.

I understand, let's not overwork it, I think the app is working well as it is, if we could only unlock the video downloading options it would be awesome (otherwise it's of no use to me, and potentially other people). I tried to compile the app using QT with no luck unfortunately.

bbernhard commented 4 years ago

Cool, yeah, what would be good is if you just made it into audio/video type of selection. Where Audio would enforce MP3 and video would just skip the type: stance in the YAML. This so far downloaded my videos into mp4 but I guess it would determine depending on source.

I was thinking about introducing two new formats. Something like bestaudio and bestvideo. (not sure yet about the naming). When those are used, youtube-dl would download the highest quality video/audio that's available. Would that option make sense for you?

31337-4554551n commented 2 years ago

Since Google Play would never allow it, would it perhaps be possible to add the Android apk through fdroid? That would up the exposure of the project, and make it possible for a dumbass like me to use.

I'd love a dedicated app on the phone to get my nextcloud to download videos in the background.

+1 on the best audio and best video options mentioned above btw