I’ve updated today to the June '22 update on my vero 4k+, updating from the March '22 update. Since the update, the key repeat on my flirc based remote and qwerty keyboard are both near unusable.
On the keyboard, I can usually manage a single keypress. On the flirc with my Logitech remote, it’s very difficult to get a single keypress. On both the keyboard and remote, holding a key for a short time (less than a second) results in many presses.
I’ve looked around menus and settings, can’t see any way to alter the key repeat delay or frequency.
This was not an issue prior to this update, and the cliff behaves as expected on another system.
Looks like you updated to an experimental version of OSMC. Some logs would be useful. We haven’t released a June update yet (still May, and number of changes still pending).
I don’t know how I’ve updated to experimental. I don’t recall doing anything or intentionally moving to debian previously, although it certainly is something I would consider doing (all my other systems are debian after all).
Rather I found a /etc/udev/rules.d/70-input-repeat.rules file on the system, possibly from changing key repeat configuration in the past. After removing this and rebooting as suggested by @darwindesign, it’s back to working properly.
There was an issue a few years back with the key repeat delay and there is a post on this forum that outlined a fix that one could apply themselves prior to it being included in the next update. If that file exists on any OSMC system it is because a user added it, likely after reading that post. I have since edited that post. I think Sam is generally opposed to having any update remove any user generated files which is why I’m guessing that we are not automatically removing this file.
Update went fine after reconfiguring programs to use latest version of Pyhton. Does this mean I can now safely delete old 2.x and 3.x version of Python?
Yes – because we don’t know what was added by the user and should be kept vs what we suggested to add. If a user has introduced a new file, then it’s ‘theirs’ and should be kept intact on the system.
thanks, 24p VC-1 is fixed now. Took a couple of steps for me to get the update though. At first no updates available, so I went to my sources.list.d folder and found the osmc-devel.list file had been deleted. No problem I thought, just recreate it per the instructions at the top of this thread - but then, still got the message that no updates are available. I checked my other Vero on the Bullseye test and noticed that its osmc-devel.list file had been modified to include a reference to bullseye-devel, which I guess had been done as part of the migration. So I then re-created the osmc-devel.list file for the first Vero with a refernce to bullseye instead of buster, and then the update worked. So might it be necessary to clarify in the first post that if a user has to re-create the osmc-devel.list file after hvaing migrated, then they will need to substitute bullseye at the relevant point?
As an aside, whenever there is an update that might affect VC-1 I go back and check the David Tennant Dr Who specials that are authored on bluray with a horrible 59.94 conversion from the 50i original. For a while now I’ve noticed the Vero has been really struggling to get any sensible field motion from these files. But as of the update just now, the motion is about as good as it could reasonably get. The occasional flash of image corruption noted at the link below is still present (this is unique to the Vero among my collection of mkv playback devices), but encouraging to see improvements in motion.
Hi, since update to Bullseye dev, two of my usb connected drives (exfat) are now non writable and have ownership showing as root.
The other two (NTFS) are fine - i.e. i can read and write, as opposed to just reading in the exfat case. Note, the ownership on the ntfs drives shows as osmc.
When I try and transfer files from my pc via ftp or samba, it fails.
When I try to sudo chown -R osmc:osmc /media/the_usb_drive, it fails with operation not permitted .
for this issue to force allowed resolutions to 1920x1080p 50 or 60 Hz