Like I said, I never changed anything regarding sshd.
That would mean other people can get this as well, giving the only option a reinstall, without even trying … is kinda harsh.
osmc@vero4k:~$ sudo apt-get autoremove
Reading package lists... Done
Building dependency tree... Done
Reading state information... Done
The following packages will be REMOVED:
ssh-app-osmc
0 upgraded, 0 newly installed, 1 to remove and 0 not upgraded.
1 not fully installed or removed.
After this operation, 38.9 kB disk space will be freed.
Do you want to continue? [Y/n] n
Abort.
Can you upload some logs so I can see if your system is fully up to date?
Sam
I pulled an old harmony remote out and programed it as a KLS, VDR 1.6, PVR which is compatible with the RC5 profile built into OSMC labeled “kls-1.6-lircd”. Even though Harmony remotes tend to be problematic with default settings and how much they repeat, this performed without issue. So much so that I had to reduce the repeat delay to under 100ms before it started repeating. Since you already said you tried changing the repeat delay all the way up to two full seconds with no effect (you just did ir-keytable -D 2000 i’m assuming then just ran ir-keytable by itself to confirm), then perhaps this custom conf of yours is problematic, but I wouldn’t know what to suggest with that.
Maybe just carry on and remove ssh then reinstall it with My OSMC.
I noticed that whenever I SSH to my vero, there’s an error message during login:
passwd: Option unknown option -y
passwd: Use -help for summary.
The culprit seems to be the /etc/profile.d/105-check-ssh-password.sh script, which tries to identify the password hashing algorithm from the shadow file.
I set the password for my osmc user using passwd on the command line:
root@vero:~# passwd osmc
New password:
Retype new password:
passwd: password updated successfully
[...]
root@vero:~# getent shadow osmc
osmc:$y$<....>
Apparently the script is not expecting the “y” here and that does not seem to be recognized as a valid option to openssl passwd ....
It looks like that script needs some fine-tuning.
Sebastian
1 Like
sudo apt-get install --reinstall ssh-app-osmc
This worked perfectly, ssh still works even after a reboot and no error anymore.
Thanks for the report.
Did you set the password after upgrading to Bullseye?
Sam
Yes, I did.
Sebastian
The hashing algorithm for passwords has changed on Bullseye
Looks like we will need to re-work the script.
Sam
A fix is on it’s way.
I’ve pushed these changes.
I can confirm it works now (both ways - no error is shown regarding the “y” and the intended warning is printed if the password is the default).
Sebastian
1 Like
Thanks for confirming.
1 Like
Dear OSMC-Team,
since last week I have issues with all vc1-coded videos on Vero 4K+ with latest test builds (Bullseye):
- stuttering video
- audio/video synchronicity getting worse, the longer a video is being played
Longpress-i shows:
Videodecoder: am-vc1 (HW)
Deinterlace: hardware
CPU-Usage: 0 to ~ 26 %
Think we already had such issues last year on [TESTING] Kodi v19 builds for Vero 4K/4K+, too.
Do you need logs?
Thanx.
Yes, it’s important to see logs.
You’ve mentioned you’re getting issues with all VC-1 videos. The log tells me that you’re playing and ISO. Maybe it’s ISO related? Do you have VC-1 videos in other containers (e.g. mkv)? And does that happen there, too?
I’m also seeing jerky playback on VC-1, including on mkv files.