Antennapod: Chrome Cast Support

[tywunon]

Are there any plans for Chrome Cast Support?

[keithzg]

Does the Chromecast app truly not just expose as a recipient for a share intent? if it doesn't, that's strange that Google themselves is ignoring one of the most useful aspects of Android. If it does, then "share website link" (which sends the URL of the content to any program that has registered an intent for receiving URLs, AFAIK) should work, no?

[jheiselman]

@keithzg The Chromecast app is not responsible for sending data to the Chromecast dongle. It just assists one in setting up the device.

The Chromecast dongle listens on your Wi-Fi network and apps that wish to implement support, but add it to their app. This is why you can start playing content with one device and then that device can leave the network and the CC continues to work (unless that app sets streaming local content).

[treyhunner]

:+1: for Chromecast support

[hintss]

This isn't done yet?

[fuddl]

related to #81

[mfietz]

At the moment, there are only two active (spare time) developers. I can only speak for myself, but I am not planning to implement ChromeCast support anytime soon, not unlikely never.

We have a lot of open issues at the moment and I think a lot of them a far more important than this. As long as there are not more devs, such "nice to have" features will take a backseat.

[mxk1235]

+1 Chromecast Audio support is sorely needed.

[keunes]

Wouldn't say it's sorely needed, but boy, I would love to see Chromecast support! To be honest I'd give this higher priority than #932, #1215, #1170 and #1085 combined together. I also think it would be good to implement as it would make AP one of the few (if not the only) ad-free podcatchers with Chromecast support (others apps have it already, as well as android wear support).
Can't we bribe you to implement it with an actual Chromecast, @mfietz ? ;)

[mfietz]

Well, as I don't own a ChromeCast stick myself, I couldn't even test the code I write. So no, I don't think I'll implement anything in this direction soon.

[keunes]

@mfietz that's why I proposed to bribe you guys with an actual device ;)
Would you be willing if you got it; or then still not?

[mfietz]

I have to stick that thing into a tv, don't I? Who's buying me one of those? xD

Besides, Tom told me he is thinking about picking one up, you might want to try persuading him _(I'm so dead...)_

[keunes]

A regular Chromecast goes into your TV, in case of a Chromecast Audio [EN, DE] you plug the device into a speaker set or receiver using 3.5 mm mini-jack, optical or RCA connections.

I'd be willing to provide some funding and I'd be happy to get a few other users so crazy as to donate as well, plus there's some € 120 in the bitcoin wallet ;)
(and they're not so expensive anyways)

Of course, @TomHennen, the offer goes for you too!

[jalcine]

One might not _need_ to buy anything. You could emulate the use of a Chromecast using this project https://github.com/dz0ny/leapcast. I've tried it with Google Play Music and it worked fine.

[mfietz]

Wouldn't really make sense to use old library versions just to get an old protocol version of Chromecast to work, would it? These might even get in conflict with the other libraries we use

[keunes]

Hi all,

Would there be interest in attracting an external developer by setting a bounty on the issue via Bountysource? I just received my Chromecast Audio and I'm now reaallly eager to have AP support this, so I' m wondering if others are willing as well to make a donation :)

[Itamar-]

+1 for Chromecast Audio support

[genepool99]

Another +1. With Chromecast Audio on my stereo and a Chromecast on all my TV's I need a pod catcher that can push to the devices. I would pay part of a bounty or send a developer a free Chromecast.

[sixgeek]

I'm also willing to support the team to hurry up the CCA (chromecast audio) development. Please make it happen soon.

[domingos86]

I've actually been working on this lately, but it's far from done. It was working more or less okay at some point but I didn't like the implementation and decided to start again from scratch (so right now it's not even sending anything to the chromecast yet), but with the pieces left from the previous implementation it should progress quickly this time.

You can follow it on https://github.com/domingos86/AntennaPod/tree/chromecast-issue-340
Any suggestions are more than welcome.

Once it's ready to be tested I'll let you guys know.

