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

TouchUI stop refreshing HDMI Display #281

Closed
maganzi opened this issue Jan 20, 2019 · 55 comments
Closed

TouchUI stop refreshing HDMI Display #281

maganzi opened this issue Jan 20, 2019 · 55 comments

Comments

@maganzi
Copy link

maganzi commented Jan 20, 2019

Hey,

i have found the following issue.
I can start prints at my Macbook, everything is working fine.
I can control the printer with the OctoPrint itself on the HDMI Touchscreen. But i can´t start a new print. The HDMI Display isn´t frozen but it doesn´t refresh the printing item area.

Thank you for your help!

octoprint.log

img_2103

@stale stale bot added the inactive label Feb 3, 2019
@maganzi
Copy link
Author

maganzi commented Feb 8, 2019

still have this problem

@stale stale bot removed the inactive label Feb 8, 2019
@stale stale bot added the inactive label Feb 22, 2019
@Jaxel
Copy link

Jaxel commented Feb 25, 2019

I have the same issue.

@BillyBlaze
Copy link
Owner

Thanks all for reporting this issue. I am trying to reproduce the issue but sofar I have no success. Could anyone please share your octoprint.log so I could possible identify a suspect.

@TheNore
Copy link

TheNore commented Mar 14, 2019

octoprint.log

this is my last log, it happened 2x in those prints. once it happens again I will post a log immediately. Thanks for resurrecting/merging this issue.

@BillyBlaze
Copy link
Owner

hmm, seems like everyone who has this issue have a big log file with a repeating Socket message held back, but backlog full. Throwing message away.

Could you confirm how you login? Do you have autoLoginAs enabled or do you manually login with TouchUI?

@TheNore
Copy link

TheNore commented Mar 14, 2019 via email

Repository owner deleted a comment from stale bot Mar 16, 2019
Repository owner deleted a comment from stale bot Mar 16, 2019
Repository owner deleted a comment from stale bot Mar 16, 2019
@BillyBlaze
Copy link
Owner

Hi @foosel, sorry to intrude you with this issue on this tracker, but I am unable to find a good way to reproduce the following issue and to find out if this is a OctoPrint issue:

  1. It seems the ForceLogin plugin is blocking the WebSockets while users are logged in and past the ForceLogin screen
  2. I have looked into [1.3.10rc2] Forcelogin interferes with websocket messages sent by plugins right on UI load OctoPrint/OctoPrint#2898 but seems not related

Do you want to move this issue over to the OctoPrint issue tracker to have more information?

@foosel
Copy link
Contributor

foosel commented Mar 17, 2019

Socket message held back, but backlog full. Throwing message away

So that indicates that the web frontend did not authenticate with the websocket. It should do that immediately after (passive) login. For some reason it is not doing it, which makes me think it might be an issue of some stale version of the web interface in the browser's cache that doesn't yet do the authentication. I've had two people run into this now due to a weird situation in their OctoPrint install, caused by some old files lying around, see this FAQ entry. Maybe this is a similar situation?

It seems the ForceLogin plugin is blocking the WebSockets while users are logged in and past the ForceLogin screen

This is true. The fix for OctoPrint/OctoPrint#2898 introduced the message backlog in order to make this process less side effect heavy for third party plugins. This backlog usually should not fill up - that it does indicates that for some reason the socket authentication is not happening. Does TouchUI rely on any kind of API key based authentication or does it just use stock auth?

@BillyBlaze
Copy link
Owner

BillyBlaze commented Mar 17, 2019

Thanks for your time and the response!

I've had two people run into this now due to a weird situation in their OctoPrint install, caused by some old files lying around, see this FAQ entry. Maybe this is a similar situation?

This could very well be the issue, there have been some issues with caching before and a latest Pull Request disables the entire cache.

Does TouchUI rely on any kind of API key based authentication or does it just use stock auth?

No, TouchUI does not rely on API keys and use stock auth. The philosophy of TouchUI is to transform the layout and to minimize any side-effects on OctoPrint core functionality.

@BillyBlaze
Copy link
Owner

BillyBlaze commented Mar 17, 2019

+all, can you try updating the bootloader to the latest version to see if this issue still persists?

@Jaxel
Copy link

Jaxel commented Mar 17, 2019

I updated the bootloader... but now I'm getting a login screen and I don't know why.

@BillyBlaze
Copy link
Owner

Good, this is expected. We only need to setup the autoLogin feature on your touchscreen:

  1. Run sudo ~/TouchUI-autostart/helpers/install
  2. Insert username during autoLogin step

@Jaxel
Copy link

Jaxel commented Mar 17, 2019

