5 ms·

Anybody using / looking for a heavy client (a desktop app) for Youtube? I'm currently working on that in C++ (Qt). For now it's just small window presenting a s

Anybody using / looking for a heavy client (a desktop app) for Youtube? I'm currently working on that in C++ (Qt). For now it's just small window presenting a searchbar, the list of search results and suggested videos. Playing the vid / playlist is done by opening a separate vlc window.

parmezan 5y ago
Alternative yt desktop app is https://freetubeapp.io/ https://freetubeapp.io/
- stragies 5y ago
  Or the native cross-plattform opensource Minitube from https://flavio.tordini.org/minitube https://flavio.tordini.org/minitube . Is already available on most systems through the package manager.
kragen 5y ago
Right now I'm using these kind of shitty shell scripts to download the videos, ls to list them, and mpv on the command line to play them. These use a file called "channels" which contains YouTube channel URLs and space-separated tags, like this: https://www.youtube.com/channel/UClaEdLrmti779-tyovta8zw grandpa amu hardware carpentry hacking https://www.youtube.com/channel/UCLt9kIslIa1ffiM8A04KORw wm levsha hardware hacking Here are the scripts, slightly cleaned up: snarf: #!/bin/sh echo "snarf $@" exec python3 ../youtube-dl -f '[height<769]' -i -r 1M -R 1 \ --sleep-interval "${wait-227}" --max-filesize "${max_filesize-242m}" \ --no-mtime --playlist-end ${n-5} --write-info-json --add-metadata \ --write-description --write-thumbnail --write-auto-sub \ --write-sub --sub-lang en,es "$@" snarf-tags: #!/bin/sh exec ./snarf $(./tag "$@" | shuf | sed 's,$,/videos,') search: #!/bin/sh exec ./snarf ytsearch10:"$(echo "$@" | sed 's, ,+,g')" resnarf: #!/bin/sh : ${1?Usage: $0 foo.mp4.part} # example: garbage\ stuff\ -zKLMCO0-How.mp4.part for x in "$@"; do x=$(echo "$x" | perl -ne 'm,(.{11})\.mp4,; print $1') ./snarf "https://youtu.be/$x" done tag: #!/usr/bin/env python3 import sys def match(args, line): return (not any('-' + word in args for word in line) and not any(word not in line for word in args if word[0] != '-')) def main(args, input, output): for line in input: words = line.split() if match(args, words): output.write(words[0] + "\n") if __name__ == '__main__': main(sys.argv[1:], open('channels'), sys.stdout) So my searchbar is "wait=3 ./search japanese hornets" or "./search electrochemical machining advances", and periodically I run "./snarf-tags" to download any new videos over the next few hours, which I can then see with "ls -lart ./*4". And if I want to know where some great search-result video came from so I can add it to the list of channels, why, that's "jq -r .uploader_url Romanes\ Eunt\ Domus\ EXPLAINED\ _\ Monty\ Python\'s\ Life\ of\ Brian\ •\ Fun\ with\ Latin-UfH6gjxTTgE.info.json", which sounds horrible but it's really more like ^Rjq^A M-f M-f M-f ^K Ro<TAB>. Suggested videos and thumbnail display, not to mention buttons to press for the above things, would be a welcome addition, but thumbnail display is difficult in the terminal. Also, it would be pretty great to have a way to not redownload a video after I deleted it, and for youtube-dl to not wait the 227 seconds before deciding not to download a video because it's a four-hour snoozefest recorded livestream.
- CGamesPlay 5y ago
  Thanks for this! I’m going to be rigging something like this soon, and I have a lot of feature crossover with what you’ve done here.
  - kragen 5y ago
    Sure! I hope it's helpful!
- scns 5y ago
  Great. My first thought was: The inverse of (dual to?) the infamous Dropbox comment
  - kragen 5y ago
    Haha! Yeah, I definitely don't mean to imply that the UX of these scripts couldn't be improved, just that these are some bits of functionality that I've found useful, and some very simple ways I've found to implement them that nevertheless worked pretty well. And, maybe as importantly, it may not be hard to have better UX than 25 lines of shell scripts, but it's even easier to have worse UX, so this is kind of the minimum bar for acceptability.
    - scns 5y ago
      Yeah, there was zero implication about UX on my part though. Instead of just dismissing it with a: "I can do that in 30 lines of Python", you just delivered a solution that works for you and can be built upon by others. Good job, praiseworthy IMHO.
      - kragen 5y ago
        I think UX was precisely the way Dropbox won.