[yzerman19]

Great news!
Getting video podcasts to my TV is my # 1 desired feature. (Either via Chromecast, or a native AP app on one of the devices connected to my TV, like FireTV stick)

[TomHennen]

That's great @domingos86.

We (I) may also incorporate other media players at some point (UPnP MediaRenderers for example).

If you're doing this for ChromeCast support I may just be able to piggy back on your work, assuming it allows for additional player types besides just local and ChromeCast.

Thanks!

[domingos86]

@TomHennen, right now I only have chromecast in mind, but it would be safe to assume that the logic won't change too much. As I get it to a stable working state I may then start looking for ways to generalize. Of course, I'm open to any suggestion on ways to implement, etc, and if you'd like me to take a look at some interface/API just to keep some perspective, just let me know.

I initially aimed to implement the chromecast as an instance of IPlayer and simply have PlaybackServiceMediaPlayer handle the media player switches (like it already does between audio and video) and got it running, but the implementation felt a little messy and the lifecycle of regular media players are somewhat different from how it works on a remote one. Besides, PlaybackServiceMediaPlayer is a little too much in control of everything, and a remote media player doesn't go well with it because the playback can also be controlled by other devices (and don't get me started on cross-device media recognition, which at some point I'll have to make work).

So now I'm turning PlaybackServiceMediaPlayer into an abstract class and took almost all of its implementation to a subclass for local playback and, hopefully, we can create a similar subclass that could encompass any type of remote playback (although now I'm using it to communicate directly with the chromecast). In this implementation, the PlaybackService class is the one responsible for switching between local and remote playback.

[keunes]

@domingos86 That's great to hear! Two questions:

• when you say 'chromecast' does that include chromecast audio (dunno if that'd require different implementation) 0:)
• about local/remote playback: maybe I'm talking nonsense, but I guess it would be good to
  
  
  
  • first try to play from remote (based on the file URL); if one's phone crashes (that happens rather frequently in my case, unfortunately) or loses connection with Chromecast for some reason, Chromecast will be able to continue playback
  
  
  • if that's not possible, revert back to local (Android) media server [this might occur if I have downloaded an episode which is not available anymore on the server, which happens for example with BBC's weekly comedy (the files are removed from their server after two weeks)]
  
  

[domingos86]

@keunes, that includes chromecast audio since, as far as I know, it uses the same implementation. However, I won't be able to test it myself because I only have the video stick, but I believe the communication protocols should be the same as the standard chromecast styled receivers, so testing it should be equivalent to just chromecasting without looking at the tv. Ultimately, I'll rely on the community of users interested in the feature to test it later on such devices.

Right now I'm only aiming for playback based on URL. I know there are solutions out there that allow to play local media files, at some point it would be interesting to implement that here, and once it happens your approach to try URL and fall back on local media files makes the most sense (we should perhaps then allow users to change that behavior in the settings - override to playback from local files by default).

All of this is probably going to take a while because I never implemented chromecast before (and my major is not CS) and this is only a spare time hobby. Having said this, I expect to get a buggy but working solution within a week (plus some more time to fix bugs, deal with dedicated UI, deal with connection and reconnection issues, queuing, etc).

[keunes]

However, I won't be able to test it myself because I only have the video stick, but I believe the communication protocols should be the same as the standard chromecast styled receivers, so testing it should be equivalent to just chromecasting without looking at the tv. Ultimately, I'll rely on the community of users interested in the feature to test it later on such devices.

I'm more than happy to test & log on my device if you can provide a build :)
A week for a 'working solution' seems pretty fast to me!

[domingos86]

@keunes, that's because I already had a somewhat working solution, but buggy in unexpected ways, so I decided to start from scratch, but a lot can be reused.

[TomHennen]

@domingos86, that sounds fine.

In the end I'd like to be able to share the way casting to some other device is triggered (be it Chromecast or Sonos or some other DNLA player) as well as how we list those devices (ideally we can list Chromecast devices next to DNLA, etc...).

