Vero 4K+ with Harmony Remote and other issues

Help and Support Vero 4K / Vero 4K +
1

Hi! I just received the Vero 4K+ and I’m really happy about it.
There are just a few of small things that I need to fix to complete the setup:

  • I’m using a Logitech Harmony with a Xbox 360 profile. After some remappings I have a working configuration. The only thing is that it’s a little slow: if I hit ‘right’ twice, it takes the Vero a while to move twice to the right. This is not an issue with the included RF remote.
    Also, if I hold ‘down’, it takes a while for it to start scrolling down and when it does it’s a little too fast. This seems to be an ‘issue’ with the RF remote, too.
    I also tried the MCE and Samsung profiles but the delays are probably even worse.
    I tinkered with the Harmony software, but the delay is already set to a minimum (100ms or even 0).
    I know there’s something I could do with the LIRC config, but I’m not sure what.

  • since the suspend mode only disables the HDMI out (AFAIK), the screensaver seems to be on all the time. And since the screensaver reads images from the NAS mounted via autofs/NFS, the NAS never puts the disks to sleep.

  • related to the one above: is there a way to actually quit Kodi in suspend mode and restart it when it wakes up? This would fix the problem above and also allow me to remove the wake.py script (which right now updates the library and takes me to the kodi “homepage” instead of the last screen I was on before suspend). I looked around in this forum but couldn’t find anything. Maybe I could fix this by adding a standby.py script and disabling the screensaver?

Great little device though, played everything I threw at it, 4K 10bit HDR via network included :open_mouth:

2

I guess same as was discussed here

3

You are right, I even read that thread.
Apparently, the screensaver is already disabled when the device is in standby mode, see this post by @sam_nazarko : Real standby mode available yet? - #14 by sam_nazarko

What is happening in my case, now that I think about it, is that the skin I’m using (Aeon Nox Silvo) rotates an image from that same image source (on the NAS) on pretty much all screens.

So either I disable that completely or I find a way to disable it in standby.py and re-enable it in wake.py. I’ll look into that.

In the meantime I’ll wait for someone to chime in about the remote :slight_smile:

4

If your vero is new, and you have just installed it, the CPU load is usually high as it does the scrapping of all medias. Once that is done, it should be faster again.
On the other hand, if you use the IR option of the Vero for your Harmony remote, then it is true that it is slow (most if the time). If your remote can do Bluetooth, use it. Switched over to Bluetooth (Harmony + Hub), and it is amazingly fast :wink:

5

I thought I fixed the skin background issue, here’s how for future reference and other users.
Added this in standby.py to unset the background path for the skin:

import xbmc
xbmc.executebuiltin('Skin.SetString(CustomDefaultBackground.path,)')

Added this in wake.py to update the library, take me to the home window an reset the skin background path:

import xbmc
xbmc.executebuiltin('XBMC.UpdateLibrary(video)')
xbmc.executebuiltin('ActivateWindow(10000)')
xbmc.executebuiltin('Skin.SetString(CustomDefaultBackground.path,/path/to/backgrounds/folder)')

Warning: this works for the Aeon Nox Silvo skin, you should check the right settings in your skin files (in .kodi/userdata/addon_data).

Now though, this may be unrelated and I need to test further: if I wait more than 1 minute (my screensaver timeout) and wake the Vero, my screensaver is already running, not sure why.
Also, after 10 minutes the device wakes by itself with the following (I think not very helpful) log:

11:25:46.586 T:3833344768   DEBUG: RunQuery took 72 ms for 4 items query: select * from movie_view  WHERE ((movie_view.playCount IS NULL OR movie_view.playCount < 1))
11:25:47.326 T:3833344768   DEBUG: RunQuery took 39 ms for 20 items query: select * from episode_view  WHERE ((episode_view.playCount IS NULL OR episode_view.playCount < 1))
11:25:48.844 T:3833344768   DEBUG: GetSongsFullByWhere query = SELECT sv.*, songartistview.* FROM (SELECT songview.* FROM songview  WHERE ((CAST(songview.iTimesPlayed as DECIMAL(5,1)) < 1)) ORDER BY RANDO
M() LIMIT 20) AS sv JOIN songartistview ON songartistview.idsong = sv.idsong  ORDER BY songartistview.idsong, songartistview.idRole, songartistview.iOrder
11:25:48.950 T:3833344768   DEBUG: GetAlbumsByWhere query: SELECT albumview.*, albumartistview.* FROM albumview JOIN albumartistview ON albumartistview.idalbum = albumview.idalbum  WHERE albumview.strRele
aseType = 'album'
11:25:48.965 T:3833344768   DEBUG: GetAlbumsByWhere - query took 14 ms
11:25:49.114 T:3833344768   DEBUG: RunQuery took 15 ms for 0 items query: select * from musicvideo_view  WHERE ((musicvideo_view.playCount IS NULL OR musicvideo_view.playCount < 1))
11:26:37.549 T:4079219056  NOTICE: Activating standby mode
11:26:37.550 T:4079219056    INFO: Activating Vero standby mode
11:26:37.550 T:4079219056    INFO: Toggle standby state is waking
11:26:37.550 T:4079219056    INFO: CApplication::ToggleStandby -- Toggle TMDS clock to 1
11:26:37.668 T:4079219056    INFO: CApplication::ToggleStandby -- Toggle LED brightness to 1
11:26:37.669 T:4079219056    INFO: CApplication::ToggleStandby -- governor will now be ondemand
11:26:37.678 T:4079219056    INFO: CApplication::ToggleStandby -- HPD locking will now be hpd_lock0
11:26:37.678 T:4079219056  NOTICE: CApplication::ToggleStandby -- checking for existence of /home/osmc/.kodi/userdata/wake.py
11:26:37.678 T:4079219056  NOTICE: CApplication::ToggleStandby -- script /home/osmc/.kodi/userdata/wake.py found
11:26:37.679 T:3797934848   DEBUG: Thread LanguageInvoker start, auto delete: false
11:26:37.679 T:3797934848    INFO: initializing python engine.
11:26:37.679 T:3797934848   DEBUG: CPythonInvoker(45, /home/osmc/.kodi/userdata/wake.py): start processing
11:26:37.679 T:4079203072   DEBUG: CAnnouncementManager - Announcement: OnScreensaverActivated from xbmc
11:26:37.679 T:4079219056   DEBUG: ------ Window Deinit () ------
11:26:37.679 T:4079203072   DEBUG: GOT ANNOUNCEMENT, type: 4, from xbmc, message OnScreensaverActivated

Then the device goes in suspend mode again after a timeout I set (10 minutes), it seems to execute the standby script but I see in the logs that the skin is still asking for background images.
So I’m not sure what is happening, I’m disabling the skin background feature for now.

I have a couple more things to ask (besides the slow remote issue):
I see these lines in kodi.log when running the wake/standby scripts:

10:49:15.732 T:4059034368   DEBUG: CPythonInvoker(17, /home/osmc/.kodi/userdata/standby.py): the source file to load is "/home/osmc/.kodi/userdata/standby.py"
10:49:15.734 T:4059034368 WARNING: CPythonInvoker(17): Script invoked without an addon. Adding all addon modules installed to python path as fallback. This behaviour will be removed in future version.

will this be an issue in the future?

I’m also using the Youtube addon (6.4.0) with inputstream-adaptive and I see the following every minute:

10:49:47.684 T:3693040384   DEBUG: [plugin.video.youtube] HTTPServer: Request uri path |/ping|
10:49:47.686 T:3693040384   DEBUG: [plugin.video.youtube] HTTPServer: Connection from |127.0.| Local range: |True|
10:49:47.738 T:3858522880   DEBUG: [plugin.video.youtube] HTTPServer: Ping |127.0.0.1:50152| |204|

So the Youtube HTTP server is on and receiving pings even in standby mode. This is not an issue but I’m not sure what the HTTP server is for and apparently it can’t be disabled.

Sorry for the long post, I’m working to have a perfect setup :slight_smile:

6

Update: I just discovered that the device wakes up again because the power saving timeout I set works both ways (wake up to standby and standby to wake up).
I think this may be a bug. Disabling that feature for now and re-enabling my wake.py and standby.py scripts for further testing.

EDIT: I can confirm that. Now the device correctly goes into suspend mode and stays that way, and the NAS puts the disks to sleep :slight_smile: @sam_nazarko could it be a bug?

