search

SvenVD / rpisurv

Raspberry Pi surveillance
https://community.rpisurv.net
GNU General Public License v2.0
610 stars 101 forks source link

Keypresses not detected #115

Closed ostermang closed 3 years ago

ostermang commented 3 years ago

Most keypresses are not being detected, so screens are not switching. Using the + or n keys nearly always works to advance one screen. However, using the number keys 0-3 on the keypad doesn't work very often, even when holding the key down. I have enabled debug logging and see the keypresses logged when they do work. However, most of the time when I press a key, the keypress is not logged and the screen does not change.

I have verified the keyboard is working and even tried a second keyboard to be sure.

Running on a dedicated RPi 4 with 4GB RAM. CPUs all around 8-15% and only using about 125mb of memory.

Running version 3.0.0-beta5 with a 2x2 screen and then three 1x1 screens to go full screen with the streams on the 2x2 screen. All streams are 640x480 h264. Opportunistic caching is turned off.

SvenVD commented 3 years ago

Hi, if you rapidly press a different numbers after each other, and it is still in the midst of changing the screen, it wont register new presses for some very short time (depending how long the screen change takes).

If you wait for the screen to change before pressing a new key, does it work then?

ostermang commented 3 years ago

Unfortunately, no. I have tried being very patient with it, pressing the button and then waiting for a bit. Every now and then it will pick up the key press after some delay, but usually it doesn't catch the key press at all. I've also watched the logs and as you mentioned, waited until it wasn't changing or reloading screens and it is still hit or miss if it catches the key press.

SvenVD commented 3 years ago

Unfortunately, no. I have tried being very patient with it, pressing the button and then waiting for a bit. Every now and then it will pick up the key press after some delay, but usually it doesn't catch the key press at all. I've also watched the logs and as you mentioned, waited until it wasn't changing or reloading screens and it is still hit or miss if it catches the key press.

Unfortunately, that is something I can not reproduce, if I wait for the screen change to complete before pressing another key then I see no occurrence of a missed keypress, do you also have the problem with the F functions keys?

ostermang commented 3 years ago

Not sure if this has anything to do with it, but is it normal for the following lines in the log to be happening 1-2 times per second?

2021/02/11 17:31:01 - l_default - DEBUG - total available malloc gpu mem value is 16M 2021/02/11 17:31:01 - l_default - DEBUG - convert_gpumem_string_to_bytes: inputmem:13M outputmem_bytes:13631488.0 2021/02/11 17:31:01 - l_default - DEBUG - convert_gpumem_string_to_bytes: inputmem:16M outputmem_bytes:16777216.0 2021/02/11 17:31:01 - l_default - DEBUG - free reloc gpu mem value is 448M 2021/02/11 17:31:01 - l_default - DEBUG - total available reloc gpu mem value is 492M 2021/02/11 17:31:01 - l_default - DEBUG - convert_gpumem_string_to_bytes: inputmem:448M outputmem_bytes:469762048.0 2021/02/11 17:31:01 - l_default - DEBUG - convert_gpumem_string_to_bytes: inputmem:492M outputmem_bytes:515899392.0 2021/02/11 17:31:01 - l_default - DEBUG - screen_manager_0: disable_autorotation is True, use input keyboard/mouse/touch only to rotate between screens 2021/02/11 17:31:02 - l_default - DEBUG - free malloc gpu mem value is 13M 2021/02/11 17:31:02 - l_default - DEBUG - total available malloc gpu mem value is 16M 2021/02/11 17:31:02 - l_default - DEBUG - convert_gpumem_string_to_bytes: inputmem:13M outputmem_bytes:13631488.0 2021/02/11 17:31:02 - l_default - DEBUG - convert_gpumem_string_to_bytes: inputmem:16M outputmem_bytes:16777216.0 2021/02/11 17:31:03 - l_default - DEBUG - free reloc gpu mem value is 448M 2021/02/11 17:31:03 - l_default - DEBUG - total available reloc gpu mem value is 492M 2021/02/11 17:31:03 - l_default - DEBUG - convert_gpumem_string_to_bytes: inputmem:448M outputmem_bytes:469762048.0 2021/02/11 17:31:03 - l_default - DEBUG - convert_gpumem_string_to_bytes: inputmem:492M outputmem_bytes:515899392.0 2021/02/11 17:31:03 - l_default - DEBUG - screen_manager_0: disable_autorotation is True, use input keyboard/mouse/touch only to rotate between screens

SvenVD commented 3 years ago

That is normal output in the debug, If you suspect it has anything to do with it you could try to disable the memory checking

memory_usage_check: False in general.yml

ostermang commented 3 years ago

Ok, I disabled the memory usage check which made the logs much easier to read. I still get the line below once per second and still have the issue with the keypresses not being picked up. Although it does seem to have improved a little bit.

2021/02/11 18:40:56 - l_default - DEBUG - screen_manager_0: disable_autorotation is True, use input keyboard/mouse/touch only to rotate between screens

ostermang commented 3 years ago

One interesting thing that I noticed in the logs is that it typically catches keypresses about 10-15 seconds after the 19 second update. Out side of this window, they are missed.

SvenVD commented 3 years ago

Maybe the scheduled health probing of your setup takes unusually long (what is your config), during which also no keypressed are registered. Does increasing interval_check_status: to something very high like 86400 solves something?

ostermang commented 3 years ago