VortexDream 5y ago
That seems interesting. I'd give that a try. I'm not satisfied with any clients I've tried so far.
Nextgrid 5y ago
There's already some competition in this space: https://flavio.tordini.org/minitube https://flavio.tordini.org/minitube
southerntofu 5y ago
I think a lot of people are looking for that. This is especially true for folks with lower-end hardware where hardware decoding may be supported by the system but not (well) by the browser, or at least the rest of the browser runtime would use way too much resources. NewPipe on Android is somewhat popular because it's much lighter than other Youtube clients (browser included) and enables features which Youtube official clients prevent on purpose (audio-only, download). We don't have an equivalent to that on the desktop. gtk-pipe-viewer [0] is close to that, but is not widely available yet. A problem you need to tackle when distributing a 3rd party client for a centralized network is you have to deal with constant micro-changes in the public-facing API, which the silo does on purpose to break 3rd party clients. youtube-dl from distro repos is almost unusable all the time because of that except on rolling-release (most people use pip version instead), and Newpipe had to make their own F-Droid repository because f-droid.org vetting/build process is too slow for that particular usecase. [1] EDIT: If you're looking for solutions to distribute your client, packaging for every distro out there is "hard" (better leave that to distro maintainers, except for your favorite distros of course) but there's a few distro-agnostic formats that are very easy to automate builds for: 0install, AppImage, Flatpak, guix, nix. The first two are statically linked (and PGP signed) and 0install is even compatible with Mac and Windows build (and any other platform, theoretically). Flatpaks are more Linux specific (some *BSD support in progress) and require a bit more setup to interface with other parts of the system escaping the sandbox (eg. for VAAPI), see the Portals mechanism. nix/guix are intended for reproducible builds: you need to package your dependencies first so it's definitely easier to get started if most of your dependency tree is already packaged there. All in all, supporting those 5 build systems should keep you busy for a few days at the start of your project but will be a huge win for portability and maintainability in the long run. If your project's architecture is not too complex and the dependencies are easy to package, some external contributors (me?) could help with that. Good luck on your project! [0] https://github.com/trizen/pipe-viewer https://github.com/trizen/pipe-viewer [1] As a user i'm happy f-droid.org default repo goes to great length to ensure quality of apps on there and that no antifeature are silently introduced by updates, but i'm also happy apps with specific needs for rapid upgrades like Newpipe can develop their own repo, and a simple QRCode can help bootstrap the repository entry + PGP key without having to mess around with repo settings manually

parmezan 5y ago

Alternative yt desktop app is https://freetubeapp.io/ https://freetubeapp.io/

stragies 5y ago
Or the native cross-plattform opensource Minitube from https://flavio.tordini.org/minitube https://flavio.tordini.org/minitube . Is already available on most systems through the package manager.

kragen 5y ago

Right now I'm using these kind of shitty shell scripts to download the videos, ls to list them, and mpv on the command line to play them. These use a file called "channels" which contains YouTube channel URLs and space-separated tags, like this: https://www.youtube.com/channel/UClaEdLrmti779-tyovta8zw grandpa amu hardware carpentry hacking https://www.youtube.com/channel/UCLt9kIslIa1ffiM8A04KORw wm levsha hardware hacking Here are the scripts, slightly cleaned up: snarf: #!/bin/sh echo "snarf $@" exec python3 ../youtube-dl -f '[height<769]' -i -r 1M -R 1 \ --sleep-interval "${wait-227}" --max-filesize "${max_filesize-242m}" \ --no-mtime --playlist-end ${n-5} --write-info-json --add-metadata \ --write-description --write-thumbnail --write-auto-sub \ --write-sub --sub-lang en,es "$@" snarf-tags: #!/bin/sh exec ./snarf $(./tag "$@" | shuf | sed 's,$,/videos,') search: #!/bin/sh exec ./snarf ytsearch10:"$(echo "$@" | sed 's, ,+,g')" resnarf: #!/bin/sh : ${1?Usage: $0 foo.mp4.part} # example: garbage\ stuff\ -zKLMCO0-How.mp4.part for x in "$@"; do x=$(echo "$x" | perl -ne 'm,(.{11})\.mp4,; print $1') ./snarf "https://youtu.be/$x" done tag: #!/usr/bin/env python3 import sys def match(args, line): return (not any('-' + word in args for word in line) and not any(word not in line for word in args if word[0] != '-')) def main(args, input, output): for line in input: words = line.split() if match(args, words): output.write(words[0] + "\n") if __name__ == '__main__': main(sys.argv[1:], open('channels'), sys.stdout) So my searchbar is "wait=3 ./search japanese hornets" or "./search electrochemical machining advances", and periodically I run "./snarf-tags" to download any new videos over the next few hours, which I can then see with "ls -lart ./*4". And if I want to know where some great search-result video came from so I can add it to the list of channels, why, that's "jq -r .uploader_url Romanes\ Eunt\ Domus\ EXPLAINED\ _\ Monty\ Python\'s\ Life\ of\ Brian\ •\ Fun\ with\ Latin-UfH6gjxTTgE.info.json", which sounds horrible but it's really more like ^Rjq^A M-f M-f M-f ^K Ro<TAB>. Suggested videos and thumbnail display, not to mention buttons to press for the above things, would be a welcome addition, but thumbnail display is difficult in the terminal. Also, it would be pretty great to have a way to not redownload a video after I deleted it, and for youtube-dl to not wait the 227 seconds before deciding not to download a video because it's a four-hour snoozefest recorded livestream.

