Posts by heitbaum

PR created - ntfs-3g_update: update to 2017.3.23AR.5 (Advanced Release) by heitbaum · Pull Request #4679 · LibreELEC/LibreELEC.tv · GitHub

thanks chewitt - Ill create a PR on le10 master - and have a look at paragon / 5.x too. Still busy getting my head around dbus.

Hi Team,

Suggesting we move to Version 2017.3.23AR.x as has been done in some mainline distributions.

E.g. Linked packages : ntfs-3g

Details are available at: NTFS-3G: Changelog for the Advanced Versions

Also noting some changes to behaviours of the caching in the driver (read the change log - NTFS-3G Safe Read/Write NTFS Driver Activity )

Specific patches are:

NTFS-3G Safe Read/Write NTFS Driver / ntfs-3g / Commit [39384c]

NTFS-3G Safe Read/Write NTFS Driver / ntfs-3g / Commit [5d6fd5]

If this is an suitable direction to move in, I’ll create a branch and put together a draft pull request.

Looks like a false alert. A USB device I had connected was causing the issues and random kernel crashes. Will continue to do further tests.

Different Kernel error back on - Linux LibreELEC 5.9.6 #1 SMP Wed Nov 11 06:51:19 UTC 2020 x86_64 GNU/Linux

http://ix.io/2DKC

ext4

Hi All,

As FYI only.(I'm rebuilding back to 5.9.6) against GitHub - heitbaum/LibreELEC.tv: Just enough OS for KODI and will advise. How it goes.

I just rebase lined GitHub - heitbaum/LibreELEC.tv at build_rudi + Kernel 5.9.7 against GitHub - heitbaum/LibreELEC.tv: Just enough OS for KODI

The compiled 5.9.7 with the rebase lined LibreELEC/Master "82a92d8d21762f2dc442b7794a6e02e3c5b74316" on the NUC6i5SYB is having kernel issues with: Workqueue: events azx_probe_work [snd_hda_intel]

Logs are at: http://ix.io/2DJH

Linux edbf6b369537 5.9.7 #1 SMP Tue Nov 10 13:49:34 UTC 2020 x86_64 x86_64 x86_64 GNU/Linux

Hi HiassofT

Some background on why I'm interested in following this through probably in order.

Note: I did laugh at the comment "CEC is pretty much voodoo to me...!" - so true.

I have the following AV equipment:

- Panasonic Viera TH-50PX600A

- Sony STR-DN1040

- Intel® NUC Kit NUC6i5SYH with "Intel NUC HDMI-CEC Adapter" (LibreElec Matrix)

- Apple TV 4K

- Cisco Webex Room Kit (experimenting / WfH)

- BrightSign CV-UHD2 / CV-HD2 (experimenting)

- Elgato 4K60 S+ / HD60 S (experimenting)

- Xbox 360 S (no CEC support)

I have the following home automation: Apple HomeKit, Apple HomePods, Hue Lighting, Homebridge (experimenting with openHAB).

The lighting works well - the rest ..., leave that unsaid.

I have had a love hate affair with the CEC in Kodi and AppleTV.

I was excited to purchase the HDMI-CEC adapter in 2018 (but that was short lived... - as below)

- The AppleTV sends a power on (but the Panasonic ignores it - CEC bug / non standard) - so the TV is always on. The Sony AMP changes itself to the AppleTV HDMI input.

- The Kodi generally misbehaves.

a) (Given my "Panasonic BUG" - that I would like to teach Kodi to send the following codes 80:44:40,80:45) as it already is successful in "power off" the Panasonic - thus I need to find the Panasonic Remote Control .

b) Kodi loves to own the CEC network and when the Sony AMP decides to power off - due to no Audio. Kodi will decide to Turn the AMP back on.

c) On swapping to AppleTV - Kodi does not honour the CEC commands always and switches back to Kodi. We then go and power Kodi off

d) When the remote control menu item <play> is pressed on the iPhone remote - the AMP does not switch on/nor does the input on the AMP change. The Apple TV using the Remote contol does power on the AMP and change the input (think Kodi should too.)