UPDATE 2 (sorry, today I have time to work on this since I’m stuck at home):
Clarification: I’m using the picture slideshow screensaver and the screenshot folder is mounted via autofs/nfs on the NAS.
Earlier I put the Vero in suspend mode before the screensaver kicked in. All was good and after a while the disks went to sleep.
Now I tried to put it in suspend mode after the screensaver kicked in. I can see from the logs that it’s still pulling images from the NAS.
In both cases, CPU usage of kodi.bin was pretty high during standby.
I hope I can help debug this.

7

We use a fake screensaver (dim); so your skin’s screensaver shouldn’t be loading.
Sam

8

I know about the fake screensaver that should activate in suspend mode, but it seems to be buggy for me somehow.
When I resume from standby I see the screensaver picture slideshow running and sometimes it freezes and I have to reboot via SSH.

9

Does this only happen with the screensaver picture slideshow; or you can reproduce it elsewhere?

10

I just tried and was able to reproduce it with the Unsplash screensaver (a random one I tried).
I put it in suspend mode (I can see it in the logs), the LED goes red.
After a couple of minutes I turn it back on and the Unsplash screensaver is there.

Here’s a log detailing it (with some notes by me). I also disabled the wake and standby scripts I talked about to remove some possible variables.
https://paste.ubuntu.com/p/YwBGGzqT9r/

11

Thanks. I’ll look in to this.

12

Thank you Sam.
I think that the next thing I’ll try is to disable the Kodi service (headless mode) and start/quit kodi with the remote. This should fix all my issues and by actually quitting Kodi I’d also solve the high CPU usage in standby mode.

13

I assume you are getting this wrong. There is actually a lower CPU usage in standby just because of the fact that the CPU MHz are reduced it looks higher in the measurements.

14

@fzinken maybe something is wrong with my config then, in suspend mode I can see kodi.bin consistently using 60%-100% of the CPU (using top).
Is top reporting incorrect values?
Also, even if I stop kodi altogether I can see load averages of >1, even though the CPU is barely used. They should be 0.something in my experience with other linux systems.

15

As I have explained the CPU MHz is reduced by a quarter. Means the usage of the CPU that top reports increases by the same figure.

Generally OSMC on Vero reports higher load averages than eg on Pi. Can not explain that logic but at least in regards to the high level at suspend it is the same logic load average increases as the CPU is under clocked

16

My load average is around 1.15 - while the CPU utilisation goes to around 20% when in idle mode.
Guess it is normal.

17

Sorry, I misread your initial reply. Right, got it :slight_smile:

About my remote issues: I decided to go the Flirc way for speed and customizability. I’m really happy about it, no issues to report.
I’m now setting up Triggerhappy so I can start/stop the mediacenter service with the remote.
The config is:
remote yellow key mapped to F4 via Flirc that triggers a script that checks the service status and runs it.
remote blue key mapped to F5 via Flirc that triggers a script that checks the service status and stops it.

I can successfully start the service but cannot stop it: it seems that Kodi is “hijacking” the Flirc keyboard events. Running evtest with Kodi running is not showing any events.
Maybe I could completely disable Lirc as I don’t need it anymore, does it make any sense?
I see that the service is running /usr/bin/mediacenter and that starts Kodi with Lirc (sudo -u osmc $KODI --standalone -fs --lircdev /var/run/lirc/lircd). I could remove it there for a start, but I’m afraid it would cause issues or would be put back with the next OSMC update.

I’d be happy to write a tutorial about running OSMC headless with a remote once I’m done with everything.

Thanks for the support

18

One more update about this: with the OSMC April update (Kodi 18), Kodi no longer hijacks events!
I’ll write a complete “headless-mode with a remote” tutorial as soon as I can. I’d like to test it out a bit more since I’ve had a fully working configuration for a couple of days only.

@sam_nazarko I still believe that the suspend/resume issue described in my previous post is a bug, did you get the chance to look at it? I don’t use the suspend feature anymore, but I’ve seen the same bug report in other posts somewhere on this forums.

Thanks everyone for the support!

19

This is likely resolved as a result of bumping CEC.

I could not reproduce the suspend bug however, but will look at it again tomorrow.

20

I’m trying to get this working but it seem the current OSMC November update is capturing any lircd events. Running evtest or thd --dump does not capture any events although the remote is working in kodi at the same time (emulated with Harmony Elite). Any way to capture the “original remotes” key presses with triggerhappy or something like it?