Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Fix UI block on iOS during initial load #1086

Conversation

danielmcmillan
Copy link

Possibly related issues: #577 #1067.
I'm experiencing an issue where, if any prop that causes the applyModifiers function to be called has a value set, then the UI will block during the initial video load from a network location. This is the 'ignoreSilentSwitch', 'rate', 'volume' and 'muted' props.
I can reproduce this by pointing the player to a remote file such as 'https://www.sample-videos.com/video/mp4/720/big_buck_bunny_720p_10mb.mp4' and setting, for example, volume to 1. If the player is mounted when the app starts, then no UI will render until the video loads. Removing the volume prop prevents the issue.

I fixed the issue by adding a check that the video is ready in the applyModifiers function. The function is called again when the video state changes to ready so I don't think this causes any problems.

@cobarx
Copy link
Contributor

cobarx commented Jul 1, 2018

Thanks for suggesting this. I did a fair bit of testing around it and this has the effect of changing the styling both while it's loading and afterwards since the resizeMode modifier doesn't get applied.

What I'd suggest is filtering out the modifiers that cause it to hang so we only avoid apply those ones.

@danielmcmillan
Copy link
Author

@cobarx Okay. Thanks for the suggestion, I'll look into it and update the PR when I can.

@iloveyumiforever
Copy link

@cobarx @danielmcmillan , I have created a new PR #1113, I adopt your suggestion to filter out specific modifiers to fix this issue, and also I didn't get the meaning of "effect of changing the styling" you mentioned clearly, so I haven't find any side-effect, could you check my code and give me more specific details of the side-effect you mentioned or response/suggestion if there's exist any problem actually , otherwise if my code without any problem , could you merge this update and release a new version as soon as possible, because this bug cause so many bad user experience that our team is sticked in this problem, thanks for your helper, I am looking forward your response.

@danielmcmillan
Copy link
Author

I'm not experiencing the original issue anymore, with the latest changes on master.
I believe due to changes in the setSrc function from #1109, which moves the call to AVPlayer playerWithPlayerItem within the dispatch_after block. I guess this changes the ordering of some operations which avoids the issue.

@cobarx
Copy link
Contributor

cobarx commented Jul 16, 2018

@danielmcmillan Pretty sure you're right, that PR makes it so that all the props get set before it attempts to set the source and start loading the video. Not sure why that fixes it, but we can take the win! Thank you for letting me know, I've released 3.1.0 with that change and am closing this.

@cobarx cobarx closed this Jul 16, 2018
@cobarx cobarx mentioned this pull request Jul 16, 2018
@zek
Copy link

zek commented Aug 21, 2019

Why this issue closed? I've got the same issue on controls prop.
I applied same patch on

- (void)setControls:(BOOL)controls
{
    // Skip applying modifiers if the video is not ready to avoid freezing
    if (_playerItem.status != AVPlayerItemStatusReadyToPlay) {
        return;
    }
....

That fixes the issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants