Ghost key presses

Help and Support Vero V
1

I replaced my vero 4k+ with a vero v.

Ever since I’ve been plagued by occasional (anywhere between 10 min and a few hours in between) bouts of pauses and/or skips. Sometimes a single pause, sometimes it skips all the way back to the beginning, sometimes a few seconds forwards…

So I turned on the debug log, waited until the next time it happened and had a look. The logs show actual keypresses being registered.

Can you suggest anything to help me debug this further? Is there some way for me to tell which devices originated these key presses (osmc remote, IR, CEC, http, …)? I’ve had a look at the dmesg output from when this happens, but this didn’t show anything apart from the starting of the video in case of an unpause.

And to get the obvious out of the way: I wasn’t sitting on the remote, and it didn’t get stuck between the sofa cushions or something idiotic like that :smiley:

2

Share the kodi.log.
First try just using MyOSMC Log Uploader and share the URL. If that fails due to size we can look for alternatives.

3

I think I would run the following in a ssh session with debug logging turned on and let us know what the some of the commands that you didn’t actually press where. That would probably be the easiest way to get an idea of where it is coming from. It would be a bit of a task to figure out from a full log which commands were the ghost ones. That should grab anything other than from the web interface/remote app as those I don’t think actually get logged. If it doesn’t show up as a HandleKey event you could disable the web access to see if it stops.

tail -f ~/.kodi/temp/kodi.log | grep -B 1 HandleKey

4

Logs: https://paste.osmc.tv/busutebaho

From the tail, the middle keypress(es?) (StepForward) was a ghost press:

2024-01-21 10:23:39.355 T:2986    debug <general>: Keyboard: scancode: 0xa4, sym: 0x155, unicode: 0x00, modifier: 0x0
2024-01-21 10:23:39.355 T:2986    debug <general>: HandleKey: play_pause (0xf0bd) pressed, window 12005, action is PlayPause
--
2024-01-21 10:34:57.115 T:2986    debug <general>: Skipped 1 duplicate messages..                                   
2024-01-21 10:34:57.115 T:2986    debug <general>: HandleKey: right (0xf083) pressed, window 12005, action is StepForward
--
2024-01-21 11:12:22.902 T:2986    debug <general>: Keyboard: scancode: 0xa4, sym: 0x155, unicode: 0x00, modifier: 0x0
2024-01-21 11:12:22.902 T:2986    debug <general>: HandleKey: play_pause (0xf0bd) pressed, window 12005, action is PlayPause

Relevant part from kodi.log:

2024-01-21 10:34:57.088 T:3000    debug <general>: CLibInputKeyboard::ProcessKey - using delay: 750ms repeat: 80ms
2024-01-21 10:34:57.089 T:5235    debug <general>: Thread Timer start, auto delete: false
2024-01-21 10:34:57.096 T:5235    debug <general>: Thread Timer 3880100096 terminating
2024-01-21 10:34:57.115 T:2986    debug <general>: Keyboard: scancode: 0x6a, sym: 0x113, unicode: 0x00, modifier: 0x0
2024-01-21 10:34:57.115 T:2986    debug <general>: Skipped 1 duplicate messages..
2024-01-21 10:34:57.115 T:2986    debug <general>: HandleKey: right (0xf083) pressed, window 12005, action is StepForward
2024-01-21 10:34:57.117 T:2986    debug <general>: ------ Window Init (DialogSeekBar.xml) ------
2024-01-21 10:34:57.118 T:2986    debug <general>: ------ Window Init (Custom_1109_TopBarOverlay.xml) ------
2024-01-21 10:34:57.888 T:5188    debug <general>: CDVDClock::SetSpeedAdjust - adjusted:0.000000
2024-01-21 10:34:57.888 T:5188    debug <general>: CVideoPlayer::HandleMessages: demuxer seek to: 1488231.034725
2024-01-21 10:34:57.891 T:5190    debug <general>: AMLInsecureVideoCodec::SetSpeed, speed(0)
2024-01-21 10:34:57.892 T:5188    debug <general>: CFileCache::Seek - </storage/media/movies/Blitz (2011)/Blitz (2011) Bluray-1080p.mkv> waiting for position 5542076447
2024-01-21 10:34:57.902 T:5189    debug <general>: CFileCache::Process - </storage/media/movies/Blitz (2011)/Blitz (2011) Bluray-1080p.mkv> source read hit eof
2024-01-21 10:34:57.904 T:5188    debug <general>: SeekTime - seek ended up on time 1493.458
2024-01-21 10:34:57.905 T:5188    debug <general>: CVideoPlayer::HandleMessages: demuxer seek to: 1488231.034725, success
2024-01-21 10:34:57.905 T:5188    debug <general>: CVideoPlayer::FlushBuffers - flushing buffers
2024-01-21 10:34:57.905 T:5190    debug <general>: AMLInsecureVideoCodec::reset
2024-01-21 10:34:57.921 T:5191    debug <general>: CDVDAudio::Pause - pausing audio stream
2024-01-21 10:34:57.972 T:5191    debug <general>: CDVDAudio::Flush - flush audio stream
2024-01-21 10:34:57.972 T:5191    debug <general>: CDVDAudio::Pause - pausing audio stream
2024-01-21 10:34:57.972 T:5191    debug <general>: CVideoPlayerAudio - CDVDMsg::GENERAL_SYNCHRONIZE
2024-01-21 10:34:57.972 T:5190    debug <general>: CVideoPlayerVideo - CDVDMsg::GENERAL_SYNCHRONIZE
2024-01-21 10:34:57.973 T:5190    debug <general>: CVideoPlayerVideo - Stillframe left, switching to normal playback
2024-01-21 10:34:57.974 T:5188    debug <general>: CVideoPlayer::CheckContinuity - wrapback :2, prev:1493583000.000000, curr:1493458000.000000, diff:-125000.000000
2024-01-21 10:34:57.982 T:5191     info <general>: CAEStreamParser::TrySyncAC3 - AC3 stream detected (6 channels, 48000Hz)
2024-01-21 10:34:57.985 T:5188    debug <general>: CVideoPlayer::HandleMessages - player started 1
2024-01-21 10:34:57.989 T:5240    debug <general>: Thread JobWorker start, auto delete: true
2024-01-21 10:34:57.998 T:5240    debug <general>: OnAVChange: CApplication::OnAVChange
2024-01-21 10:34:58.029 T:5188    debug <general>: CVideoPlayer::HandleMessages - player started 2
2024-01-21 10:34:58.029 T:5188    debug <general>: VideoPlayer::Sync - Audio - pts: 1493760000.000000, cache: 320000.022650, totalcache: 800000.011921
2024-01-21 10:34:58.029 T:5188    debug <general>: VideoPlayer::Sync - Video - pts: 1493458000.000000, cache: 50000.000000, totalcache: 100000.000000
2024-01-21 10:34:58.029 T:5188    debug <general>: CDVDClock::SetSpeedAdjust - adjusted:0.000000
2024-01-21 10:34:58.029 T:5190    debug <general>: CVideoPlayerVideo - CDVDMsg::GENERAL_RESYNC(1493358000.000000)
2024-01-21 10:34:58.029 T:5191    debug <general>: CVideoPlayerAudio - CDVDMsg::GENERAL_RESYNC(1493358000.000000), level: 100, cache: 508459.730983
2024-01-21 10:34:58.029 T:5190    debug <general>: AMLInsecureVideoCodec::SetSpeed, speed(1000)
2024-01-21 10:34:58.029 T:5191    debug <general>: CDVDAudio::Resume - resume audio stream
2024-01-21 10:34:58.033 T:3021    debug <general>: ActiveAE - start sync of audio stream
2024-01-21 10:34:58.172 T:3021    debug <general>: ActiveAE::SyncStream - average error of -72.884325, start adjusting
2024-01-21 10:34:58.223 T:3021    debug <general>: ActiveAE::SyncStream - average error -8.884325 below threshold of 30.000000
2024-01-21 10:35:00.273 T:5191    debug <general>: CDVDClock::ErrorAdjust - CVideoPlayerAudio::OutputPacket - error:-57915.846847, adjusted:-41666.666667
2024-01-21 10:35:01.307 T:2986    debug <general>: ------ Window Deinit (DialogSeekBar.xml) ------
2024-01-21 10:35:01.307 T:2986    debug <general>: ------ Window Deinit (Custom_1109_TopBarOverlay.xml) ------
2024-01-21 10:35:02.862 T:5190    debug <general>: CPtsTracker: detected pattern of length 1: 41666.67, frameduration: 41666.666667
2024-01-21 10:35:27.998 T:5240    debug <general>: Thread JobWorker 2318090496 terminating (autodelete)
5