I doubt the playback logic will be shareable, but that's fine.

[domingos86]

@TomHennen, the device selection, at least, is handled by MediaRouter:
http://developer.android.com/guide/topics/media/mediarouter.html

It apparently supports devices other than chromecasts, so you should be shareable.

At least in that respect, I don't think my implementation is going to change, so you can peek if you want. Basically what I did was to extend MainActivity and MediaplayerActivity from a common Activity superclass that all it does is to show the MediaRouter button, while associating it with the chromecast manager.

[domingos86]

By the way, I just tested my chromecast implementation and it's working as expected ( = no major unexpected bug), which is a nice milestone. There are still many features to take care of, especially concerning the UI, that wasn't sufficiently adapted to this new reality, but can perform basic tasks (and break the app with others, especially if you try to open the video player while casting video). You can still try it, but don't expect too much at the moment.

Once I feel like it's ready for testing, I'll let you all know.

[mfietz]

Might be useful: https://github.com/MacDegger/BABBQastPresentation

[mfietz]

@domingos86 Made any progress? Something we can help you with?

[domingos86]

@mfietz Unfortunately I haven't had much time recently to work on this. I'm actually very busy these days with my thesis (and job interviews), but I'll try to find some time here and there to at least incorporate with the UI. In a week or so there should be more progress.

[mfietz]

@domingos86 Sorry for being pushy. If I understand him correctly, @TomHennen would like chromecast in the next release (1.6). I, on the other hand, would like to get 1.6 out to fix Flattr and some other issues. So, how is it looking? ;)

[domingos86]

@mfietz, frankly, I was not aware that @TomHennen wanted it with 1.6. I thought it would go with more like a 1.7 release or something in between, but it's something that was never brought up.

To get everyone's expectations right, let me lay out what the current situation is what is likely to be in the near future:

• Right now, it casts, switches back and forth between local and remote playback.
• Logic for handling temporary disconnects isn't fully done, but should be quick to implement.
• This weekend, possibly tomorrow, I'll work on the UI part. I'll essentially reuse the current audioplayeractivity, with some minor tweaks. You can expect it to be done by tomorrow evening/sunday morning.

After that point, it's possible to safely test, but there will be some declared limitations that with more time should be taken care of:

• Proper feedback to the user when an instruction fails to reach the chromecast.
• Unexpected behavior when sharing the same chromecast with 2 different AP instances simultaneously.
• No (remote) queuing support: chromecast supports queuing, so that by using preloading you can have a seamless transition between episodes, as opposed to waiting for your phone to tell it what to play next once the current episode ends. This one might be a little tricky to implement, especially when considering the previous point.
• No support for local content playback (it always streams).
• No support for authentication (if your content requires login & password).
• If an episode ends playing on the chromecast and your phone isn't connected at the moment, AP won't mark it as played, possibly even if it reconnects after a while.

Based on my report, you can decide whether having it on 1.6 is the right thing to do. If so, I'll be happy to speed things up to the best of my availability.
An alternative would be to release it as an experimental feature, so it'd have to be activated in the settings. My code actually already accounts for that possibility, so it's something that on my part could totally be done.

Also, the last 2 limitations I listed should only be properly solved with a custom receiver (the HTML5 that runs on chromecast on behalf of our app). For that, AP would have to register a custom receiver with Google (and pay $5 for it). We can probably live without it for the moment, but if interested you can look at https://developers.google.com/cast/docs/receiver_apps and https://developers.google.com/cast/docs/registration

[TomHennen]

That actually sounds fine. I think it would actually be helpful to include ChromeCast support as an experimental feature.

[domingos86]

So now a basic UI is implemented and it's possible to test it.

In order to avoid compatibility issues with future versions, given the early stage of this feature, I'm not allowing more than one device to use the same chromecast simultaneously. Once we start handling queues on the chromecast, we'll then be able to lift this restriction (think of the case when an episode finishes on the chromecast and two devices want the chromecast to play whichever episode is next on their queues). Because of this, sometimes joining an existing remote session might not be as seamless, or we end up killing a session to start a new one unnecessarily. All these issues will obviously be addressed with time.

