LGPL only stipulates that users have the freedom to link against their own version of the LGPL library you're using. You don't have to open source anything if you don't want to.
> QT needs a commercial license which is pretty expensive
Are you sure about that? Most of Qt for desktop is licensed under LGPL or similarly permissive licenses that don't require you to open source your project or pay licensing fees.
Some specialized components in Qt are GPL/commercial, but those are for things like automotive use.
I use Qt/QML for desktop applications and never had to buy a license.
Check this out[1] and sort by license to see if you're actually using modules that require a commercial license. Chances are you aren't.
Half-seconded. I wouldn't claim to have fully understood how the Qt licensing model works (and I think it can be different if you do servers, or deliver binaries), but it's definitely worth checking out your exact use case, because I find developing in Qt really good.
A while ago, I found the need to stream directly from yt-dlp instead of downloading full videos[1]. You can have yt-dlp write to stdout and pipe that stream into your player of choice.
> (not certain if grep is reading the pipe as it is output or waits for execution to complete first)
Commands to the left of the pipe block upon writing to the pipe, and commands to the right of the pipe block upon reading. As something is written to the pipe, it gets read by the next process in the pipeline.
Data flows through Unix pipelines as it is written, and data flow is not dependent on completed execution.
Theoretically it should work if you're able to get D-Bus working on macOS. D-Bus is usually a Linux thing, but it's been ported to other platforms. macOS isn't included in the title because most macOS users don't have D-Bus installed.
I included instructions here[1] with URLs to the macOS versions of D-Bus and PyGObject. I'd be interested in whether you're able get it working.
While you have chromecast_mpris running, you can use an MPRIS client to issue the OpenUri method[1]. Here's an example:
$ export URL="http://ccmixter.org/content/gmz/gmz_-_Parametaphoriquement.mp3"
$ playerctl -p My_Chromecast open "$URL"
This will cast a song to the Chromecast named "My_Chromecast". I forgot that OpenUri was implemented in the project because I typically cast from other devices and programs, but I'll include it in the README.
> Thoughts on what this provides that's better?
People tend to use catt or castnow to cast from the command-line. I wrote about using VLC to cast to the Chromecast[2], but I wouldn't recommend it unless you're watching something that you need VLC for.
I do something similar with chromecast_mpris. I have my media keys mapped to Plasma's Media Controller, which uses MPRIS in the background. Works well for me, and you don't have to wait for catt to launch and find your Chromecast each time.
Thanks for your work on pychromecast, I've looked and it's the best supported library for working with Chromecasts out there. It was also pleasant to integrate into this project.
Does the pychromecast project use semantic versioning? I've had to pin the library to a specific version after running into an API breaking change on what would be a minor or patch update to 7.X if the project used SemVer.