Okay, all is working now. Lets see if the screen dies again in a few days.

@TheNore
Copy link

TheNore commented Mar 18, 2019 via email

@Jaxel
Copy link

Jaxel commented Mar 19, 2019

It froze again. Worse than before. I used to be able to still navigate the menus, it just never updated the print status. Now I can't navigate the menus at all. The mouse cursor shows up, but nothing changes.

@BillyBlaze
Copy link
Owner

That sounds like a different issue; can you start by sharing the latest octoprint.log?

@TheNore
Copy link

TheNore commented Mar 24, 2019

this is still happening ;/ little to no improvement.

@TheNore
Copy link

TheNore commented May 15, 2019 via email

@BillyBlaze
Copy link
Owner

Does this issue also persist on OctoPrint 1.3.11? and whats the octoprint log of that?

@TheLion
Copy link

TheLion commented May 16, 2019

My preliminary finding is that in Octoprint 1.3.11 is does refresh and doesn't freeze up anymore. :-) But have to test some more.

@TheLion
Copy link

TheLion commented May 18, 2019

Unfortunately it didn't update again during my last print :-( It does respond to touch, like scrolling, but not all commands (like trying to get to the TouchUI submenu to refresh TouchUI) work.

@TheNore
Copy link

TheNore commented May 18, 2019 via email

@BillyBlaze
Copy link
Owner

BillyBlaze commented May 18, 2019