I had a look at: GitHub - joshjowen/script.json-cec: cec control for xbmc/kodi (to put some scripted workarounds in), but it does not allow arbitary CEC codes to be pushed. As Kodi owns the the CEC device entirely, I can't write a script to fix/workaround my issues. If I tell kodi to not enable CEC, then I can use cec-client to fix some of my issues.

The Sony AMP doesn't really automate very well either, though the codebase - GitHub - balert/Sony-STR-DN840-Remote-Python: Control your STR-DN840 receiver via the network interface. does work.

I have worked on a state machine diagram of what I want to happen so that this can be configured in to the home automation. But without the ability to issue CEC commands - I have reached the "unhappy - it does not work state."

Options as I see it:

1 - Use the kernel framework (same as #1 - but with no required code change)

2 - Have passthru access through Kodi to CEC (Changes to Kodi/script.json-cec/libcec)

3 - Disable Kodi CEC and hack with cec-client

4 - Develop functionality (addon) in Kodi - haven't really investigated - relies on #1 in some way

5 - Buy a dedicated CEC device

6 - Buy a new TV (and hope it works right - hi risk - what is works right)

7 - Give up --> - as I actually like my "pet project"

The actual Panasonic BUG - Power On does not work:

Panasonic Viera TH-50PX600A - Power On does not work · Issue #511 · Pulse-Eight/libcec · GitHub (not fixed in libcec - I don't see it being fixed by pulse8 anytime in the near future)

Need to send the following to make it work:

In my case: (Playback 2 —> TV)

80:44:40

80:45

In my enterprise office work environment we toy / flirt with "AV Control Systems" - and most of the time they are broken in their own special way. We have been successful with end-user devices like Cisco Webex hardware mostly with wireless screen sharing. But continue with the usual issues using HDMI extenders and the like. Recently been looking at Wyrestorm, rticorp.com, Cisco Video to simplify AV in the office and standards based AV/IP. I guess - what does this have to do with the /dev/cec0 discussion - I'm looking to have a working Home Automation system and the Kodi CEC configuration as-is doesn't allow for that. Overtime and if I can get my state-machine automation fully correct and working well - it might be that #4 could be done on either the built in CEC or as a addon.

Hope the above helps my case.

I do understand the support issue that you have mentioned though and would not at all propose to move from the userspace integration - it is good to have pulse8 looking after that codebase. My question to this - is that we are already supporting the Kernel interface for the other hardware (note: I don't disagree that linux-console is an additional product though.)

Regardless of the core teams decision to change the way for everyone, I would like to continue down the route of using cec-ctl for the moment, even if I have to maintain a separate branch/autstrat.sh commands. I would appreciate you pointing me in the right direction to add the build of linux-console into my branch though (so that it was buil;t properly.)

**Note: Without implementing my proposed systemd/udev changes - Kodi Generic would continue to use the /dev/ttyACM0 mechanism. The Kernel Framework is only ever activate if the modprobe and inputattach are run.

Thanks for your consideration.

Hi Hias,

100% agree with the get the supported approach, for which is the official libcec. As I understand it libcec is now supporting the Linux kernel framework (in passthrough) since April 2020 - RFC: Linux CEC framework adapter by Kwiboo · Pull Request #380 · Pulse-Eight/libcec · GitHub With the kernel driver (5. CEC Kernel Support — The Linux Kernel documentation) integrated with libcec now and allowing Kodi to continuing to exclusively use the libcec api. My proposed patch for which I note that Milhouse had eluded to in a recent Generic image #0717 - LibreELEC Testbuilds for x86_64 (Kodi 19.0) and in the below GIT branch.

The Milhouse branch where the CEC changes are for Generic is: Comparing LibreELEC:master...MilhouseVH:le10_libcec_next-drop-framework · LibreELEC/LibreELEC.tv · GitHub

The patch I'm proposing is:

Comparing LibreELEC:master...heitbaum:master · LibreELEC/LibreELEC.tv · GitHub

pulse8-cec: enable via Linux Framework · LibreELEC/LibreELEC.tv@79fb25d · GitHub

The patch includes all udev and systemd changes to make it work. I have included a binary compile in my patch just for the time being - but would propose incorporating linuxconsoletools-1.7.0.tar.bz2 and compiling the utils/inputattach

This still maintains the normal libcec operation within Kodi - but also integrates the remote control passthrough feature into the kernel’s remote control framework.

Hope this answers all the questions and that it can be incorporated in the mainstream Generic support.

Thanks

Rudi

Will recompile and retest.

-CONFIG_SERIO_SERPORT=y
+CONFIG_SERIO_SERPORT=m

-CONFIG_CEC_CORE=y
+CONFIG_CEC_CORE=m

+CONFIG_CEC_NOTIFIER=y
+CONFIG_MEDIA_CEC_SUPPORT=y

+CONFIG_USB_PULSE8_CEC=m

Hi HiassofT I believe I have worked our the required pieces.

Added this to the configuration. “CONFIG_USB_PULSE8_CEC=m”

Full diff against master is - http://ix.io/2CxB (I made all of the serial stuff modules)

It only used the following though

LibreELEC:~ # lsmod

Module Size Used by

serport 16384 1

pulse8_cec 24576 1

##

modprobe -v pulse8_cec debug=2

inputattach --pulse8-cec /dev/ttyACM0 --daemon

dmesg....

[35462.886070] serio: Serial port ttyACM0

[35462.886282] pulse8-cec serio0: transmit FIRMWARE_VERSION: 15

[35462.888117] pulse8-cec serio0: received FIRMWARE_VERSION: 15 00 08

[35462.888133] pulse8-cec serio0: Firmware version 0008

[35462.888137] pulse8-cec serio0: transmit GET_BUILDDATE: 17

[35462.890240] pulse8-cec serio0: received GET_BUILDDATE: 17 59 71 c4 88

[35462.890259] pulse8-cec serio0: Firmware build date 2017-07-21T09:08:24

[35462.890265] pulse8-cec serio0: transmit GET_AUTO_ENABLED: 19

[35462.891982] pulse8-cec serio0: received COMMAND_REJECTED: 09 19

[35462.892000] pulse8-cec serio0: transmit SET_CONTROLLED: 18 01

[35462.893792] pulse8-cec serio0: received COMMAND_ACCEPTED: 08 18

[35462.893886] pulse8-cec serio0: transmit GET_AUTO_ENABLED: 19

[35462.895597] pulse8-cec serio0: received GET_AUTO_ENABLED: 19 01

[35462.895692] pulse8-cec serio0: transmit GET_DEVICE_TYPE: 21

[35462.897352] pulse8-cec serio0: received GET_DEVICE_TYPE: 21 04

[35462.897371] pulse8-cec serio0: transmit GET_LOGICAL_ADDRESS_MASK: 1d

[35462.899106] pulse8-cec serio0: received GET_LOGICAL_ADDRESS_MASK: 1d 09 10

[35462.899127] pulse8-cec serio0: transmit GET_PHYSICAL_ADDRESS: 1f

[35462.900878] pulse8-cec serio0: received GET_PHYSICAL_ADDRESS: 1f 13 00

[35462.900896] pulse8-cec serio0: transmit GET_HDMI_VERSION: 23

[35462.902562] pulse8-cec serio0: received GET_HDMI_VERSION: 23 05

[35462.902578] pulse8-cec serio0: transmit GET_OSD_NAME: 25

[35462.904458] pulse8-cec serio0: received GET_OSD_NAME: 25 4b 6f 64 69

[35467.648788] cec cec0: transmit SET_CONTROLLED: 18 01

[35467.650511] cec cec0: received COMMAND_ACCEPTED: 08 18

# ls -lt /dev/char/250\:0 /dev/cec0

crw-rw---- 1 root video 250, 0 Oct 31 11:37 /dev/cec0

lrwxrwxrwx 1 root root 7 Oct 31 11:37 /dev/char/250:0 -> ../cec0

# cec-ctl

Driver Info:

Driver Name : pulse8-cec

Adapter Name : serio0

Capabilities : 0x0000002f

Physical Address

Logical Addresses

Transmit

Passthrough

Monitor All

Driver version : 5.9.0

Available Logical Addresses: 1

Connector Info : None

Physical Address : f.f.f.f

Logical Address Mask : 0x0000

CEC Version : 1.4

Vendor ID : 0x001582 (Pulse-Eight)

OSD Name : ''

Logical Addresses : 1 (Allow Fallback to Unregistered)

Logical Address : Not Allocated

Primary Device Type : Record

Logical Address Type : Record

First impressions:-

- the cec-ctl binary is there

- the seco_CEC kernel module is there

- the module doesn’t work with the Pulse8 (compiling that module now)

——-

LibreELEC (community): pr4627 (Generic.x86_64)

LibreELEC:~ # dmesg | grep -i cec

[ 3.037539] input: Pulse-Eight CEC Adapter as /devices/pci0000:00/0000:00:14.0/usb1/1-6/1-6:1.2/0003:2548:1002.0001/input/input4

[ 3.037614] hid-generic 0003:2548:1002.0001: input,hidraw0: USB HID v1.10 Mouse [Pulse-Eight CEC Adapter] on usb-0000:00:14.0-6/input2

LibreELEC:/ # modprobe -v seco-cec

insmod /lib/modules/5.9.0/kernel/drivers/media/cec/platform/seco/seco-cec.ko

LibreELEC:~ # lsmod | grep -i cec

seco_cec 20480 0

LibreELEC:~ # cec <tab>

cec-client cec-client-4.0.7 cec-ctl cecc-client cecc-client-4.0.7

LibreELEC:~ # cec-ctl

Failed to open /dev/cec0: No such file or directory

LibreELEC:/dev # find . | grep -i cec

./serial/by-id/usb-Pulse-Eight_CEC_Adapter_v8-if00

./input/by-id/usb-Pulse-Eight_CEC_Adapter_v8-if02-event-mouse

./input/by-id/usb-Pulse-Eight_CEC_Adapter_v8-if02-mouse

** I think the required driver for the NUC is the “CONFIG_USB_PULSE8_CEC=m” — I have updated the linux.x86_64.conf file and started a recompile. I’ll check in a bit later.

Thanks HiassofT . Just fixed my build environment. Was about to send @jernej a note on updating the wiki to add the following (not sure which on fixed the build)

apt install --reinstall python3-pkg-resources python3-setuptools

apt install --reinstall python-pkg-resources python-setuptools

pkg_resources was missing for the build of zstd:host

Compile [LibreELEC.wiki]

thanks Hias.

I don’t have a build system setup - but will get one together to compile the image - will let you know how I go.

Tried to watch Red Sky this evening. This is after rebooting the LibreElec last night.and watching Ad Astra.

the iPhone remote was able to select Red Sky, but there was not visual changes on the HDMI (it was showing the default estuary page) Up / down via the iPhone kodi app did not change display.

the log had a series of errors.

2020-10-28 21:36:22.153 T:112138 WARNING <general>: CRenderManager::WaitForBuffer - timeout waiting for buffer

http://ix.io/2Ch5

I killed the kodi process, and am currently able to watch Red Sky without issue.

this is on nightly-20201026-9e9b97f (Generic.x86_64) - Intel NUC6i5SYH

I was following th thread on CEC-client on RPI. And note that the direction suggested was CEC-CTL.

On the generic nightly matrix image it is not there. Is there a reason for that? It would be good to have cec-ctl available on the Intel NUC.

I was reading this reference. I have some issues with the way that my CEC environment behaves, and being able to pass though commands to the CEC devices would probably give me a good workaround.

CEC-HDMI - UDOO X86 Docs

I see that you have got cec-ctl running on your RPI.

On the generic nightly matrix image it is not there. Is there a reason for that? It would be good to have cec-ctl available on the Intel NUC.

I was reading this reference. I have some issues with the way that my CEC environment behaves, and being able to pass though commands to the CEC devices would probably give me a good workaround.

CEC-HDMI - UDOO X86 II Docs

confirmed all working.

inputstream.adaptive-2.6.0.2.zip

inputstream.ffmpegdirect-1.16.0.1.zip

inputstream.rtmp-3.2.0.1.zip

Hi All,

Just wondering if/why UsePrivilegeSeparation=no is set? versus =yes?

Could we not have the sshd user? e.g. "sshd:x:74:74:Privilege-separated SSH:/var/empty/sshd:/sbin/nologin"

My reasoning is to get rid of the error "ex protocol error: type 7 seq ######" when scp'ing to the libreelec.

Also I guess if ssh is updated from 7.3 in LibreElec 8.2 to openssh7.6 in 9.0 - then we will need to update UsePrivilegeSeparation=sandbox

Thanks