Sorry for the delayed response. I tried setting interval_check_status to 86400 and it does make it a little more responsive, but still not perfect. There are still times where pressing the number keys on the keypad just refuses to work, but pressing the + key works nearly instantly.

Here is my general.yml: `advanced: update_stats: False enable_opportunistic_caching_next_screen: False memory_usage_check: False interval_check_status: 86400

fallbacks: displays:

And my display1.yml: `essentials: disable_autorotation: true

screens:

AadityaRathod97 commented 3 years ago

Hi, I want to be able to change the stream with the help of GPIO input, is that possible if yes? where should I put my code and also how to stop the switching between streams automatically

SvenVD commented 3 years ago

Hi, I want to be able to change the stream with the help of GPIO input, is that possible

This should be possible with, for example, an intermediate python script.

  1. register you gpio input
  2. depending on gpio input, simulate the wanted standard keyboard keys presses( which keys rpisurv understand: https://github.com/SvenVD/rpisurv/tree/v3_latest#rpisurv-in-operation )

if yes? where should I put my code and also how to stop the switching between streams automatically

disable_autorotation: False https://github.com/SvenVD/rpisurv/blob/v3_latest/surveillance/conf/display1.yml

AadityaRathod97 commented 3 years ago

HI, ThankYou For Your Help

AadityaRathod97 commented 3 years ago

Hello again, so i have the code which sends the key press ready and i am running it on autostart through rc.local but i think my code is not executing because i think rpisurv takes over not sure how do i make sure that my code and rpi both are working together?

i am new to this.

SvenVD commented 3 years ago

Hello again, so i have the code which sends the key press ready and i am running it on autostart through rc.local but i think my code is not executing because i think rpisurv takes over not sure how do i make sure that my code and rpi both are working together?

i am new to this.

Maybe you can find some inspiration here: https://github.com/SvenVD/rpisurv-api

thezab commented 3 years ago

Hi, So i wanted to know if it's possible to switch between streams under 3s? I tried interval_check_status and cache_next_screen but it still takes 9-11s to start the stream So i was wondering is there any way that can be improved?

Thanks for your help:)

SvenVD commented 3 years ago

Please do not use this issue for non-related questions.

Support forums are over here /https://community.rpisurv.net/

Hi, So i wanted to know if it's possible to switch between streams under 3s? I tried interval_check_status and cache_next_screen but it still takes 9-11s to start the stream So i was wondering is there any way that can be improved?

Thanks for your help:)

You need to allow some time for next screens cache to warm up. Typically that takes longer than 3s. If a screen cycles and you wait for example 20 seconds, then cycling to the next screen will be seamless, if you cycle to fast you will see the streams still loading.

SvenVD commented 3 years ago

Sorry for the delayed response. I tried setting interval_check_status to 86400 and it does make it a little more responsive, but still not perfect. There are still times where pressing the number keys on the keypad just refuses to work, but pressing the + key works nearly instantly.

Here is my general.yml: `advanced: update_stats: False enable_opportunistic_caching_next_screen: False memory_usage_check: False interval_check_status: 86400

fallbacks: displays:

  • hdmi: 0 display_number: 2 resolution: width: "1920" height: "1080" device_name: "fallback_device_0"`

And my display1.yml: `essentials: disable_autorotation: true

screens:

  • camera_streams:
  • url: "rtsp://redacted_1/cam/realmonitor?channel=1&subtype=1" rtsp_over_tcp: true
  • url: "rtsp://redacted_2/cam/realmonitor?channel=1&subtype=1" rtsp_over_tcp: true
  • url: "rtsp://redacted_3/cam/realmonitor?channel=1&subtype=1" rtsp_over_tcp: true
  • url: "rtsp://redacted_4/cam/realmonitor?channel=1&subtype=1" rtsp_over_tcp: true nr_of_columns: "2"
  • camera_streams:
  • url: "rtsp://redacted_1/cam/realmonitor?channel=1&subtype=1" rtsp_over_tcp: true
  • camera_streams:
  • url: "rtsp://redacted_2/cam/realmonitor?channel=1&subtype=1" rtsp_over_tcp: true
  • camera_streams:
  • url: "rtsp://redacted_3/cam/realmonitor?channel=1&subtype=1" rtsp_over_tcp: true
  • camera_streams:
  • url: "rtsp://redacted_4/cam/realmonitor?channel=1&subtype=1" rtsp_over_tcp: true`

Just a guess, could you try to disable probing and see if that changes anything, for the keypresses delay you experience?

disable_autorotation: False https://github.com/SvenVD/rpisurv/blob/v3_latest/surveillance/conf/display1.yml

I can not think of a reason why the + key would be registered better then another key. I still can not reproduce

on top of that rtsp_over_tcp is generally not needed anymore in vlc player as it does not seem to have the smearing issues like omxplayer, at least that is what I experienced

SvenVD commented 3 years ago

stale issue

stevenhorner commented 11 months ago

Strangely I have the same issue.

If I press the + key it work perfectly every time, but no matter which number I press nothing happens. I am using a separate number pad, yet if I press the numbers on the terminal I see number 0 - 9 as expected. I plugged in a regular full keyboard and the number pad worked on it.

It's not that the number pad is faulty as proved with the numbers appearing when not in rpisurv but at a terminal prompt. The reason for buying the number pad was to switch screens. Number also worked in windows as expected.

SvenVD commented 11 months ago

Maybe keypresses of your numpad are registered differently, debug log of rpisurv could reveal what it detects