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

Video session is not closed in suspended state when HMI level become BACKGROUND or NONE #1047

Closed
t-yoshii opened this issue Aug 13, 2018 · 5 comments · Fixed by #1049
Closed
Labels
bug A defect in the library
Milestone

Comments

@t-yoshii
Copy link

Bug Report

Video session is not closed in suspended state when HMI level become BACKGROUND or NONE. Session should be closed even in suspended state.

Most HMI have only 1 video resource (decorder, screen, etc.). So, SDL proxy and SDLCore should close session (send Navigation.StopStream to HMI from SDLCore) at appropriate timing.

Reproduction Steps
  1. Activate VPM app1 to FULL. App1 starts video streaming
  2. Make app1 inactive. Video streaming state of app1 becomes SUSPENDED.
  3. Activate VPM app2 to FULL and VPM app1 is changed to BACKGROUND
Expected Behavior
  1. VPM app1 stops video streaming session
Observed Behavior
  1. VPM app1 does NOT stop video streaming session
OS & Version Information
  • iOS Version: 10.3.3, 11.1
  • SDL iOS Version: v6.0.1
  • Testing Against: Our internal devboard HU
Test Case, Sample Code, and / or Example App

I will create PR and will update test case.

@joeljfischer
Copy link
Contributor

@t-yoshii Many changes have been made to these classes on the develop branch. Please take a look and let us know if this is still an issue on that branch.

@joeljfischer joeljfischer added the bug A defect in the library label Aug 13, 2018
@joeljfischer
Copy link
Contributor

Never mind, I see that this is against develop. Your SDL iOS Version is therefore incorrect. It should have specified 6.1-develop or a commit entry, not 6.0.1 which has a very different streaming manager. If it affects both, then let us know. It may be worth a hotfix against master.

@t-yoshii
Copy link
Author

@joeljfischer Thanks for your comments and sorry for incorrect version.

I confirmed that this issue occurs both on 6.0.1 and 6.1-dev (3cb0f3b). Should I create different PR for master?

@joeljfischer
Copy link
Contributor

Yes, that would be helpful.

@t-yoshii
Copy link
Author

Created PR #1049 for master branch.

@joeljfischer joeljfischer added this to the 6.1.0 milestone Aug 15, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A defect in the library
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants