Add support for YouTubeTV

[rbclark]

Specifically, there are only 2 differences between you Youtube API and the YoutubeTV api. The Youtube TV API requires authentication while it is optional on Youtube, and the endpoint is different. This adds support for authentication and adds the proper bind_data for YoutubeTV.

[ur1katz]

Hi Thanks for the PR this looks like a great addition to CastTube. I left some comments on the code, check them out.
I also have a few questions:

1. How do you get the cookies?
2. What happens if CURRENT_TIME is not -1 (CURRENT_TIME will change when I merge my branch)
3. Could you please add the changes to the README?
4. I have no way of testing this as there is not YouTube TV service where I live. What testing have you done?

I'm planning to merge some long awaited changes this weekend so i'll merge it probably Saturday with some other changes if everything will be ready :D

[ur1katz]

Does this affect YouTube TV? I have a branch that lets users change the start time of the video so CURRENT_TIME is going to be a variable

[rbclark]

I did some testing here and it seems to me that it didn't affect actual YouTube and causes YouTube TV to go to the "Live" section of the video instead of the current recording. As long as we still have the ability to pass CURRENT_TIME as -1 into YouTube TV then this being a variable won't be a problem, as long as we make it default to -1 for YouTube TV.

[rbclark]

@ur1katz Thank you for the code review! For your other questions:

1. I got the cookies by logging into YouTube TV, opening the element inspector and browsing to Application > Storage > Cookies > https://tv.youtube.com and filling in the matching cookie values that I just added to the README :). It should actually be possible to use this to authenticate to regular Youtube as well, meaning this might also be useful for Youtube red subscribers to avoid ads playing on their chromecast.
2. If current_time is not -1 it will try to start at a different point in the video. I believe 0 will start at the beginning of the currently recorded show. Overall, being able to pass in current_time could be useful for some people however I am mostly trying to use this to simplify the interface for some older people not interested in the additional features that streaming TV provide so my biggest goal was simply getting to the end of the current video.
3. Yep done!
4. I have tested closing the YouTube TV app multiple times on my SHIELD TV and re-launching it using the changes here + Add support for YoutubeTV home-assistant-libs/pychromecast#314. I have also used the play_video method to flip through channels. Now that I have this working I've also gone ahead and ordered a chromecast 3rd gen to perform some additional testing with to verify that it works there as well. I have not messed with anything involving adding to queue since YouTube TV doesn't really have a concept of queues, only what is currently playing.

[rbclark]

So I was doing some more testing and it seems that passing in -1 has a different effect on youtube than I originally realized. It seems that -1 causes youtube to resume play from the watchers current video location, not from the beginning.

[ur1katz]

Hey, do you think you can extract the cookies in a script? It would make this simpler for people.

I really don't know the tv interface so could you please tell me more about the API?
How do you change channels? what happens when you use the queue functions in a YouTubeTV session? Could you extract the channel names as part of the API?

As for the time you can look at #8 . I think the best way would be to override the play_video with a default of -1 in the YouTubeTV controller.

[rbclark]

Okay I'll go ahead and let you merge #8 first, I can pretty easily work with that. So I've drastically changed how I'm doing authentication, I am now properly requesting OAuth tokens and using requests-oauthlib. I have tweaked my changes to not take any cookies and just receive a request handler, which in my case is an authenticated requests-oauthlib session.

I have also tested and basically the only functionality that works here is play_video. I can raise NotImplementedError or something on all the other endpoints, at least for my use case I was able to use pychromecast to stop playing still by calling cast.media_controller.stop().

I really don't know the tv interface so could you please tell me more about the API?
How do you change channels? what happens when you use the queue functions in a YouTubeTV session? Could you extract the channel names as part of the API?

Apologies I missed this question at first. So this part is a bit complicated, I tried to go ahead and pull the channel names are part of the API however they seem to be broadcast using some youtubei internal API that end users are not allowed to generate OAuth tokens for. This means I have had to manually go down the list of channels (all of which are just basically Youtube URLs) and just create an array of them. To change channels you simply call play_video with the new video URL and that is about all you can do. When you use the queue functions nothing happens, clear queue doesn't do anything either.

Also I just added a full example to home-assistant-libs/pychromecast#314

[ur1katz]

Sorry to keeping you waiting iv'e been really busy lately. Auth method looks good but I'm a little worried about people having to add a cloud project for this. Can you extract the cookies from request_handler? if so what do you think about using cookies and providing this method as an optional way to automate the cookies extraction(in casttube-scripts)? I'm not sure if it's better so asking for your input :)

As for the other session requests it's cleaner to raise not implemented with a message that they are not supported in YouTubeTV.

Last thing is #8 there's a bug that i'm currently not really sure how to solve. I don't want that to block this PR so just change the start_time for the YouTubeTV controller in this PR in i'll adjust #8 afterwards. I think the cleanest way to do this is to add **kwargs to _initialize_queue and
request_data = dict(**dict(request_data, **kwargs))
That way you can override start_time

[mchro]

Anything I can do to help get this merged? I've been using this patch together with this example script, and using a client id/secret created using the same way as gphotos-sync does it.
This allows retrieving a refresh token without any expiry, and a robust integration.