Build installed as per instructions. I’ll let you know!
@sam_nazarko I did a stupid.
I forgot I had left the USB drive in with the last build.
I don’t think it updates it - build date is still 02/09/2022, but the main issue is the vero will not boot up without the USB drive in now - I get “[FAILED] Failed to start Load Kernel Modules.”
Can I fix this when booting from the USB drive?
thanks and sorry!
Nick
USB being attached won’t be relevant – does Kodi load?
Sam
Installed this today will monitor and feedback.
Hi Sam,
Sadly not. I get that error on a blue screen, then after a few more seconds it moves to a sad face. Then get a failed boot loop with sad faces.
booting from usb is fine though - I left that on in case the new build was deployed to the usb but it doesn’t look like it was, and cec problems still there. I think I broke the main installation.
I applied the build using the scripts you sent, but I did it over ssh rather than with keyboard plugged in (I couldn’t access the tv at the time)
I’d suggest uploading some logs in a new thread.
I’ve sorted it Sam. Managed to a command prompt by pressing esc, stopped mediacenter to prevent constant reboot loop and ran your commands above again.
I’ll let you know how I get on (again)
Unfortunately, after a couple of days on the fix via staging the problem has returned for me. The Vero has disappeared from the selection of inputs on my TV and when I manually switch the AVR to it there is no CEC control and it has hijacked other HDMI-connected devices stopping them from being able to be selected via the TV menu, and audio is forced out the TV speakers, not the AVR.
No debug logs sadly but I have rebooted and turned on debug to try to capture some if it does it again.
Hi, also applied that staging fix and the issue still manifested within 24hrs.
Will try supply more logs.
How can I verify the Staging Build was applied @sam_nazarko ?
If you post some logs I can confirm.
Unfortunately the attempted fix is only an educated guess. I’ve only had one person test things and haven’t really had any logs as you can see in this thread.
If the issue persists I will park it for now until I get sufficient feedback to make further improvements
Thanks for your understanding
Sam
It’s v. hard to collect logs unfortunately via the conventional method for this since the behaviour cannot be reproduced reliably by any user action I’ve discovered. It just seems to happen by itself after a time (for me, it’s typically when the TV/AVR have been in standby for a long period of time (hours) and I go to turn it on I might discover the Vero’s input has vanished from the available list and other HDMI-connected devices are subsequently misbehaving. A reboot of the Vero, or restart of mediacenter service over SSH) seems to sort it for a while.
In the meantime I have turned on debug logging (since last night) on my Vero and will def. send them over when it does it again - I am hoping they will not be too large though since they may well have been running for >24hrs before it occurs.
If that is the case, or alternatively, is there any way I can capture some other logs and/or do anything else to help? I’m au fait with the CLI…happy to help however to try to nail this down…
Sorry for a basic question, is there a way to rollback to the previous build? I am unable to have my Vero plugged into my TV at the moment on the current build. Thanks Steve
I have the same problem vero Just disapears from tv input. I can watch a show for 20-40 min and then the tv screen goes black and tv is searching for input.
Samsung q90 ,Denon x3600 and vero 4k+
That’s not what users in this thread are talking about.
I’d suggest starting a new support request.
Sam
Spoke too soon, it’s certainly better than it was but it’s started playing up again, as someone else said.
No idea what to do with sending logs etc, no idea when the event occurs that throws everything off.
There’s always a chance it’s a combination of ham fisted interpretations of cec specification from any of the devices in the chain - maybe I’m over simplifying things, but I don’t get why something as simple as cec isn’t rock solid and hasn’t been for 10 years - why are there always changes and improvements to something that should change very infrequently…
Not saying your work is hamfisted by the way Sam, you have to rely on libcec and the firmware in the actual hardware component here!
I’m home tomorrow and will install this and start logging. As I’ve never compiled any logs, do I enable logging and then when it happens - as some have said above, when the devices have been off for a period of time (usually overnight) send the logs into here.
Mine usually exhibits this behaviour overnight and it’s easily observed. My Apple TV is connected to the Soundbar and the Vero via eArc and when it glitches I can switch the devices on with the Apple Remote.
I just set debug logging going and left it logging until it did it again. I have sent a couple of sets of logs whilst it is in a “stuck” state and from a number of hours later when it just sorted itself out without me intervening (it never did that before I took the staging update), but I assume Sam will need more logs from a variety of users in case the behaviours are different depending on different hardware involved.
For me it has manifested in a variety of ways as I had mentioned earlier, none of which ever happened before the September update.
Here’s some logs, look at the kodi old log file :
https://paste.osmc.tv/ugumigosow
EDIT : not in debug mode so there is nothing useful, sorry, and i can’t reproduce it right now
I got 2 errors when generating the logs :
An error occurred while grabbing OSMC Build Information:
FileNotFoundError: [Errno 2] No such file or directory: ‘/etc/osmc_build_info’
…
An error occurred while grabbing edid-decode:
FileNotFoundError: [Errno 2] No such file or directory: '/usr/bin/edid-decode
The second one was fixed with :
apt install edid-decode
And for the first one :
apt install debootstrap
debootstrap_version=$(debootstrap --version awk {‘print $2’})
build_date=$(date)
hostname=$(hostname)
echo -e “OSMC filesystem assembled on ${hostname} at ${build_date} using Debootstrap version ${debootstrap_version}” > ${1}/etc/osmc_build_info