Thanks. But can you also re-boot and upload logs from that, because after a few hours we can no longer see what happens just after booting.
Ah, will do. I will leave the debug logging on, then reboot, then when the GUI comes back up generate the logs. Watch this space !
Not so fast. If you have a screen showing, upload the logs so we can see when/how it turned itself on. Then reboot and upload logs for the boot process.
Ok. Just to be clear on my actions…
I will upload the logs when I get home. Then, with debug logging still enabled, reboot the box. When the GUI is back up upload a new set of logs.
Right?
Not quite. If the gui doesn’t come back up immediately, can you get the logs through the commandline for us?
The first logs you uploaded started from zero in the kernel message log. The second lot was missing the first few seconds because the kernel log is only so long and forgets older messages.
Hope this is clear. I’m planning to replicate your situation but need those logs to make sure I’ve done it right.
sure, can you give me a few pointers to achieve this please? FTP / SSH? Which file(s) am I locating?
thanks grahamh
To get a better understanding of the problem you are experiencing we need more information from you. The best way to get this information is for you to upload logs that demonstrate your problem. You can learn more about how to submit a useful support request here.
Depending on the used skin you have to set the settings-level to standard or higher, in summary:
-
enable debug logging at settings->system->logging
-
reboot the OSMC device
-
reproduce the issue
-
upload the log set either using the
Log Uploadermethod within the My OSMC menu in the GUI or thesshmethod invoking commandgrab-logs -A -
publish the provided URL from the log set upload, here
Thanks for your understanding. We hope that we can help you get up and running again shortly.
OSMC skin screenshot:
Details regarding how to access the command line interface can be found here on our Wiki: Accessing the command line - General - OSMC
Many thanks, 
Good evening
Right, the logs from the GUI as it was when I got home from work are here: https://paste.osmc.tv/dozubuhigi
I then left the box connected to the HDMI 3 with debug logging enabled and rebooted it. After leaving it for a bit I uploaded the logs via SSH to here: https://paste.osmc.tv/ogavijidet
Fingers crossed this reveals something.
Cheers
Ben
I have used your EDID to simulate your TV and I just can’t reproduce your black screens. If you are up for some more testing, and are happy with ssh now, could you try the following:
- Re-boot, verify you are still not getting any picture then type on the commandline
sudo systemctl restart mediacenter. What happens? - What happens if you just unplug the HDMI cable and plug it in again?
- If no luck, type
cat /sys/class/amhdmitx/amhdmitx0/configand post the output here. Then typeecho 8bitnow | sudo tee /sys/class/amhdmitx/amhdmitx0/attr. What happens then?
Edit: Maybe it’s simpler than that. Can you try updating again?
sudo apt-get update && sudo apt-get dist-upgrade
Post any error messages here.
WIll do grahamh, and it is appreciated the suggestions to see if we can get to the bottom of this.
Just my thought on my initial post on this topic; the update may not have failed, it could simply have been at that stage I didnt know about the fact that this Vero and TV was booting the black screen for an extended period before the GUI comes up.
This is the result of running these commands…
Linux osmclounge 3.14.29-134-osmc #1 SMP Mon Dec 31 00:16:36 UTC 2018 aarch64
The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.
Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Feb 2 09:08:41 2019 from 192.168.1.99
osmc@osmclounge:~$ sudo apt-get update && apt-get dist-upgrade
Get:1 http://security.debian.org stretch/updates InRelease [94.3 kB]
Ign:3 Index of /debian stretch InRelease
Get:4 Index of /debian stretch-updates InRelease [91.0 kB]
Hit:5 Index of /debian stretch Release
Get:6 http://security.debian.org stretch/updates/main arm64 Packages [455 kB]
Get:7 http://security.debian.org stretch/updates/main armhf Packages [460 kB]
Hit:2 Index of /osmc/osmc/apt stretch InRelease
Fetched 1101 kB in 5s (196 kB/s)
Reading package lists… Done
E: Could not open lock file /var/lib/dpkg/lock - open (13: Permission denied)
E: Unable to lock the administration directory (/var/lib/dpkg/), are you root?
osmc@osmclounge:~$
I rebooted and still the black screen. It appears that I cant SSH whilst it is like this (or at least I cant SSH yet). I have left it 5 minutes or so on the black scrren before trying to SSH. I can, however, get a reply to ping.
No change, just the black screen and the TV message that is will redirect the remote down the HDMi.
I will have to wait for the GUI to come back up it looks like before I can SSH to get these results. I will post them either later on or tomorrow depending on when the GUI comes up.
Many thanks
You missed one “sudo”.
1 Like
Many thanks ooZee. I will try again when the Vero GUI comes up and I get SSH access back. Just tried it now and the GUI and SSH access are still not back up.
SSH should be coming up even when the GUI is not up.
Sam
The more I hear, the more I think only a re-install will sort you out. Try the December image.
I must have tried it for about 15 minutes after restarting it, but no SSH access. I guess it depends on where in the boot process it is hanging as to whether the SSH access is available.
I did a reload of the os about 10 days ago and it made no difference; this seems to be a conflict between the Vero and Toshiba TV as it doesnt happen on my other TV and my other Vero box does exactly the same on this Toshiba TV.
Just a shower thought have you tried wiping all the settings on the Toshiba ? ( Factory resetting it ) ?