YouTubeController doesn't display video

[home-assistant-libs]

YouTubeController doesn't display video

[adrianlshaw]

curl http://192.168.0.2:8008/apps/YouTube -X POST -d 'v=3ZdSDUyxFmc'

EDIT:
Ok, I realized that this is using the old DIAL protocol. So this doesn't really apply here.

Does this method still work for anyone? Today I've noticed it has stopped working and returns 404.

curl http://Chromecast.local:8008/apps/YouTube -X POST -d 'v=3ZdSDUyxFmc' -v
Note: Unnecessary use of -X or --request, POST is already inferred.
*   Trying 192.168.1.7...
* TCP_NODELAY set
* Connected to Chromecast.local (192.168.1.7) port 8008 (#0)
> POST /apps/YouTube HTTP/1.1
> Host: Chromecast.local:8008
> User-Agent: curl/7.52.1
> Accept: */*
> Content-Length: 13
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 13 out of 13 bytes
< HTTP/1.1 404 Not Found
< Content-Length:0

[joelhaasnoot]

Same issue here

[andmart]

Same issue here[2]

[franciscod]

same!

[brusc]

Same issue as well. Any ideas on a fix?

[balloob]

I think that YouTube has changed the way they communicate with the Chromecast. I did dig into this once and it seems that YouTube is moving to a system where they pass a token that you need to use to talk to a TV queue API.

[brusc]

Sounds good. I appreciate the info! So is it fair to say that the YouTube controller function is out of commission for the foreseeable future? No worries if so. Just wondering if it's time to move onto other media player options.

[balloob]

Yes, should probably add a warning to the controller.

[brusc]

Sounds good! 👍

[clusterfudge]

Sorry, just to clarify, this is dead in the water? A warning on the controller of "Hey, this doesn't work at all" seems kinda sub-awesome. Thanks!

[am0s]

It's dead unless someone can figure out what needs to be sent to the youtube controller.
I think the code needs to setup a session (lounge) before passing along the video to play (or rather enqueue), but the exact names of variables to pass along etc. is unknown at the moment.

I might be able to have a look at it after the multiroom features are done, but can't really promise anything.

[clusterfudge]

Got it. I may try to capture the traffic as it goes past and see if I can pitch in, but that does mean closing my other 40 browser tabs, and I finally just got them just right :)

[clusterfudge]

I've been over my dump several times, and I'm unable to find anything related to a session/lounge in the protocol. With the exception of some messages sending sessionId when the chromecast plugin does not, I haven't found any differences in the protocol. I'm concerned this may just be a matter of timing, which would be lame.

[clusterfudge]

Sorry for the long delay; I did put another few hours into this and the session dumps from chrome exactly mirror the logs from pychromecast; I have no understanding of how this protocol has changed or how to get flingVideo working again. I've now heard reports that it's intermittent, and I'm hearing from other people that it works fine. I'm very clearly still broken, so who knows what's actually going on.

[agumonkey]

castnow used to have a similar feature but now suggest to pipe the mp4 stream found by youtube-dl toward the chromecast device (note that this seems buggy too). https://github.com/xat/castnow Just in case it gives people ideas.

[ur1katz]

I have a working(mostly working) POC - https://github.com/ur1katz/pychromecast
The session parameters are very not clear and youtube changes then frequently..
i will not have much time to work on it so feel free to help :)

[enriquegh]

@ur1katz hey if you need any help I would love to. I've been playing with your fork and so far so good!

[theychx]

@ur1katz
Have you considered doing a PR? Even in it's current state, your controller is much superior to the completely broken one currently in pychromecast.

[ivan-krukov]

Any news on this? How about using the HTTP interface exposed on 8008? This still works for chromecast v2:

curl http://192.168.0.2:8008/apps/YouTube -X POST -d 'v=3ZdSDUyxFmc'

EDIT:
Ok, I realized that this is using the old DIAL protocol. So this doesn't really apply here.