The issue about no able to open the TouchUI settings in 1.3.11 is already fixed (#299) and will be released in upcoming version.

That OctoPrint stops refreshing is still a concern, any change to share your octoprint log again.

@TheLion
Copy link

TheLion commented May 18, 2019

The TouchUI settings issue isn't there all the time. After restarting the Pi or TouchUI it works just fine for a while. It is something in the menu in general, also not able to enter the Connection menu item.

@TheNore
Copy link

TheNore commented May 18, 2019 via email

@BillyBlaze
Copy link
Owner

I dont see any log :(

@TheNore
Copy link

TheNore commented May 21, 2019 via email

@BillyBlaze
Copy link
Owner

nope, no attachments.

@TheNore
Copy link

TheNore commented May 21, 2019

octoprint (7).log

@TheNore
Copy link

TheNore commented Aug 17, 2019

This is still happening to two different octo print instances on two different screens

@Kiron21
Copy link

Kiron21 commented Aug 20, 2019

Me too, me too :(

@Vertigo1206
Copy link

Still the same issue.
Needs to be reloaded at least once a day.

Raspberry Pi 4B
Octoprint: Version 1.3.12

Octoprint log attached:
Does the Plugin have its own log file?
octoprint 16.12.2019.log

@AfroPsycho
Copy link

Same issue here everything is up-to-date and it just happened a minute ago this isn't the first time it happens by the way
Maybe little refresh button will do the work whenever it happens I restart the octoprint but refreshing the touchui would be easier

@lciscon
Copy link

lciscon commented Jan 4, 2020

I am having this issue as well. Same error message.

This happens to me usually after the session has been running for some length of time (e.g. hours - but it varies). Given that, it seems logical to me that the browser session is timing out and there is a race condition occurring when everything tries to reconnect.

Rather than trying to fix the race condition, perhaps it would be easier to try to either remove or postpone the timeout itself? Is there a browser setting for that? Or maybe something could generate ping events simulating user input periodically as a kind of keep-alive?

Just a thought...

@TheNore
Copy link

TheNore commented Jan 4, 2020

@BillyBlaze - is there any way we can help? I know this is a old issue that still plagues us. I will gladly donate for your time. Over the past year it has been very tough to use my printer accurately, as I highly depend on the touchui for my printers.

@Vertigo1206
Copy link

Vertigo1206 commented Jan 5, 2020

@Iciscron
I found a lot of arguments, maybe this will held
https://peter.sh/experiments/chromium-command-line-switches/

@TheNore
Copy link

TheNore commented Mar 4, 2020

Just upgraded to Octoprint 1.40 and get this screen on the initial touchui startup.
IMG_20200304_112201

@AfroPsycho
Copy link

Same issue here everything is up-to-date and it just happened a minute ago this isn't the first time it happens by the way
Maybe little refresh button will do the work whenever it happens I restart the octoprint but refreshing the touchui would be easier

I dont know how did overlook this for a long time but in the TouchUI settings there is a "Refresh TouchUI" button which solves my problem completely
All I need was a little refresh button now when touchUI show outdated information I can simply refresh it

@TheNore
Copy link

TheNore commented Mar 4, 2020 via email

@BillyBlaze
Copy link
Owner

@lciscon
I am having this issue as well. Same error message.

This happens to me usually after the session has been running for some length of time (e.g. hours - but it varies). Given that, it seems logical to me that the browser session is timing out and there is a race condition occurring when everything tries to reconnect.

Rather than trying to fix the race condition, perhaps it would be easier to try to either remove or postpone the timeout itself? Is there a browser setting for that? Or maybe something could generate ping events simulating user input periodically as a kind of keep-alive?

Just a thought...

Thanks for your feedback, All your suggestions would be something for OctoPrint because that is responsible for updating the information and keeping the connection alive with its websockets. All this is not managed nor manipulated by TouchUI. We only give it a bit of styling.

@TheNore
@BillyBlaze - is there any way we can help? I know this is a old issue that still plagues us. I will gladly donate for your time. Over the past year it has been very tough to use my printer accurately, as I highly depend on the touchui for my printers.

I really want to resolve this issue, however since I am unable to reproduce this issue I cant really help you. In addition to that; TouchUI doesn't not do manipulate the communication (WebSocket) connection. It's entirely managed by OctoPrint so if we do find the issue, I am afraid we need to fix that in either OctoPrint or the libary its using.

@lciscon
Copy link

lciscon commented Mar 7, 2020

@lciscon
I am having this issue as well. Same error message.
This happens to me usually after the session has been running for some length of time (e.g. hours - but it varies). Given that, it seems logical to me that the browser session is timing out and there is a race condition occurring when everything tries to reconnect.
Rather than trying to fix the race condition, perhaps it would be easier to try to either remove or postpone the timeout itself? Is there a browser setting for that? Or maybe something could generate ping events simulating user input periodically as a kind of keep-alive?
Just a thought...

Thanks for your feedback, All your suggestions would be something for OctoPrint because that is responsible for updating the information and keeping the connection alive with its websockets. All this is not managed nor manipulated by TouchUI. We only give it a bit of styling.

I understand and agree in general. However in this case the embedded browser configuration is established by TouchUI (or rather the TouchUI install scripts) not OctoPrint. So if there is a browser setting that is incorrect it has to be changed in TouchUI.

Also keep in mind that the run-time behavior of the TouchUI environment is significantly different than in other OctoPrint installs. Most people don't leave a browser window to OctoPrint open for 10+ hours. And even if they did their PC would probably go to sleep and the subsequent wakeup would trigger a refresh - thus avoiding the issue.

Net net it seems like a cumulative system behavior that only manifests in TouchUI installs. Whatever the final fix involves it has to be diagnosed first at that level.

@BillyBlaze
Copy link
Owner

I understand and agree in general. However in this case the embedded browser configuration is established by TouchUI (or rather the TouchUI install scripts) not OctoPrint. So if there is a browser setting that is incorrect it has to be changed in TouchUI.

I am not sure what you mean with browser configuration setup by TouchUI the installer; There is no such thing in the installer. However I cannot rule out that there is command line parameter like @Vertigo1206 mentioned that might trigger a race condition, but I think this would be highly unlikely. You can play with those parameters in the chromium.xinit file in the TouchUI-autostart folder.

Also keep in mind that the run-time behavior of the TouchUI environment is significantly different than in other OctoPrint installs. Most people don't leave a browser window to OctoPrint open for 10+ hours. And even if they did their PC would probably go to sleep and the subsequent wakeup would trigger a refresh - thus avoiding the issue.

Al-through I agree that a common user don't do this, I cannot rule out that people are doing this and have disabled sleep. Also you assume that a wakeup would trigger a refresh. WebSockets would be able to resubscribe to the feed without refreshing.

Net net it seems like a cumulative system behavior that only manifests in TouchUI installs. Whatever the final fix involves it has to be diagnosed first at that level.

On first sight this seems true, however I still think this problem lies into re-subscription to WebSockets on the client-side. Since refreshing the browser will fix this issue; If there was a system wide problem (e.g. no more space to write) or an expired sessions then you wouldn't be able to do other things. My experience with failing WebSockets is typically a bug in the resubscription or the server-side timing out and not on the client. This is where I would start debugging; but since I am unable to reproduce this, I am therefor unable to find the potential issue.

If you want to fix this; I would gladly give assistance. I would start by attaching the remote debugger and wait unilll it stop refreshing data and see what errors are thrown in the console or what the status is of the WebSockets in the network tab. (e.g. does it still receive events from the server-side)

@github-actions
Copy link

github-actions bot commented Dec 2, 2020

This issue has been automatically marked as inactive because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@github-actions
Copy link

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@github-actions github-actions bot locked and limited conversation to collaborators Dec 23, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

10 participants