There are also some obvious UI deficiencies, not too important, that I don't have the time right now to solve, but within a week or two they should be handled. These include the color of the cast button on the light theme, the notification that should show a button to stop the casting, the pagerview on the player activity that seems to not always update its info, no easy way to start episodes from the queue that weren't downloaded - play button is replaced by download button, etc. Another problem with the UI, but on the chromecast side, is that, at least in my case, when playing video it shows a useless horizontal scroll bar on the screen. This is of course out of my control, certainly a problem with the way google implemented the standard media receiver, and we can only hope to fix that once we start using a custom receiver.

@TomHennen, what is the best way to make it available for testing?
I can either do nothing and people access it from my repo, or we can do a PR to develop or to a new branch (or any better idea you could have in mind).

[TomHennen]

Awesome.

I think a PR would be best. If all the normal AntennaPod features work we
can push it to the Alpha channel and people can test there.

On Sun, Apr 17, 2016, 5:19 PM domingos86 [email protected] wrote:

So now a basic UI is implemented and it's possible to test it.

In order to avoid compatibility issues with future versions, given the
early stage of this feature, I'm not allowing more than one device to use
the same chromecast simultaneously. Once we start handling queues on the
chromecast, we'll then be able to lift this restriction (think of the case
when an episode finishes on the chromecast and two devices want the
chromecast to play whichever episode is next on their queues). Because of
this, sometimes joining an existing remote session might not be as
seamless, or we end up killing a session to start a new one unnecessarily.
All these issues will obviously be addressed with time.

There are also some obvious UI deficiencies, not too important, that I
don't have the time right now to solve, but within a week or two they
should be handled. These include the color of the cast button on the light
theme, the notification that should show a button to stop the casting, the
pagerview on the player activity that seems to not always update its info,
no easy way to start episodes from the queue that weren't downloaded - play
button is replaced by download button, etc. Another problem with the UI,
but on the chromecast side, is that, at least in my case, when playing
video it shows a useless horizontal scroll bar on the screen. This is of
course out of my control, certainly a problem with the way google
implemented the standard media receiver, and we can only hope to fix that
once we start using a custom receiver.

@TomHennen https://github.com/TomHennen, what is the best way to make
it available for testing?
I can either do nothing and people access it from my repo, or we can do a
PR to develop or to a new branch (or any better idea you could have in
mind).

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/AntennaPod/AntennaPod/issues/340#issuecomment-211117766

[TomHennen]

For anyone that wants to test this I've put a debug build here: https://www.dropbox.com/s/ox91c6qx9tjcwbx/AntennaPod_pr1879.apk?dl=0

NOTE: we're not aiming to get every feature implemented right now. We'd like basic functionality. I don't have a ChromeCast, so hopefully people with ChromeCasts can step up and make sure the basics work.

[yzerman19]

FYI- I plan on testing with my Chromecast, but it may take me a day or two.

[f1ori]

Awesome job, thanks! Just noticed this thread by chance and tested the build. Works really well for me. The only thing I notice, is that the chromecast icon is on every view of the app (even add podcast) and I only expect it to be on the view with the play controls.

[domingos86]

@f1ori Thanks for the feedback. We certainly need to fine tune where we want the icon to show and where not.

[TomHennen]

@domingos86 what if we only had the cast button on the main audio player and nowhere else?

