Please paste the output of uname -a
sudo uname -a
Linux Osmc_Vero_4K 3.14.29-119-osmc #1 SMP Wed Sep 5 19:09:21 UTC 2018 aarch64 GNU/Linux
Appears identical to that shown after my first update (3rd post in the thread)
Linux Osmc_Vero_4K 3.14.29-119-osmc #1 SMP Wed Sep 5 19:09:21 UTC 2018 aarch64 GNU/Linux
I repeated the update process twice in case of error.
Thanks
That’s an old kernel – and not the latest
Try sudo apt-get install --reinstall vero364-image-3.14.29-126-osmc && reboot
Thanks
Sam
Thanks Sam
uname is now returning:
Linux Osmc_Vero_4K 3.14.29-126-osmc #1 SMP Wed Oct 31 17:34:23 UTC 2018 aarch64 GNU/Linux
A brief test of the colourspace on the 8bit files looks good.
I’ll perform some YouTube testing and let you know the results.
Many thanks for your assistance.
Hi,
After much playback of h265 files without issue, I’ve just experienced the ‘input not supported’ error multiple times.
I started playback, watched a few seconds, then the monitor displayed its error, whilst audio continued (via bluetooth).
Power cycling the monitor restored the image, then after a few more seconds the error reappeared.
Stopping the file playback, repeating the monitor power cycle, then starting playback, resulted in the same error.
Switching to a different h265 file gave the same results.
Rebooting the vero appears to have resolved things.
Points to note:
The vero had been in ‘suspend’ mode previously, and had had an external usb hdd connected. As the drive later entered power saving mode, I switched it off when the vero was suspended, and didn’t power it back on before bringing the vero out of suspension.
sudo uname -a
Linux Osmc_Vero_4K 3.14.29-126-osmc #1 SMP Wed Oct 31 17:34:23 UTC 2018 aarch64 GNU/Linux
Thanks
Can you post the output of cat /sys/class/amhdmitx/amhdmitx0/config when you get a blankscreen, please?
Absolutely. It’s very hard to replicate (before last night, last instance was around November 8th), but I’ll run the command if it occurs again.
Thanks
Hi,
The ‘input not supported’ issue just reoccurred (maybe of note, this was immediately after bringing the vero out of Suspend and beginning h265 playback, albeit with the external hdd powered on this time)
osmc@Osmc_Vero_4K:~$ cat /sys/class/amhdmitx/amhdmitx0/configcur_VIC: 16
VIC: 16 1920x1080p60hz
Colour depth: 10-bit
Colourspace: YUV444
Colour range: limited
EOTF: SDR
YCC colour range: limited
PLL clock: 0xc000027b, Vid clock div 0x000b0000
audio config: on
3D config: offSame command immediately after reboot, playing back the same file (without the input error)
osmc@Osmc_Vero_4K:~$ cat /sys/class/amhdmitx/amhdmitx0/configcur_VIC: 16
VIC: 16 1920x1080p60hz
Colour depth: 8-bit
Colourspace: YUV444
Colour range: limited
EOTF: SDR
YCC colour range: limited
PLL clock: 0xc000027b, Vid clock div 0x000a339c
audio config: on
3D config: off
Notably the colour depth is reported as 8 bit (10bit when in error state), and Vid clock div is different
Spot on, thanks!
1 Like
@retroresolution Can you try the latest update?
For your memory:
- Login via the command line
- Edit the file
/etc/apt/sources.list - Add the following line:
deb http://apt.osmc.tv stretch-devel main - Run the following commands to update:
sudo apt-get update && sudo apt-get dist-upgrade && reboot - Your system should have have received the update.
I also recommend you edit /etc/apt/sources.list again and remove the line that you added after updating. This will return you to the normal update channel.
Cheers
Sam
Thanks @sam_nazarko , @grahamh
I’ve performed the update.
For the record, uname -a returns:
Linux Osmc_Vero_4K 3.14.29-132-osmc #1 SMP Mon Nov 26 00:05:01 UTC 2018 aarch64 GNU/Linux
I’ll let you know how I fare with this version.
Many thanks.
That’s the latest and greatest.
1 Like
Hi Sam,
Firstly, let me wish you a Merry Christmas, and thank you for all your support this year (both Vero4K and otherwise related).
Nothing urgent, just thought you’d like to know I’ve been experiencing stuttering on 720 and 1080p playback of files on both encrypted and unencrypted partitions.
As is normal, here’s chapter and verse…
I’ve not been using the Vero that much recently in the usual manner (directly playing files from a locally connected usb hdd, and a locally connected monitor), plus illness has left me ambivalent regarding consuming tv shows and films.
I recently installed Samba on the Vero, and had been using a Raspberry Pi 2 with an ALFA Network AWUS051NH V2 (Version 2) 2.4/ 5GHz Dual Band USB WiFi unit, with Detachable RP-SMA Antenna and Ralink RT3572 Chipset as the playback device.
I experienced frequent pauses / freezes, which may, or may not, be due to wifi issues (using 2.4ghz as I’ve at the time I had Kodi 17.3 installed, and was unable to switch to 5ghz. I’ve since installed the latest Osmc on the Pi 2, but performed no further testing, as I started experiencing random, severe stuttering on local playback for short periods on a range of x264 files. Some media seems bullet proof, others randomly falters.
As the drive holding the media is relatively new, and encrypted at partition level, I spent several days eliminating hardware failure (my drives are all mirrored, with identical hardware), via a full low level drive scan, and a full bitwise comparison of the files on primary and backup disks.
Tonight I was watching h265 media from an unencrypted drive, from a different manufacturer, and saw the exact same issue (albeit after several hours of flawless playback).
Top showed no unexpectedly high CPU usage.
I’m wondering if Samba could have caused this, even when no external sources are accessing Vero’s shares.
Should I update to the latest build (currently I’m using
Linux Osmc_Vero_4K 3.14.29-132-osmc #1 SMP Mon Nov 26 00:05:01 UTC 2018 aarch64 GNU/Linux)?
Merry Christmas,
All the best
RR
Hi RR,
Good to hear from you
This might be one we need to pick apart as two different issues, as it seems you have issues with Raspberry Pi too.
If you can, I’d run some iperf or speed tests to check the network.
When you say you can’t connect to 5Ghz, can you elaborate?
You may need to use separate SSIDs, as Vero will pick the strongest signal (as per 802.11 spec); but 5Ghz may have a weaker signal but higher throughput.
Re. playback issue from USB: can you reproduce this; or is it rare?
Cheers
Sam
Hi Sam,
Thanks for the reply, good to hear from you too.
I’m not concerned with the wifi issues - I’m confident that I can resolve all of these once the core system is achieving smooth playback once again, especially now I’ve ditched the custom Kodi-installed-on-Raspbian build, with manually implemented wifi, for a clean new Osmc image. For the record, the source media is from the same hard drives as used for local playback - just streamed.
Unfortunately the local usb hdd playback stuttering is only semi-reproducible, a.k.a the worst type of problem for any developer.
The system has exhibited the problem with the same drives on more than one occassion, and there are entire seasons of specific shows which seem immune, whereas others are prone to the issue.
I’ve not found a method to reproduce the stuttering, even using the same file. Time appears to be a factor, given that the system generally appears stable for several hours before the problem arises. Whilst it’s suggestive of a memory leak (my cheap Samsung tablet does this constantly with YouTube), nothing in Top suggested this was the case, however I did only investigate with bmon, Top, etc, when investigating the issue on wifi.
I could install dstat, however I’m warying of adding further variables into the mix.
Many thanks,
RR
When you get a stutter, you could try uploading logs quickly as it may reveal something
Sam
Hi Sam,
Hoping you’ve had a wonderful Christmas Day, if that’s your thing (otherwise, just a great day in general).
I’ve uploaded logs to:
Https://paste.osmc.tv/mipenilice
This is immediately after a c. 5 second stutter upon resuming from a brief pause (then skipping back using the left remote key a couple of times) on a 45 minute tv show.
Format is x264
Setup: usb attached hard drive, partition encrypted. All hardware connections are local (vero to hdmi monitor. Hdd to vero usb).
Please don’t even consider investigation until after the holidays!
Best regards,
RR
Forgot to defrost…
Readrate 1450000 is too low with 1480125 required
It looks like there’s a lack of throughput here.
Forget if I asked, but is CPU use high because of real-time decryption?
Sam
1 Like
Hi Sam,
I’d say it’s unlikely. Top never shows veracrypt using much CPU, and I’ve been using encrypted files on multiple drives for months (all ntfs).
Top shows veracrypyt (2 processes) using 0.0% / 0.0% cpu and 0.0 / 0.1% ram during playback
The files I’ve noticed the stuttering on recently are both x264 and h265, and low bandwidth compared to some movies I’ve got.
The final nail in that coffin is that it happened on a totally standard unencrypted drive (which finally prompted me to post about it).
Kodi is using between 22 and 35% cpu, and 22MB ram, during playback.
(All above info taken during playback ofx264 media file from veracrypted partition, from one of the series apparently prone to stuttering).
Forgot to defrost? Your Christmas Turkey (or equivalent)? Nightmare.