mpsyt support about catt

[theychx]

I dont't see this happening. Catt is not a conventional media player, it just takes the url it gets from youtube-dl and passes it on to a chromecast. And besides, why not just bake chromecast support directly into mps-youtube? As you can see in catt's source code, thats pretty easy to do.

[theychx]

I see now that mps-youtube relies on external programs for playback, so disregard that last comment. I'm still not in favour of putting functionality into catt, that is going to be obscure to 99.9% of users.

[atomi]

I just really love the idea of being able to cast a playlist of youtube videos from the command line.
I was thinking something simple. catt cast --foreground [url] with SIGINT support.

[skorokithakis]

That would be a nice piece of functionality indeed. I don't know how this could work, as I'm not sure how mps works. Does the solution in mps-youtube/yewtube#607 work reliably?

[atomi]

Yeah it actually does work as is except for a small bug:

In mpsyt, catt works like this:

set player catt
set playerargs cast

But as catt goes into the background, mpsyt thinks the video has terminated so it goes on to the next video. If catt is able to stay in the foreground (with an optional arg perhaps) mpsyt will properly consider the video still playing.

[skorokithakis]

Ah, I see. The problem with that is that catt can't (easily) know when the video has stopped playing, as it's not playing the video itself. All it could do is ask the TV whether the video has stopped playing every few seconds, but that would have different problems (if the user performed a seek at some point, catt might get confused, or delay playing the next song too much, or play it too early)...

[atomi]

Hmmm I think it wont matter to mpsyt. As long as catt is running the video is considered still playing. When catt terminates mpsyt will know to execute another catt command.

[atomi]

Oh nevermind. I see what you're saying.

[atomi]

We might be able to use a listener described here. home-assistant-libs/pychromecast#84 (comment)

Or if it's outside the scope of catt. I can open a new project just for this.

[skorokithakis]

Hmm, this might work. I'm not against having this in catt, although it will have to be a bit unsupported/hidden (perhaps just be a --foreground argument). Would you like to do some testing and see if it's doable?

[atomi]

Yeah.

[theychx]

@atomi
I did this PoC, to use in place of catt. This has the behaviour you requested. It also responds to SIGINT, but that does not seem to work with mpsyt.

[atomi]

@theychx How was your script called from mpsyt?
I opened up an issue at mps-youtube/yewtube#607
perhaps @ids1024 can comment.

[theychx]

I just put it in my path, and then did something like set player cc-play from within mpsyt. Please note that playback itself works fine with mpsyt.

[theychx]

@skorokithakis @atomi
So I incoporated some more of that catt goodness into my script.
I've grown quite fond of mpsyt, so I might expand the script, so that the user also has basic playback controls. But since that strays away quite a bit from what catt is doing, I'm wondering if it isn't better if this becomes sort of a "sister"-project to catt, instead of incorporating this functionality into catt. Let me know what you think.

[atomi]

@theychx haha yeah that's awesome, but none of these are my projects. If I wasn't so bogged down yesterday/today I might have done a simple script like you. Thanks for sharing it.

[skorokithakis]

What's the resolution on this ticket?

[skorokithakis]

I have gotten to quite like mpsyt as well, but I agree with you, @theychx. Adding controls to catt would be a bit too much, and possibly break easily if other people connected to the network seek/stop/pause playback on their devices/phones.

If it were rather bulletproof, I wouldn't be against doing this, but both error-prone and somewhat-out-of-scope is a bit much, I think.

[theychx]

@skorokithakis, sorry about closing this without consulting you, I was tired and this annoyed me for some reason.

I actually fiddled with a prototype that was remote-controllable through the mpv(media player) json-ipc protocol, and got it mostly working. However, adding support for a new "player" in mpsyt proved to be really hard. There is actually an ongoing effort to make the relevant code more object-oriented (which would make my project a lot easier), but that seems to (also) have gone stale.

I agree that this functionallity does not belong in catt, and that mpsytsupport is not really useful without the control part.

[skorokithakis]

@theychx No problem, I agree with the closure even though I'd like it if we had something like this implemented (if not for the caveats above).

Let's revisit if mpsyt becomes more modular, maybe we can have a special mode in a separate, bundled utility or something like that.