Unfortunately that particular entry is the same coming from the IR sensor as well as the OSMC remote or another type of keyboard device so it only really narrowed it down to not coming from CEC. Can you use another device to control Kodi temporarily for testing (IR, CEC, keyboard, Kodi remote app) and disable the internal receiver for the OSMC remote with the following command and see if the behavior stops…

echo 1 | sudo tee /sys/devices/platform/fde00000.dwc3/xhci-hcd.0.auto/usb1/1-1/1-1.2/remove

You will have to reboot the Vero V to re-enable the remote again.

Other thoughts are have you tried re-pairing the remote by holding down the home and OK buttons for a few seconds. If it is coming from IR interference then maybe try putting something in front of the Vero V to block light. If that works then changing which remote is selected in My OSMC should probably cure that.

6

I disabled the internal receiver for the OSMC remote on Monday.

So far I see no keypresses at all in the log.

So it seems the problem lies with the OSMC remote or receiver.

I guess I’ll wait for the new dongle, and see whether that solves the problem? And if not I’ll likely need a new remote?

7

Note that the handlekey events only log with debug enabled so if you had turned that off to get rid of the annoying overlay there won’t be any of those logged.

If we could do a bit more testing that would be great. This isn’t a known issue so I would prefer not to assume too much. Can you reboot and use it normally long enough to confirm the issue is still present. One you discover that it is could you hold down the home and OK buttons until the light at the front edge of the remote starts blinking, and then use it long enough to confirm if the problem is still present. If the problem is still present could you then remove the battery from the remote control and use the Vero long enough controlling it with something else where either the problem manifests itself or it has worked long enough that your confident the problem is gone.

Those tests should definitively tell us if the dongle is somehow picking up a signal from somewhere else or if the remote is screwed up and triggering when it shouldn’t. I suspect the latter and if that is the case you can send off an email to support@osmc.tv with a link to this thread and your order number and @sam_nazarko will get a new one out to you. If your needing the updated dongle as well be sure to mention that so that can go out at the same time.

8

I’ve got it set to loglevel 1.

I’ve already rebooted a number of times while investigating this before I came here. So I’ll go directly to the rebinding. I’ll follow these steps:

  • reboot to activate the receiver
  • rebind, and wait until the problem re-occurs (if it doesn’t, problem solved)
  • remove the battery, and wait until the problem re-occurs
  • if it does, get just the replacement dongle
  • if it doesn’t, get both remote and dongle

Thank you!

1 Like
12

Rebooted, did a rebind, problem re-occurred.
Removed the battery, problem didn’t appear for a full week.
Put the battery back, and got a new ghost press the next day.

I’ll send an email.

Thanks for the help!

1 Like
13

I didn’t get a new remote, but I did figure out the source of the ghost presses!

As time went by I noticed that the problem only occurs when the remote is lying right next to my phone! (Which is where I usually keep them on the armrest of the sofa when watching tv.)

So it seems as my phone (through induction?) is causing the remote to send out ghost presses occasionally.

I don’t know if this problem is unique to my remote, but it for sure never happened with the old Vero 4K+ remote.

In any case I have a workaround for the problem (don’t keep the remote next to my phone).

2 Likes
14

Thank you for sharing these amazing insights with us. I wouldn’t have though of that in a million years. :smile: :+1:

15

That’s odd. Out of curiosity what’s the brand and model of phone?

16

It’s a google pixel 6 pro.