I am using TVHeadend but, the problem is in LE7 that was working flawlessly.
So my guess is that's a problem not dedicated to vdr or TVHeadend it's a general fault/issue?
Yes, it is an issue of current Kodi 17 code. LE7 includes Kodi 16.1 that calls setwakeup.sh correctly.
So that's another/different problem?
Kodi is shutting down before a timer is getting set?
Yes, according to your log kodi seems to be hanging on shutdown while/after disconnecting VNSI and is killed finally. This is behaviour by design of the LibreELEC kodi SIGTERM implementation.
Kodi will even fail when going further and trying to set the timer because it cannot read its own settings any more.
Does setting a timestamp (using setwakeup.sh date '+%s' -d '+ 10 minutes') works on your system?
I am getting an error but there is always a timer 5 minutes ahead.
So could you try with 10 minutes pls?
Busybox's "date" does not accept parameters like "+ 10 minutes". You have to use something like
setwakeup.sh $(($(date +%s)+600))There is not the expected message
DEBUG: CSettingsManager: requested setting (pvrpowermanagement.enabled) was not found.
in your log because Kodi seems to be killed before exit completes.
The functionality can be restored using this Kodi patch. I do create a bug report the next days so it can be fixed upstream.
Kodi Log: gPhY
Thanks for the log. Unfortunately in this special case the shutdown needs to be logged. Please post a full /storage/.kodi/temp/kodi.old.log
So here's what I did: 1) copy over the contents of /storage to the flash drive, 2) replace contents of cmdline.txt, and 3) reboot:
Code# systemctl stop kodi # rsync -rtv /storage/ /var/media/TV-201702/ # mount -o remount,rw /flash # nano /flash/cmdline.txt
Unfortunately your rsync line does not copy all content, i.e. symlinks are skipped.
I recommend wiping the USB disk and retry with
rsync -a /storage/ /var/media/TV-201702/cp /usr/lib/systemd/system/kodi.service /storage/.config/system.d/and add
Environment=MALLOC_MMAP_THRESHOLD_=32768No further ideas.
If you are curious enough you may do a binary search on Milhouse's LE Testbuilds to find the starting build with the issue.
Krypton adds dithering to video processing causing higher CPU load.
In worst case you may get 100% CPU load and video stuttering on slower CPUs.
Dithering is enabled by default, your settings level has to be "Expert" to be able to disable it.
You need the build with official Digital Devices drivers: thread-130-post-31085.html#pid31085
If this only occurs in SD mpeg2 videos you my work around the issue by activating expert settings level and disable VAAPI mpeg2 only.
The CPU can easily decode mpeg2 and VAAPI is still used for HD video.
I'm running tvheadend 4.0 server and tvheadend pvr in this htpc with a digital devices cine s2 card. MB is an zotac atom with nvidia card.
You may try CvH's build with Digital Devices drivers: thread-130-post-31085.html#pid31085
Please read the Deprecated Stuff section and the answers.
When I said I'm not too sure about what any of that means, I was referring to your previous post that I had quoted.
This disables the start of lircd via udev. You have asked about it.
I am aware that the code I posted disables the eventlircd service, but it does not do it on subsequent boots unfortunately
Really? As long the link exists eventlircd is not started by systemd. Did you check with
ps|grep eventlircd
I'm not too sure what any of that means but I did find the following code from the OpenELEC forums:
Codeln -sf /dev/null /storage/.config/system.d/eventlircd.service sync && reboot
This disables systemd's eventlircd service on following boots by overriding the normal /usr/lib/systemd/system/eventlircd.service file.
This fixes my issue after the reboot! All keys on the IR keyboard (remote) start working again. However, once I reboot for a second time, it stops working again. It looks to me like the above code creates a symbolic link from /dev/null to the LIRCD service which basically stops LIRCD from working completely. This is fine as it allows IR-KEYTABLE to work but I cannot figure out how this code should be implemented to work on every boot!At least I'm getting somewhere now and I know this is possible in LibreELEC.
There is a nice picture in the yaVDR documentation describing the eventlircd input device handling on 3.3. Remote Control. There are differences in details to LibreELEC but it may help to get an idea how your IR receiver is working in the system.
So I'm using DRI3 + GLAMOR? not DRI2 and exa as specified in the xorg-radeon.conf comment?
Is the correct/better configuration for my GPU?
Only Glamor is implemented for Kabini, the configuration is correct.
Also receive incorrect temperatures in the system information.CPU and GPU show 1ºC
AMD virtual temperatures, see k10temp\hwmon\Documentation - kernel/git/stable/linux-stable.git - Linux kernel stable tree
There must be a way to permanently disable LIRC / LIRCD so that only IR-KEYTABLE processes IR commands in-kernel.
Do not know if it helps but you can disable the udev lirc rules with
: >/storage/.config/udev.rules.d/98-lircd.rulesand/or mask the lirc systemd units with
: > /storage/.config/system.d/[email protected]
: > /storage/.config/system.d/[email protected]and reboot
EDIT: Here is an excerpt from my kodi.log. It looks like I was right; LIRC is intercepting IR signals and dropping those it doesn't understand!11:49:02.518 T:140430158071040 DEBUG: LIRC: Update - NEW at 71677:2e 0 KEY_C devinput (KEY_C)
11:49:02.767 T:140430158071040 DEBUG: LIRC: Update - NEW at 71926:2e 0 KEY_C_UP devinput (KEY_C_UP)
You can map unknown lirc keys to kodi remote keys using Lircmap.xml.
cp /usr/share/kodi/system/Lircmap.xml /storage/.kodi/userdata/Edit the devinput section (in your case), i.e.:
...
<remote device="devinput">
<menu>KEY_C</menu>
...
Could you probably please share a generic build with official dd drivers?
It was one build with experimental features/changes and is already deleted because youtube did not work any more.