Would that be a big usability issue? It should only be one click away (though I guess that would only be if you're _currently_ playing it in AP, which may not be true all the time).

Perhaps the player and the ItemFragment? That would let you cast the current episode and it would let you go to an episode in your various lists and cast it.

[domingos86]

@TomHennen Given the central role that the queue plays, I don't think we should ever have to leave it in order to enable or disable a cast session.

What we could do would be to leave it to each different type of main fragment to decide whether:

1. cast button shown as action (on the action bar)
2. shown on the options menu
3. not available at all

Right now it's easy to implement a solution that switches between 1 and 3, but for 2 it seems to be a harder job for the moment.
The default action provider for the media router button didn't really work with option 2, but I was able to tweak it and now it also works from the overflow menu.

An alternative would be, despite generally not recommended, to have the cast button on the navigation drawer on the left right of settings (in MainActivity, and in the action bar inMediaplayerActivity).

[TomHennen]

1 and 3 might be fine. Certainly for now.

On Wed, Apr 20, 2016, 10:35 PM domingos86 [email protected] wrote:

@TomHennen https://github.com/TomHennen Given the central role that the
queue plays, I don't think we should ever have to leave it in order to
enable or disable a cast session.

What we could do would be to leave it to each different type of main
fragment to decide whether:

1. cast button shown as action (on the action bar)
2. shown on the options menu
3. not available at all

Right now it's easy to implement a solution that switches between 1 and 3,
but for 2 it seems to be a harder job for the moment.

An alternative would be, despite generally not recommended, to have the
cast button on the navigation bar on the left of settings (in MainActivity,
and in the action bar inMediaplayerActivity).

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/AntennaPod/AntennaPod/issues/340#issuecomment-212702177

[keunes]

Another option (for later I guess): do it like Spotify and put the button in the miniplayer (and the app bar in the player view). Still thinking of a way to make it look nice, though.

[TomHennen]

@keunes that's sort of what I was thinking originally. It would certainly reduce clutter, but would require that someone starts playing the episode locally before casting (unless I'm not understanding you properly). Perhaps that's not so bad though? I don't really have a good idea of how this works elsewhere.

If we have it in multiple views perhaps a good way to determine which views would be putting it on any view that has a play button in it somewhere. Queue, episodes, episode details, player. Then it wouldn't show up in add podcast, etc...

[yzerman19]

I only had about a half hour to try this out last night, but here are my initial thoughts.
As expected, it played my video and audio podcasts to my TV via my Chromecast. Two issues I noticed:
1) While playing a video podcast, I disconnected my phone from my home wifi, just to see what would happen. The podcast kept playing, but AP still had the "cast" button at the top of the player. It didn't seem to know that I was no longer connected to the network. I would have expected the "cast" button to disappear if I leave the wifi network. I haven't really tried this with other chromecast-enabled apps to see their reaction to this type of thing. Maybe this is out of your control, or maybe this is expected behavior...

2) Two or three times, after choosing to cast to my CC, the app would crash ("AP has stopped working"...). The podcast still started playing on my TV, however. I know you are probably going to ask for a log, but I don't have one. I was busy poking around and didn't think of it. Was there a button to send debug info? I didn't pay attention at the time, sorry... I will give it a try again soon.

Overall, great work! This will be such a great feature for me.

[TomHennen]

Settings - > Crash Report.

Alternatively, it's a debug build. If you can reproduce you could grab the
logs with adb. I think @mfietz may have had some version that makes
collecting the logs easier.

On Thu, Apr 21, 2016, 9:02 AM yzerman19 [email protected] wrote:

I only had about a half hour to try this out last night, but here are my
initial thoughts.
As expected, it played my video and audio podcasts to my TV via my
Chromecast. Two issues I noticed:
1) While playing a video podcast, I disconnected my phone from my home
wifi, just to see what would happen. The podcast kept playing, but AP still
had the "cast" button at the top of the player. It didn't seem to know that
I was no longer connected to the network. I would have expected the "cast"
button to disappear if I leave the wifi network. I haven't really tried
this with other chromecast-enabled apps to see their reaction to this type
of thing. Maybe this is out of your control, or maybe this is expected
behavior...

2) Two or three times, after choosing to cast to my CC, the app would
crash ("AP has stopped working"...). The podcast still started playing on
my TV, however. I know you are probably going to ask for a log, but I don't
have one. I was busy poking around and didn't think of it. Was there a
button to send debug info? I didn't pay attention at the time, sorry... I
will give it a try again soon.

