Yeah, I also had a second update, but already yesterday.
There was an update which fixed some scraping issues.
āAdded support for Full SBS / TAB support on Vero 4K / 4K + and Vā
Yay!!!
Iāll have to try the update on my 4K+ to see how it works!
1 Like
One more fix on Vero V for WiFi issues and Vero 4K/4K+ and Vero V for some crashes when seeking; just pushed.
2 Likes
Should work just fine, but let us know how you get on
Cheers
Sam
1 Like
Will do!
I just ordered a Vero5 today as well. I presume that comes with the latest version already?
Just updated and unfortunately still freezing for me. Picture freezes at āsome pointā during playback and the Vero V is unresponsive, canāt even ping it.
I might try a complete reset but itās disappointing as it had been running fine for months before the update 
I suggest a new post with some logs, particularly to ensure everything is updated.
We ship a known stable build and there is a lag between the version we ship and the stable release given the nature of shipping and sending to different resellers and partners.
As advised by the manual, you should always check for updates and install them.
1 Like
I didnāt fancy updating the Vero V just yet, so I updated an old Vero 4k+ to Kodi 21.
I got the same message about Aeon Nox and it was disabled, but when you go into the repositry, there is an update option for the skin. I did see there was a new version for Kodi 21 and upwards(?).
After updating the skin to the new release all seems to be working fine again 
2 Likes
Thank you, the latest (second update) since release resolved this (freezing) for me.
1 Like
About the timezone issue.
In guisettings.xml there is a
<setting id="locale.timezone" default="true">etc/localtime</setting>
instead of the correct (for my timezone)
<setting id="locale.timezone">Europe/Madrid</setting>
This is a glitch in the upgrade procedure.
Thanks. I will take a look at this.
Interestingly, it is not enough to edit the timezone name, you MUST delete also the ādefaultā attribute of the tag.
If you keep the default attribute, the timezone goes back to etc/localtime. Maybe this fact is the root cause of this bug.
I have a Kodi patch that keeps the timezone set in Kodi in sync with that of the system, although Kodi v22 drops this setting, so I will need to re-think how it is set.
It is very simple and unchanged over the years:
+ if (timezoneName.empty())
+ return;
+ /* Keep /etc/timezone in sync */
+ FILE *fp = fopen("/tmp/timezone", "w");
+ if (fp)
+ {
+ fprintf(fp, "%s\n", timezoneName.c_str());
+ fclose(fp);
+ int res = system("/usr/bin/sudo /bin/mv /tmp/timezone /etc/timezone"); /* We need this to update a root owned file */
+ if (res == 0)
+ {
+ char *command;
+ asprintf(&command, "%s%s%s", "/usr/bin/sudo /bin/cp /usr/share/zoneinfo/", timezoneName.c_str(), " /etc/localtime.dpkg-new");
+ system(command);
+ system("/usr/bin/sudo /bin/mv /etc/localtime.dpkg-new /etc/localtime");
+ }
+ }
+
I canāt see what would cause guisettings.xml to show the timezone as /etc/localtime. Can you reproduce the problem easily? If so, what is the value of cat /etc/timezone?
Sam, I tried this today finally and it isnāt working great for me. I found a FSBS file to try and I can āseeā the picture, but itās sitting on the bottom of the screen and is only the right frame. I discovered this when I tried closing each eye with glasses on.
Are there any settings I need to change to make this work from how it upgrades on itās on own?
UPDATE: Found a second FSBS file I had with same result.
I would suggest posting some logs so we can investigate this
I think there is some kind of change in the xml parser. The old guisettings.xml has a default attribute set to true, and that attribute is causing the replacement with etc/localtime. If you upgrade with no default attribute in that tag, it works fine.
I can reproduce this issue easily.
My /etc/localtime contains Europe/Madrid.
1 Like
Can you retry but this time please turn on debug logging.