I just finished watching a X264 film, from a usb memory device. At the end of the file the screen showed a black background with a blue circle containing ‘100’.
The system was completely unresponsive, however I was able to ssh onto the vero and issue a sudo reboot.
The device eventually began showing a slew of ‘stopped …’ messages, and got as far as ‘reached target shutdown’, then stopped. For c. Three minutes, at which point the screen blanked, then reappeared with the same information.
I eventially had to power cycle the unit.
After the reboot i replayed the last 10 seconds of the film. At the end it completed, and began autoplaying the next file.
I’d provide logs, but health issues are taking precedent at the moment.
Edit: is there any value in switching on ‘enable event logging’ all the time, or are these types of issues only diagnosable with full debug logging enabled?
Err… On the Vero, I don’t know. I’m guessing we copy to /boot still, despite it not being external medium.
I’ve had some issues with the new kernel, but it’s experimental for a reason. Please check the improvements thread in about half an hour. I’ll update it with some new instructions
Hello, sorry for maybe asking the trivial or even hijacking the thread, but this topic is closest to my issue and so decided to post it here.
I have a Sony TV which is calibrated to Rec.709. The calibration was done on a PC, with RGB full range output (0-255). This TV accepts full range YCbCr 4:4:4 data, and there’s no setting on the set to disable this. Instead in the EDID information it advertises this feature as “YCC quantization range… Selectable (via AVI YQ)”. If I’m not mistaken, this means that the video stream can instruct the TV to use either limited (mapping 16-235 to 0-255) or full (0-255) range.
Although the TV is HDR ready, I’m not using it in 10-bit HDR mode since I mostly watch 720p and 1080p SDR videos.
Now, on the PC (with Kodi DSPlayer version) it was easy to make everything work - I used full-range RGB mode on the GPU and instructed the renderer (madVR) to map any video data to full range properly. So both limited range (16-235 --> 0-255) and full range (0-255 --> 0-255) video looked perfect, even HDR videos were properly rendered.
On Vero 4k+, I’m struggling to set everything up. If I use YCbCr mode (Force RGB disabled), there’s no mapping, so normal (limited range) movies look washed out. This is confirmed by a black/white clipping test video, having all bars from 1-16 and 235-254 flashing. 16 is gray, 235 is light gray.
If I enable Force RGB, the Kodi GUI renders correctly, but videos play the same.
Is there anything I’m missing here? Is there a way to force mapping of 16-235 to 0-255 on Vero 4k+? Or should I re-calibrate my TV to 16-235, running the risk of losing detail and some color range?
HDR ready… Not HD ready His TV is capable of HDR, but he’s mostly watching SDR content, so he calibrated it for that use case: SDR bt709. Correct, @norbertlang?
In the meantime I also found out that the HDMI Dynamic Range setting that I’m desperately missing from my set is gone after an update to Android 7. I’m not the only one complaining about it, yet I don’t know how to overcome this problem with my set.
Not yet, and this is exactly what I’d like to find out, if it’s worth a try.
Honestly, I’m not much of a Linux guy myself, and I wouldn’t run the risk of somehow ruining or messing up my otherwise beloved Vero if there’s no improvement expected.
If the experts here tell me that it can help, I’ll try of course.
If you have issues with limited range, this should fix it, but I understand if you are nervous about getting into linux. Loads of people in here will help you with that, though.
If all goes well, the improvements will be in the next general upgrade at the end of the month, so if you’d rather wait…
Thanks @grahamh, I’ve updated to the new kernel. Unfortunately things are the same.
I disabled HDR autoswitching, also verified I have the new kernel (3.14.29-129).
Checked with the black/white clipping test patterns from AVS HD 709. On my side, it’s still 0 = black, 255 = white, instead of 16 and 235.
Did you install the kernel linked above or update from the stretch-devel repo? I made a mistake yesterday - the latest video tweaks are not yet in stretch-devel. The kernel you can get by downloading with wget is numbered the same as the current release (119, not 129) but will have a compile date in the last few days (type uname -a to confirm).
This kernel was developed after a user submitted samples of rips which are limited range but tagged as full-range in the sei metadata. We have made vero default to limited range since that is what most media should be. I can’t think of a way to detect if media has been incorrectly tagged, though.
Presumably the test pattern you are using is tagged as limited range?
Sorry, I meant 119, not 129. Yepp, kernel I have was compiled on 12th Sept:
Linux osmc 3.14.29-119-osmc #1 SMP Wed Sep 12 21:28:17 UTC 2018 aarch64 GNU/Linux
I’m pretty sure it’s not the media that’s tagged incorrectly, as most media files I have behave similarly. Also I have several test clips from different sources (AVS HD, LightSpace CMS) and all of them are the same.
I’m almost sure the culprit is my Sony TV. While on Android 6, it had a setting to change the dynamic range per HDMI input. Setting that to Limited forced the TV to interpret the range correctly. Now, in the “updated” version, this setting is gone. In the FW release note from Sony there’s a blurry reference to a fix for “HDMI Dynamic range malfunction”. Probably this is why they removed the dynamic range setting, and consequently the TV now follows HDMI 1.4 and can be instructed to use full or limited range. At least this is what it advertises in its EDID.
@grahamh, is there a way for me to somehow debug (or even forcefully adjust from maybe my PC) HDMI infoframes, specifically the AVI YQ field content? AFAIK, the display should interpret video data as limited range if AVI YQ=0 and full range if AVI YQ=1. This would allow us to understand the root cause (wrong infoframe data or lack of capability of my TV to interpret and act on this field properly).
If I’m completely off with my infoframe ideas (sorry, I’m a newbie on this), the only other workaround I can imagine is a setting in Kodi / OSMC to force output in full range, using a mapping for limited range media to adjust 16-235 to 0-255. Again, this was easy with my nVidia / madVR HTPC, but not sure if possible with the Vero.
Get a commandline going and cd /sys/class/amhdmitx/amhdmitx0
While playing media, type cat config This should tell you what vero is outputting to the AVI InfoFrame as the SDR range (Q) and HDR range (YQ).
type echo fullnow | sudo tee attr to force SDR range to full, echo limitnow | sudo tee attr to signal limited. See what happens. Those settings stick until a reboot, but you can reset them with echo now | sudo tee attr. There is no implementation for changing YQ manually. AFAIK it should never be full-range with PQ encoding.
To verify the input (media) range, cat /sys/video/frame_format.
FWIW, my Panasonic is fixed at limited range for YUV input, so playing with those settings has no effect. If I send RGB (echo rgblimitnow | sudo tee attr for example) the Panny will switch to limited or full.
Thanks a lot, tested them all, even the RGB modes. None of these made any difference to how the TV interprets the dynamic range. I could see the TV getting different inputs though (kinda’ changing modes, going to black screen and coming back a moment later), but the range remained the same.
The video is correctly flagged as limited range. Without attr changes, according to cat config OSMC properly interprets it and sends Colour range: limited to the display.
My last suspect is my Marantz AVR, which might interfere with the infoframe content. I’ll now do a test with my AVR removed from the HDMI chain, but it takes some time power off everything and redo the cabling.
PQ colour range reports the YQ bits. But if the video is not HDR (and EOTF: SDR implies it’s not) that’s irrelevant. Or should be. Yr TV should be reacting to the Q bits for SDR and the YQ bits for HDR. AFAIK.
Ok, now I’m confused. I was referring to the YQ bit going to the TV via HDMI.
By editing attr, did I or didn’t I apply changes to the video infoframe going to my TV?
Honestly, I have doubts that my TV completely mis-advertises its capabilities. I want to make sure that we’re indeed testing a different YQ bit setting with these changes.
FYI, this is config with fullnow in attr:
cur_VIC: 32
VIC: 32 1920x1080p24hz
Colour depth: 8-bit
Colourspace: YUV444
Colour range: full
EOTF: SDR
PQ colour range: limited
audio config: on
3D config: off
Is Vero now sending YQ=1 in the HDMI infoframe? And in the previous version of config, is it flagging it with YQ=0?
If so, we can conclude the Sony TV is not working as it should. If not, there’s maybe room for improvement in OSMC.
His TV is capable of HDR, but he’s mostly watching SDR content, so he calibrated it for that use case: SDR bt709. Correct,