Scroll issue

[videosmith]

On a few occasions while scrolling with the mouse wheel, scoll control was lost, even with keyboard input.

By exiting and re-entering the prompt mode restored scroll control.

Any suggestions?
Raspberry pi 4, latest updates.

[Cuperino]

Is the editor open in windowed mode when this happens? If so, the issue may be none of Imaginary Teleprompter's windows are focused, causing the program not to listen to inputs devices. Clicking anywhere on the prompter restores focus.

Focus loss may be caused by clicking or miss-clicking outside of Imaginary Teleprompter's windows, or by another program stealing focus away from Imaginary Teleprompter. Programs that steal focus are more common on Windows, but although rare, they're not impossible to find on Linux and MacOS.

Try closing or disabling other program activity that may steal focus away from Imaginary Teleprompter; such as programs that do periodic pop-up messages. On desktop environmentś other than Raspbian's default, enabling a do not disturb mode may also help.

[videosmith]

Editor is full screen (see pic)

I click in the prompt display for focus, otherwise the mouse wheel tends to scroll both displays, one text, the other scrollbars in the editor window.

No other programs launched (although any usb sticks occasionally remount themselves :/)

Any links describing enabling do not disturb in raspbian?

[Cuperino]

Correct, for the wheel to change velocity, the mouse cursor must be placed on top of the prompter. For keyboard inputs to work, either window can be focused, but the text editor must not be in focus. Mouse inputs are separate from keyboard inputs.

I doubt the disconnecting USB sticks would cause this issue. Unless the mouse is disconnecting, but that would prevent the mouse from moving and not just affect mouse wheel.

There's no do not disturb mode in PIXEL, Raspberry Pi OS's default desktop environment. I mentioned that in case you were using a different desktop environment, such as Gnome or Plasma. Since there are no other program running, I don't think stolen focus is the issue. Miss-clicks of the mouse are the most likely cause in my opinion...

[Cuperino]

One question... Is the prompter scrolling at a very high speed when control is lost?

[videosmith]

No. It seems to continue at the last mouse wheel's input speed.

[videosmith]

Leaving and re-entering the prompt mode appears to resolve the issue, unfortunately that resets the script to the beginning.

[videosmith]

I will notify you should a pattern develop.

[Cuperino]

No. It seems to continue at the last mouse wheel's input speed.

I see... That discards my working hypothesis...

Leaving and re-entering the prompt mode appears to resolve the issue, unfortunately that resets the script to the beginning.

This is unfortunate... The Update It button was added to prevent the need to restart, but I guess that doesn't help here.

@va2ron1 added the ability to start from current editor location to the code for the next release. We're planning to start a beta period for this update soon. I'll inform you when the beta is available.

I will notify you should a pattern develop.

Alright, thanks.

[videosmith]

Update:
Today the app was left in prompt mode sitting idle for a few hours during show setup.

When I finally attempted to scroll, the script only moved a few lines then stopped no matter if I used keyboard or mouse wheel input-acted like it was the end of the script.

Clicking Update made no difference.

Only solution was to exit then re-enter Prompt mode which then behaved normally.

Script is short with no content other than text.

[Cuperino]

When I finally attempted to scroll, the script only moved a few lines then stopped no matter if I used keyboard or mouse wheel input-acted like it was the end of the script.

That's very strange... I can't think of any time based events that could cause this... I've left a prompter running in an attempt to replicate. Is there anything else you could tell me? What was the prompter's configuration?

For my test, I'm using the external prompter only, with no flip. I have a timer paused at 00:00:00. The focus area is set to Middle and the first line of text has its baseline aligned to the bottom of the focus area. Screen width is 1920px, Font size is set to 104%, and Width to 66%. My test script is 12 lines long, with 12 paragraphs of short lengths. The test script was written in Imaginary Teleprompter itself, saved, closed and re-loaded before prompting.

[videosmith]

