[BUG] Previous video gets played on the Chromecast device

[Jmilham21]

What does this Pull Request do?

• Fix casting issue for Android
• Make RNJWPlayerView lifecycle aware, which allows for better JWPlayer setup
• Fixes massive memory leak related to players not destroying as expected
• Formatting fix(es)

Why is this Pull Request needed?

• The wrong video could be cast due to players not destroying it appropriately.
• Fix a huge memory leak.

Are there any points in the code the reviewer needs to double check?

• No

Are there any Pull Requests open in other repos which need to be merged with this?

• No

Addresses Issue(s):

GitHub Issue

[guillermomachado]

@Jmilham21 I've integrated these changes as a patch package into my project, and it fixed the issue mentioned in the PR, along with some problems when changing the video while it was playing. However, I've noticed an issue when the video completes: after it finishes, it seems like the connection isn't handled properly, and we can't cast a new video. Is this a problem for you? Could you advise?

Thank you!

[Jmilham21]

Hey @guillermomachado, I'm glad it's somewhat better, but could you give me the steps to reproduce what you're experiencing? I have a hunch, but I don't want to chase a bug wildly.

[guillermomachado]

@Jmilham21 Thanks for your quick response. The steps:

1. Cast a video to a Chromecast.
2. Wait for it to finish.
3. Try to cast a new video.

See how the Chromecast shows the app's name and doesn't play a new video.

[Jmilham21]

@Jmilham21 Thanks for your quick response. The steps:

1. Cast a video to a Chromecast.
2. Wait for it to finish.
3. Try to cast a new video.

See how the Chromecast shows the app's name and doesn't play a new video.

I have tested and confirmed 😞. I will work on a further patch and update this branch and you when I have more @guillermomachado

[Jmilham21]

@guillermomachado, after some internal discussion, we opted for a slightly different approach. Since we do not have a great way to connect a player to an existing cast session seamlessly, we must lock a player to a cast session. This means that when you destroy a player that is casting, we have to break the connection to the receiver and stop playback.

Understandably, this may not be ideal for your app/use case. If you need to keep the session alive while navigating your application, we'd suggest considering having a player object alive (it can be invisible) at a higher level so it won't be destroyed. This way, if you're casting and want to change content, you can load it into this existing player (which is still connected to the end user's receiver).

If you need to, we recommend considering having a global player object that you display in your separate screens and load content through that if you need to keep your cast session alive when the screen that the player lives in is destroyed.

[guillermomachado]

@guillermomachado, after some internal discussion, we opted for a slightly different approach. Since we do not have a great way to connect a player to an existing cast session seamlessly, we must lock a player to a cast session. This means that when you destroy a player that is casting, we have to break the connection to the receiver and stop playback.

Understandably, this may not be ideal for your app/use case. If you need to keep the session alive while navigating your application, we'd suggest considering having a player object alive (it can be invisible) at a higher level so it won't be destroyed. This way, if you're casting and want to change content, you can load it into this existing player (which is still connected to the end user's receiver).

If you need to, we recommend considering having a global player object that you display in your separate screens and load content through that if you need to keep your cast session alive when the screen that the player lives in is destroyed.

Thanks for your clarification @Jmilham21, I'll consider your suggestion