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

live view doesn't work if no sub stream is configured #119

Open
IronOxidizer opened this issue Apr 9, 2021 · 2 comments
Open

live view doesn't work if no sub stream is configured #119

IronOxidizer opened this issue Apr 9, 2021 · 2 comments
Labels
bug javascript Pull requests that update Javascript code usability Usability / user interface improvements

Comments

@IronOxidizer
Copy link
Contributor

Live view does not work for cameras with no sub stream configured. The result is a black screen and the following error on FireFox

Firefox can’t establish a connection to the server at ws://192.168.1.64:8080/api/cameras/7b2c7111-09c8-42a0-bdcd-ac1439133371/sub/live.m4s. LiveCamera.tsx:85:14
door: aborting due to ws close: 1006 

It's caused by this line:

stream_id = camera.streams[stream_type.index()].ok_or_else(|| {

Potential solutions could be:

  • allow the selection of main or sub stream for live view in the web UI
  • fallback to main stream if sub stream is not available
  • disable the selection of cameras with no sub streams and add notice during config that live view is only enabled for sub streams

I'm not sure if this is expected behavior, but it should at least be documented.

@IronOxidizer IronOxidizer changed the title live view not working if no substream is configured live view doesn't work if no sub stream is configured Apr 9, 2021
@scottlamb
Copy link
Owner

Good point. I added a note to the troubleshooting doc for the moment. Long-term, I want it to support both streams; there's a bullet point about this at #115.

@scottlamb scottlamb added the js label Apr 9, 2021
@scottlamb
Copy link
Owner

I'm calling this a JS bug in that the Javascript has all the information to know in advance that the sub stream doesn't exist and the main stream does.

It'd be nice if the server reported an error in a way the client Javascript could actually see—maybe accepting the WebSocket, sending a text message with an error, then closing it—rather than a HTTP status that the browser deliberately withholds from the Javascript. But given that the error is avoidable (ignoring silly edge cases like the server being reconfigured to take away the sub stream between the loading /api/ and loading /api/cameras/.../sub/live.m4s), I think that's a secondary concern.

@scottlamb scottlamb added the usability Usability / user interface improvements label Apr 9, 2021
scottlamb added a commit that referenced this issue Aug 13, 2021
scottlamb added a commit that referenced this issue Feb 16, 2023
This gives much better information to the UI layer, getting rid of a
whole troubleshooting guide entry. See #119 #132 #218 #219

I also restructured the code in anticipation of a new WebSocket event
stream (#40).
scottlamb added a commit that referenced this issue Feb 16, 2023
This gives much better information to the UI layer, getting rid of a
whole troubleshooting guide entry. See #119 #132 #218 #219

I also restructured the code in anticipation of a new WebSocket event
stream (#40).
@scottlamb scottlamb added javascript Pull requests that update Javascript code and removed js labels Sep 30, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug javascript Pull requests that update Javascript code usability Usability / user interface improvements
Projects
None yet
Development

No branches or pull requests

2 participants