CGamesPlay 5y ago
Thanks for this! I’m going to be rigging something like this soon, and I have a lot of feature crossover with what you’ve done here.
- kragen 5y ago
  Sure! I hope it's helpful!
scns 5y ago
Great. My first thought was: The inverse of (dual to?) the infamous Dropbox comment
- kragen 5y ago
  Haha! Yeah, I definitely don't mean to imply that the UX of these scripts couldn't be improved, just that these are some bits of functionality that I've found useful, and some very simple ways I've found to implement them that nevertheless worked pretty well. And, maybe as importantly, it may not be hard to have better UX than 25 lines of shell scripts, but it's even easier to have worse UX, so this is kind of the minimum bar for acceptability.
  - scns 5y ago
    Yeah, there was zero implication about UX on my part though. Instead of just dismissing it with a: "I can do that in 30 lines of Python", you just delivered a solution that works for you and can be built upon by others. Good job, praiseworthy IMHO.
    - kragen 5y ago
      I think UX was precisely the way Dropbox won.

VortexDream 5y ago

That seems interesting. I'd give that a try. I'm not satisfied with any clients I've tried so far.

Nextgrid 5y ago

There's already some competition in this space: https://flavio.tordini.org/minitube https://flavio.tordini.org/minitube

southerntofu 5y ago

I think a lot of people are looking for that. This is especially true for folks with lower-end hardware where hardware decoding may be supported by the system but not (well) by the browser, or at least the rest of the browser runtime would use way too much resources. NewPipe on Android is somewhat popular because it's much lighter than other Youtube clients (browser included) and enables features which Youtube official clients prevent on purpose (audio-only, download). We don't have an equivalent to that on the desktop. gtk-pipe-viewer [0] is close to that, but is not widely available yet. A problem you need to tackle when distributing a 3rd party client for a centralized network is you have to deal with constant micro-changes in the public-facing API, which the silo does on purpose to break 3rd party clients. youtube-dl from distro repos is almost unusable all the time because of that except on rolling-release (most people use pip version instead), and Newpipe had to make their own F-Droid repository because f-droid.org vetting/build process is too slow for that particular usecase. [1] EDIT: If you're looking for solutions to distribute your client, packaging for every distro out there is "hard" (better leave that to distro maintainers, except for your favorite distros of course) but there's a few distro-agnostic formats that are very easy to automate builds for: 0install, AppImage, Flatpak, guix, nix. The first two are statically linked (and PGP signed) and 0install is even compatible with Mac and Windows build (and any other platform, theoretically). Flatpaks are more Linux specific (some *BSD support in progress) and require a bit more setup to interface with other parts of the system escaping the sandbox (eg. for VAAPI), see the Portals mechanism. nix/guix are intended for reproducible builds: you need to package your dependencies first so it's definitely easier to get started if most of your dependency tree is already packaged there. All in all, supporting those 5 build systems should keep you busy for a few days at the start of your project but will be a huge win for portability and maintainability in the long run. If your project's architecture is not too complex and the dependencies are easy to package, some external contributors (me?) could help with that. Good luck on your project! [0] https://github.com/trizen/pipe-viewer https://github.com/trizen/pipe-viewer [1] As a user i'm happy f-droid.org default repo goes to great length to ensure quality of apps on there and that no antifeature are silently introduced by updates, but i'm also happy apps with specific needs for rapid upgrades like Newpipe can develop their own repo, and a simple QRCode can help bootstrap the repository entry + PGP key without having to mess around with repo settings manually