Overall, great work! This will be such a great feature for me.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/AntennaPod/AntennaPod/issues/340#issuecomment-212907845

[yzerman19]

Here is the log from settings > crash report.

crash-report.log.txt

[domingos86]

@TomHennen @keunes Right now, as of the latest commit, the cast button isn't showing all the time anymore.
Current behavior is:

• Queue and Episodes (new, all, favorites) shows the button only if there's room (so on a phone it's most likely not showing while on a tablet it might show),
• Downloads, Playback History, Add Podcast and Subscriptions does not show the button (not even on an overflow menu),
• Feed view has bast button, but always on the overflow menu,
• Media player view has button, always on the action bar,
• Any other place defaults to not having the button at all.

[domingos86]

Of course, these choices are what made the most sense to me, but feel free to disagree.

[domingos86]

Thanks @yzerman19 for your report.

About the first issue you mentioned, my perspective is that it's assumed that it's a temporary disconnection issue, so the user should still have access to the controls of the casting session, even if only to ultimately tell AP that it should disconnect (in this case, let go of trying to reconnect).

As for the crash, I was able to reproduce it on my phone, so I know what the issue is. It essentially happens when you're watching a video on your device and choose to start casting. Am I right?
It's a shame that I hadn't tested that particular sequence of events before (I had only started casting from the queue or from the audio player). This shouldn't be too difficult to solve anyways, so a fix should be coming tomorrow.

[keunes]

that's sort of what I was thinking originally. It would certainly reduce clutter, but would require that someone starts playing the episode locally before casting (unless I'm not understanding you properly). Perhaps that's not so bad though? I don't really have a good idea of how this works elsewhere. [@tomhennen]

Your assumption is true, also for Spotify. I don't really see any problem there, no; I don't think it's so bad. At least, it's true if the user didn't initiate playback at all. For me, in most of the cases, the miniplayer will be visible (even after force-closing the app, playback is paused and the miniplayer remains visible).

Right now, as of the latest commit, the cast button isn't showing all the time anymore. Current behavior is: [@domingos86]

This makes sense and is perfectly fine, but for later stages I'd still prefer the mini-player + action bar in player view :)

Here's how it looks/works in Spotify:
https://owncloud.vub.ac.be/index.php/s/9LE6G0k9EKZjYcz

[domingos86]

@yzerman19 Actually in the situation that I mentioned (that you disconnect your wifi), the expected behavior should be for the cast button to have this animation showing that it's trying to reconnect. If it's not showing in your case, then you should let me know the exact conditions so that I can try to reproduce it.

[domingos86]

@keunes thanks for the screenshots. If we do it we should allow the mini-player to increase its size a little bit, and make it not look weird when devices are being discovered (i.e., it's either always bigger or changes size the same way a cast button would show up). Of course this is a discussion we should have later, once all the basic functionality (including device sharing) is working without a problem.

[yzerman19]

As for the crash, I was able to reproduce it on my phone, so I know what the issue is. It essentially happens when you're watching a video on your device and choose to start casting. Am I right?
It's a shame that I hadn't tested that particular sequence of events before (I had only started casting from the queue or from the audio player). This shouldn't be too difficult to solve anyways, so a fix should be coming tomorrow.

Yes, I think you reproduced the issue the same way as me.
As for not catching it yourself, you can't test everything, and that's what people like me are for :) You're doing a great job.

As for the disconnected wifi, I will do more testing later, but I think you are correct about the animation.

A technical question about casting podcasts- If I have already downloaded a large video podcast and it is on my phone, when I cast it to CC, does the CC re-download the podcast again? or does it get it from my phone?

[domingos86]

@yzerman19 it redownloads. Some people have requested the possibility of streaming from the phone's storage. That feature is not a priority for now, but sooner or later should be implemented.

[keunes]

@mfietz Guess this one can be closed as 'implemented' :)