Results 1 to 8 of 8

Thread: Chromecast play after tablet off

  1. #1

    Chromecast play after tablet off

    When I use youtube or iPlayer I select what I want to play and then Chromecast plays and the tablet could be switched off and the stream will continue to play. With bp it will play the podcast episodes downloaded by streaming them from the tablet to the cc. Is there anyway that the cc could be supplied the URL of the podcast from bp and then it plays directly. I can see that would work but thinking ahead I can't see how the pod would be marked as read / listened to view that method

  2. #2
    BeyondPod Team
    Join Date
    Mar 2012
    Location
    UK (BP Team member from Jun 2012 to Mar 2017), http://blog.juwlz.co.uk/
    Posts
    4,169
    BeyondPod ALWAYS streams direct from the podcast's online URL to a Chromecast. Chromecast is not designed to cast local content from your device (despite Koush's hacks to make it work).

    Chromecast then plays the podcast, and periodically reports back to BeyondPod, so that BP gets updated progress information.

    What's the issue that you're seeing?

  3. #3
    I will try it again and report back. I use juice defender on tablet to close WiFi on screen off so it uses minimal power when screen off. The iPlayer programme kept playing but I thought the podcast stopped. Could it be streamed from the source but relies on having a control link for volume, pause button etc and losing that link causes the vid to end? ( no idea how it works but just guessing). Let me get that it wasn't a one off and then I will let you know

  4. #4
    BeyondPod Team
    Join Date
    Mar 2012
    Location
    UK (BP Team member from Jun 2012 to Mar 2017), http://blog.juwlz.co.uk/
    Posts
    4,169
    Quote Originally Posted by nickthorley View Post
    I use juice defender on tablet to close WiFi on screen off so it uses minimal power when screen off.
    Then that's the issue. Without WiFi on, Chromecast and BeyondPod can't do the handshaking. I'm not sure of the details in terms of how the handshaking is requested, but the ChromeCast player is detecting that it can't find the initiating device any more, so stops playback before it gets too out of sync with what BP is aware of.

    I guess with YouTube and iPlayer, the app doesn't really need to have (or at least don't request) progress information, because they're not necessarily going to take any action based on it anyway? My guess is that YouTube keeps its playback information in the cloud anyway, and iPlayer doesn't give you the option to resume playback where you left off (or at least, if it does, it won't know where you left off if you switch WiFi off, because the CC can't tell it where you were).

    On the other hand, BP expects
    a) that people will often pause playback and expect to be able to resume from that point at a later time, (whether casting or not, before or after the pause), and
    b) to be able to play multiple episodes in your playlist without having to be told to play each one individually (assuming you use Play Next or Delete and Play Next)
    To do these things, it needs the handshaking to keep track of your playback progress, update your local playlist to say that playback is complete at the end of the episode, delete the local episode if you have delete and play next set, update your other devices about progress (if you're using episode sync) so that they can resume playback at the point you left off, etc.

    Without the handshaking and timeout, it would be perfectly possible for an episode to finish without BP ever knowing. As far as it is concerned, you'd have reached the point in playback where the WiFi was switched off, so that's where it would resume. And, of course, if you're casting multiple episodes in your playlist, BP can't advance to the next episode to start playback without knowing that the previous one has finished. Switching the screen on to tell it to play the next one manually will probably use more battery than leaving WiFi on for the duration of the playback.

    I don't use JuiceDefender, but can you whitelist BP, so that WiFi stays on when you're playing podcasts? I'd be surprised if the amount of difference that having WiFi switched on is really that much of an issue. (It's certainly peanuts in comparison to having the screen on.)

    Julie

  5. #5

    Thanks

    Yes i whitelisted it last night and that works well. I thought it was probably a "feature" of chromecast and hence not a BP problem but always good to check

    On the subject of showing the podcasts - is there anything that the podcast companies need to do to add support for using a chromecast - or is it the case that as long as BP can download and play the podcast that it can be casted too. I am thinking file formats etc.

    Finally not a BP issue I know but any advice welcome I may stumble across vids of interest - maybe the videos from a conference that are put online or something similar that are not on the standard youtube, vimeo etc channels. Is there a website similar to something like huffduffer where I could add links to random vids and then the site generates an rss feed that I could add to BP? The only other solution i can see is to download them and add them as a local disk feed into BP but I presume that in the light of the conversation below, this wouldnt work as they would need to be online to stream them to the CC

    Anyway as I say not really a BP issue but if anyone has any suggestions then I would welcome them

    Thanks again for your help and quick replies

    Nick

    Quote Originally Posted by juwlz View Post
    Then that's the issue. Without WiFi on, Chromecast and BeyondPod can't do the handshaking. I'm not sure of the details in terms of how the handshaking is requested, but the ChromeCast player is detecting that it can't find the initiating device any more, so stops playback before it gets too out of sync with what BP is aware of.

    I guess with YouTube and iPlayer, the app doesn't really need to have (or at least don't request) progress information, because they're not necessarily going to take any action based on it anyway? My guess is that YouTube keeps its playback information in the cloud anyway, and iPlayer doesn't give you the option to resume playback where you left off (or at least, if it does, it won't know where you left off if you switch WiFi off, because the CC can't tell it where you were).

    On the other hand, BP expects
    a) that people will often pause playback and expect to be able to resume from that point at a later time, (whether casting or not, before or after the pause), and
    b) to be able to play multiple episodes in your playlist without having to be told to play each one individually (assuming you use Play Next or Delete and Play Next)
    To do these things, it needs the handshaking to keep track of your playback progress, update your local playlist to say that playback is complete at the end of the episode, delete the local episode if you have delete and play next set, update your other devices about progress (if you're using episode sync) so that they can resume playback at the point you left off, etc.

    Without the handshaking and timeout, it would be perfectly possible for an episode to finish without BP ever knowing. As far as it is concerned, you'd have reached the point in playback where the WiFi was switched off, so that's where it would resume. And, of course, if you're casting multiple episodes in your playlist, BP can't advance to the next episode to start playback without knowing that the previous one has finished. Switching the screen on to tell it to play the next one manually will probably use more battery than leaving WiFi on for the duration of the playback.

    I don't use JuiceDefender, but can you whitelist BP, so that WiFi stays on when you're playing podcasts? I'd be surprised if the amount of difference that having WiFi switched on is really that much of an issue. (It's certainly peanuts in comparison to having the screen on.)

    Julie

  6. #6
    BeyondPod Team
    Join Date
    Mar 2012
    Location
    UK (BP Team member from Jun 2012 to Mar 2017), http://blog.juwlz.co.uk/
    Posts
    4,169
    Quote Originally Posted by nickthorley View Post
    On the subject of showing the podcasts - is there anything that the podcast companies need to do to add support for using a chromecast - or is it the case that as long as BP can download and play the podcast that it can be casted too. I am thinking file formats etc.
    You can find what's supported at Supported Media for Google Cast

    The only other solution i can see is to download them and add them as a local disk feed into BP but I presume that in the light of the conversation below, this wouldnt work as they would need to be online to stream them to the CC
    You are correct that episodes in a local Virtual Feed will only play on the device, so to use BeyondPod to cast them, you'd need generate a feed containing the URLs of the online versions. I'm not aware of any services that can do this, but others may have some ideas.

    Another alternative is to use Chrome on a Destop with the GoogleCast extension to cast any browser window.

    Having said that, you may find that you can use something like Allcast (which uses a hack) to stream local content if you donwload them.

    Julie

  7. #7
    It is something rather to check with the machine than diagnosing this to be a problem with Vimeo as Vimeo has standardized the configuration so as to suit everybody's need

  8. #8
    Junior Member
    Join Date
    Jul 2019
    Posts
    7
    hi, i'm having the same issue since few days and i tried everything but nothing works
    and i don't know how to do a "whiteliste"

    _________________________________________________
    UC Browser SHAREit MX Player
    Last edited by escobarrr; 07-20-2019 at 12:45 PM.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •