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

Streaming sessions are not closed on proxy disconnect #386

Closed
asm09fsu opened this issue Apr 4, 2016 · 6 comments
Closed

Streaming sessions are not closed on proxy disconnect #386

asm09fsu opened this issue Apr 4, 2016 · 6 comments
Labels
bug A defect in the library
Milestone

Comments

@asm09fsu
Copy link
Contributor

asm09fsu commented Apr 4, 2016

Bug Report

Currently, if a video or audio streaming session in SDLStreamingMediaManager is connected and streaming, and the proxy gets disconnected, the streams are in a non-ideal state as they are not closed.

Reproduction Steps
  1. Connect Proxy to Core.
  2. Begin video/audio streaming.
  3. Disconnect Proxy from Core.
Expected Behavior

Video/audio streaming should be stopped.

Observed Behavior

Video/audio streaming is not stopped.

OS & Version Information
  • iOS Version: iOS 9.3
  • SDL iOS Version: 4.1.0
  • Testing Against: Core 4.0
@asm09fsu asm09fsu added the bug A defect in the library label Apr 4, 2016
@joeljfischer
Copy link
Contributor

How do you mean disconnect? If only the RPC service disconnects that does not affect the video or audio services.

@asm09fsu
Copy link
Contributor Author

asm09fsu commented Apr 4, 2016

Shouldn't we be checking the connection state of the proxy before sending data of any kind? This may actually be even further out of scope and be a question for the entirety of the proxy.

If we start a video session, and core is shut down, what happens to this session? Is the videoSessionConnected updated? It doesn't seem so.

@joeljfischer
Copy link
Contributor

When a transport is disconnected, it ought to notify the proxy, which ought to notify its protocol that all sessions have been terminated, which should then roll back up the chain to the streaming manager. That's how I think it should work, but I doubt it does work that way.

@joeljfischer joeljfischer added this to the 4.1.X milestone May 10, 2016
@joeljfischer
Copy link
Contributor

@asm09fsu Has this been fixed?

@asm09fsu
Copy link
Contributor Author

@joeljfischer This has not been resolved, however with the improvements in this proposal it would be resolved. We could add a hot fix in now that would notify SMM of these changes.

@joeljfischer
Copy link
Contributor

@asm09fsu That would be better. We don't want to wait 'till 5.0 for bug fix changes if possible.

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

No branches or pull requests

2 participants