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

[Feature] Add button to Obico app/window to prevent/delay video streaming timeout #175

Open
puterboy opened this issue Jun 24, 2022 · 5 comments

Comments

@puterboy
Copy link
Contributor

Currently, whenever I hide or close the window in which Obico is running and then return to the window, the video stream stalls while buffer as presumably the streaming was interrupted while the window wasn't active.

I understand why this feature may be important (even critical) when streaming remotely when bandwidth is limited/costly -- especially if using Obico cloud.

However, if you are running at home using your own local Obico-server, one should be able to override this feature and keep the streaming going all the time.

It's especially annoying when even a momentary alt-tab away from the Obico browser tab causes the stream to re-buffer -- which takes about 3-5 seconds.

Ideally, have options as follows in the Obico UI allowing for on-the-fly configuration of the following behaviors:

  1. Current behavior - stop streaming when tab/app inactive
  2. Stream forever
  3. Stop streaming
  4. Stream only when printing
  5. Continue streaming for user-configurable X minutes after tab/app is inactive.
@kennethjiang
Copy link
Contributor

I can't reproduce it based what you described here Please list the steps to reproduce so that we can reproduce it.

@puterboy
Copy link
Contributor Author

I'm not doing anything special that I know of... but this is my current context.

  • Running Octopi + Obico on vanilla Raspbian on a RPI4 with 4GB

  • Running Obico-Server on a Linux Dell Server

  • I have an RPI camera working in Advanced mode (and restreaming jpg to Octoprint) (btw I am JK123 on the Discord board)

  • Obico (whether run in a browser tab or as an Android app) experiences a buffering delay (with white circle spinning) whenever the tab or app is activated/re-activated. The delay on the app is about 1 sec, in the browser about 3 seconds.

  • The restreamed Octoprint stream shows no video delays when the 'control' tab is activated/reactivated, confirming that there is no problem with the streaming/restreaming on the RPI (as expected since the RPI is not aware of the status of the app/tab)

  • This suggests that there is something either in the Obico app/browser code that pauses or causes the Obico server to pause when the tab/app is not active and then resumes (requiring restarting of the stream and hence buffering) when the tab/app is reactivated.

  • I thought this was a "feature" in that this was done to save bandwidth when streaming via Obico cloud and hence logged this as a feature request (rather than bug) to allow for continuous streaming without pausing when the tab/app are inactive.

If this is not the intended behavior, happy to help troubleshoot.
In particular, is there any easy way to access the Obico server stream directly (without the Obico app) - can I view it in my browser directly? This would help separate my Obico server from the Obico client code running in the browser or app.

@kennethjiang
Copy link
Contributor

  • Obico (whether run in a browser tab or as an Android app) experiences a buffering delay (with white circle spinning) whenever the tab or app is activated/re-activated. The delay on the app is about 1 sec, in the browser about 3

So the stream will resume after a brief period of showing the spinner, correct? If so, it is the expected behavior.

@puterboy
Copy link
Contributor Author

  • Obico (whether run in a browser tab or as an Android app) experiences a buffering delay (with white circle spinning) whenever the tab or app is activated/re-activated. The delay on the app is about 1 sec, in the browser about 3

So the stream will resume after a brief period of showing the spinner, correct? If so, it is the expected behavior.

I know it is expected :) -- hence my labeling as a FEATURE request rather than bug.

I can even understand why such pausing and restarting may be desirable in some situations but my point is that it is a PITA in others.

Perhaps when you are away from your LAN or if you are using the paid Obico Cloud service, saving bandwidth is important and waiting for the stream to restart is a necessary compromise.

But I typically access Obico from my LAN where I keep it running in a browser tab and frequently tab back-and-forth to check on it. Waiting a few seconds for the stream to resume is frustrating and serves no purpose on my LAN where bandwidth is not an issue.

I think Obico is a wonderful piece of software -- but there are some seemingly simple changes that would allow for user configuration of certain very simple and standard behaviors that I think would vastly expand the usability of the software with minimal (relatively speaking) changes to the code. But I understand if the devs are not interested in prioritizing other use cases (and for myself, it's trivial for me to edit the code and override hard-wired options now that I have figured most of it out -- but I am filing these requests because I think easy configurability would be great for other users)

@kennethjiang
Copy link
Contributor

I'm not sure how many users will be willing to have the streaming going all the time just to cut a couple seconds of pause. Changing it is not hard. The relevant code is: https://github.com/TheSpaghettiDetective/obico-server/blob/release/frontend/src/components/StreamingBox.vue#L109 . Feel free to submit a PR that:

  1. Makes a configurable feature to have always-on streaming.
  2. Makes the configuration hidden from the main UI since it's not a frequent control for most users (unless you can prove otherwise), while discoverable enough.

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

No branches or pull requests

2 participants