Raspberry Pi 4, 4Gb ram, dual monitor 1280x720p, no timer, normal prompt to external monitor only, no focus area, custom prompter style (000000, FFFFFF). font size 120%, width 90% 75 lines, copy/pasted from libre office writer, saved and program reloaded before prompting.

[videosmith]

I will check for system updates in case this is an OS issue...

[Cuperino]

I wasn't able to replicate the issue... I also tried copying from LibreOffice, pasting and prompting with and without restarting the program.

One guess is the operator may have been attempting to change the velocity while the prompter was paused, but this should result in no motion at all, not just a few lines.

Many years ago there used to be a bug where changes to the height of the script didn't always reflect in the values used for the animation loop, but I believed to have solved all those issues long ago...

Was any setting updated after the prompter had been started? If so, how was it modified?

[videosmith]

Understood. It's an infrequent occurrance and so far I have not been able to replicate it deliberately. My current thought was the OS (Raspberry Pi) may be the cause since I've also experienced issues outside of your app as well when it occurs (unable to select apps on the task bar, windows that won't un-minimize, etc.). Since I have two Pi 4's I am going to update all the OS software and then use the other one to see if the situation occurs there as well.

I am the operator and haven't used the pause function, nor altered the velocity slider.

Since my workflow is to leave the app in prompt mode and utilize the update button when the client makes edits, the only setting I usually adjust is the height of the script via your scale slider when the client requests larger font. I will explore this further.

Do you recommend a better OS than Raspbian for your app on these platforms?

[Cuperino]

It's probably an issue with power

Because you're having problems with OS components as well, I suspect the hardware may be faulty, potentially due to overheating or long periods of use. The Raspberry Pi itself throttles down to prevent overheating, but overheating may still occur in enclosed spaces. A bad power supply or lack of ground may also cause a degradation of signal integrity, which could cause bit flips that lead to an unstable system.

With regards to hardware, try:

1. Changing the RPi's power source to one with better ground.
2. Replacing the RPi's power supply.
3. Adding a heat sink and fans to the RPi. This should also improve performance because it prevents throttling.
   https://www.adafruit.com/product/4340
4. Replacing the RPi.

Adding a heat sink and and fan will likely improve performance but consume more power. If this were lack of ground or bad power supply, adding fans may actually aggravate the issue.

It may also be an issue with 32 bit architecture

While I doubt there is a problem with the OS itself, and the following is less likely than a problem with signal integrity, the issue you describe in Imaginary Teleprompter could have something to do with the 32 bit ARM architectures... Because ARM7l and ARMhf are both 32 bit, there may be an obscure overflow bug causing some value during animations to be computed incorrectly. If this were the case, using the arm64 binaries on an arm64 OS would prevent the issue from happening.

Normally I don't recommend any OS for the RPi other than Raspberry Pi OS because even though various systems work excellently on the Pi at first, when updates come they tend to break apart... This is especially true for ARM64 Linux systems, but is likely to change as ARM64 becomes more prevalent. Unfortunately, Raspberry Pi OS is ARMhf only. Its done this way to ensure Raspberry Pi OS runs on all models of Raspberry Pi since model 2. The 64 bit architecture also requires higher amounts of RAM, making it unsuitable for systems with less than 4 GB of RAM. This means you'll need either a Raspberry Pi 400 or a Raspberry Pi 4 with 4 GB or more to use the arm64 version of Imaginary Teleprompter.

If your Raspberry Pi 4 has 4 GB or more, I advice you try Ubuntu 21.10 for the Raspberry Pi. I tried it on a Raspberry Pi 400 I just got, and it works really well. Nevertheless, I'm comparing it to a Raspberry Pi 3 running Raspberry Pi OS. I don't know how much better or worse it performs compared to a Raspberry Pi 4 running Raspberry Pi OS. I expect it to be slower to start but show slightly smoother animations.

Summary

To summarize, this is likely a power issue, but it may also be an issue with Imaginary Teleprompter's 32 bit ARM binaries. The only way to be certain that it is not an architecture issue is to get rid of all potential power issues first. Try the suggested solutions as you see fit.