I now find a way to switch a Samsung D series to HDMI3 and back to TV tuner with cec-client:
#switch to HDMI3
echo "tx 4F:82:30:00" | cec-client RPI -s -d 1#switch back to TV
echo "tx 40:9d:00:00" | cec-client RPI -s -d 1It is running on a Raspi 2.
I want to switch the Samsung TV to HDMI3 and if necessary back to TV tuner (previous active source). This works with cec-ctl, but I tried it hours with cec-client and gave up.
Because of the WLAN invalid-key-problem I downgraded to LE 9.2.8
Unfortunately there is no cec-ctl included. Is it possible to install this from any add-on or repository? Or is it impossible to work with the 4.9 kernel?
I have a script which works fine with cec-ctl on LE 11. LE 9 includes cec-client, but I wasn't able to get the same result with it.
I copied the cec-ctl from version 11 into the 9, but it doesn't run because of the wrong glibc version.
When I was at home visiting my parents I checked the wifi connection via OSD menu. I tried to connect to the router and got "invalid key" answer. Tried it again several times and suddenly it works. A few hours later the Raspi was again unreachable...
As I am on LE 11.0.1 I believe I have the infamous invalid-key-bug: https://github.com/LibreELEC/LibreELEC.tv/issues/7166
Is there anything I can do to fix this?
In /storage/.cache/connman/wifi_08beac0ef069_4d442d3231323739_managed_psk there is a valid settings file for the router.
Right now the Fritzbox shows a signal strength of -65dBm which should be good.
Signalstärke-65dBm
max. mögliche Datenrate (maximum possible speed)144 / 144 Mbit/s
aktuelle Datenrate (current speed) 61 / 117 Mbit/s
WLAN-Standard WLAN-b+g+n / Wi-Fi 4
Frequenzband 2,4 GHz
Kanalbandbreite 20 MHz
Streams2 x 2
The stick is advertised with 802.11b/g/n and a maximum speed of 300 Mbit/s when connected to a 802.11n WLAN. Therefore the 144 Mbits/s makes me wonder. The rtl8xxxu in kernel 6.1.19 seems to be the right driver.
The Fritzbox works on autochannel mode (currently channel 11) and shows no noise. There is no other WLAN net on channel 11 and there are no other WLAN devices in the house. Of course I don't know how it looks when the Raspi is offline, but I doubt that the conditions differ much on other days.
While I am writing this the connection suddenly broke and the Fritzbox is no longer connected to any WLAN device...
I have a Raspi 2 with an Edimax EW-7612UAN V2 at my parent's home. There is a crontab which makes an automatic reboot every morning at 6 a.m.
I have a VPN access to the Fritzbox router at my parents home and can get access to the Raspi with ssh. But this works only in 1 from 20 days. The other days the Fritzbox shows that no device is connected to its network. Today is one of the rare days the Raspi is connected an I have access.
What could be the problem?
iw wlan0 get power_savealready shows
Power save: offI also have in /storage/.cache/libreelec/network_wait
WAIT_NETWORK="true"
WAIT_NETWORK_TIME="10"My suspect is that this only a wait before starting Kodi. Maybe the problem is that loading the driver and initializing the stick with its firmware is not ready when LibreElec starts the network. I don't know how this works - should a network always start once a device becomes available? Or could there be a timing problem?
I installed a Rasperry Pi 2 in the home of my old parents, connected to a Samsung LCD TV (D-series). They don't use the Pi yet - I am still working to convience them that it is better than their old VHS recorder...
Every few weeks I visit them, and when I turn the TV to the Pi input, I recognize that the picture is too dark with low contrast. But it is still not as dark as it would be with active power saving mode after some time of inactivity. The picture doesn't get bright again when I press keys. The device is not frozen, the OSD still reacts. The only thing that helps to bring back the normal bright picture is to reboot the Pi. Is this a known problem? How could I automatically make a nightly reboot via cronjob?
Thank you, that was very helpful. I changed my file, let my mother press the yellow key and can confirm that it works.
On my own Samsung TV (a newer genration model) the yellow key is identified as 'remote' and 'yellow'. Maybe a different CEC protocol.
Strange is, that the red key on my mothers TV remote does not work as expected with key id 251 - kodi still trys to start PVR.
Anyway, I just needed one key to call my script.
On a Raspi 2 with LE 10.0.2 I created the file yellow.xml in .kodi/userdata/keymaps:
<keymap>
<global>
<remote>
<yellow>RunScript(/storage/num_input.py)</yellow>
</remote>
</global>
</keymap>The file storage/num_input.py is present and executable.
When I press the yellow key on my Samsung TV remote, kodi still switches to 'Music', which is the default action for the yello button.
On a Raspi 4 (LE 10.0.2) and on an Odroid N2+ (CoreElec) this works with the same two files as expected. Is there anything that can prevent kodi from respecting user defined keys?
Currently I am not on the location whre the Raspi 2 is working (my parents home). I am logged in via VPN and ssh. Is there a way I can simulate a certain CEC-keypress on command line? It seems that kodi-send can only send actions to kodi, not the keypress which should trigger the action.
Strange. I installed LE again from the same 10.0.2 image. CEC is working out of the box, although I can't find any difference in the configuration.
I know for sure that it worked a few weeks ago, already with a LE 10 version Since then I had the Raspi 4 disconnected and switched off for a few weeks. Now I wanted to test it again. The micro to HDMI cable (no adapter) is connected to the HDMI port near to the USB-C connection. I guess this is HDMI0 while the other one is HDMI1? If I remember right, CEC was only working on HDMI0.
The other side of the HDMI cable is connected to my Yamaha AVR RX-V677. LibreELEC version is 10.0.2
After booting, I get the message that it is connected to Pulse Eight Adapter. But no key on my tV remote control is working. Same happens when I connect the Raspi directly to a HDMI port of my Samsung TV.
cec-client can't find a connection:
LibreELEC:~ # cec-client
No device type given. Using 'recording device'
CEC Parser created - libCEC version 4.0.7
no serial port given. trying autodetect:
path: /dev/cec0
com port: Linux
opening a connection to the CEC adapter...
DEBUG: [ 64] Broadcast (F): osd name set to 'Broadcast'
DEBUG: [ 64] CLinuxCECAdapterCommunication::Open - m_fd=3 bStartListening=1
ERROR: [ 64] CLinuxCECAdapterCommunication::Open - ioctl CEC_S_MODE failed - errno=16
DEBUG: [ 64] CLinuxCECAdapterCommunication::Close - m_fd=3
ERROR: [ 64] could not open a connection (try 1)
DEBUG: [ 64] CLinuxCECAdapterCommunication::Close - m_fd=-1
DEBUG: [ 1065] CLinuxCECAdapterCommunication::Open - m_fd=3 bStartListening=1
ERROR: [ 1065] CLinuxCECAdapterCommunication::Open - ioctl CEC_S_MODE failed - errno=16
DEBUG: [ 1065] CLinuxCECAdapterCommunication::Close - m_fd=3
ERROR: [ 1065] could not open a connection (try 2)I checked the settings of the CEC Adapter (Version libCEC 4.0.7 - firmware v0). What makes me wonder: There is a setting for the HDMI port number. The lowest number one can choose is 1. Shouldn't it be zero for HDMI 0?
I doubt that my TV respects the AVI infoframe and automatically changes the colour range. If this was the case, I shouldn't get grey colours instead of black or even washed out colours.
My TV is set to limited colour range. I don't want to change this because it is connected to an AVR with other devices which are all sending limited RGB (e.g. the Bluray player).
My HTPC has an nvidia card.The nvidia driver is configured to Full RGB, which should be correct according to https://kodi.wiki/view/Video_levels_and_color_space
In Kodi 19.4 I have set "Use limited colour range (16-235)" to 'on'. The picture both from Kodi menu and video files is fine.
A Rasperry Pi 2 is set to hdmi_pixel_encoding=1 RGB limited (16-235). I need to set "Use limited colour range (16-235)" to 'off'. Otherwise the dark parts of the skin look grey.
Should I set hdmi_pixel_encoding instead to 'to Full RGB' and activate "Use limited colour range (16-235)" ?
My third machine is a Rasperry Pi 4. The parameter hdmi_pixel_encoding in config.txt seems to effect nothing, and from what I have read the Pi4 is always on Limited RGB and this can't be changed. I also need to set "Use limited colour range (16-235)" in kodi to 'off', otherwise the dark parts of the skin look grey. Is there anything else I should do?
Both Raspis are running LibreElec 10 with Kodi 19.4
On a CoreElec system (Odroid N2+) I even don't have the "Use limited colour range (16-235)" in their Kodi 19 expert setting. Did they remove this by patching do avoid user confusion? The picture looks like my other 3 machines with my described settings.
What does "Use limited colour range (16-235)" effect? Is it only for the Kodi skin or has it an effect on movie playback?
My TV is a Samsung UE40F6500 and I believe that it's edid may be wrong, because without any hdmi_pixel_encoding setting the Raspi 2 always had washed out colours.
I used the LibreELEC.USB-SD.Creator.Linux-64bit.bin in the past without problems (Ubuntu 21.10. 64 bit). Today I wanted to create a new sd card and suddenly the tool seems to be broken. Selecting a version is not possible. I can select an image file, but there is another problem:
One of my SATA ports on the motherboard is configured as hotplug to allow using an e-SATA drive. The kernel reserves /dev/sdd for it, even when no drive is connected. The tool shows /dev/sdd with 0 MB and no partitions as only writable device and it is not possible to select another drive like the sd card which is connected as sdf.
I
It seems there is a major issue with the creator and I suggest that it is removed from https://libreelec.tv/downloads/ as long as this is not investigated and fixed.
It is the latest Kernel 5.8.0-50-generic which makes the problem. It includes a first Patch from December, which makes things even worse for Kodi. A second Patch from 01.02., which notes the problem with Kodi and fixes it, didn't make it into the 5.8 Ubuntu-Kernel.
I upgraded the Server to Ubuntu 21.04 with Kernel 5.11 and the problem disappeared.
I have read several similar reports since February. It seems to be a kernel regression. See also here.
My suspect is that Ubuntu has backported this to my kernel 5.8.0-49-generic which was installed yesterday.
The question is why does the problem not occur when Kodi is running on a Ubuntu machine?
I have exactly the same experience since yesterday. Nothing has changed, my NFS server is Ubuntu 20.10.
Yesterday I suddenly had a lot of green artefacts when playing any movie. I use NFS since years without problems. The NFS server is my Ubuntu 20.10 Desktop machine.
I switched to another client (Nvidia-based HTPC with Ubuntu 20.04.), also using NFS, and there were no problems with Kodi playback.
Today I tried the latest 10.0 nightly build and have the same experience. Playing via SMB works, playing via NFS only with artefacts. I attach the log.
If it were a network or server problem I would assume that this should also effect other clients. So I have no idea what is going on there.