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.
yes known problem, official drivers do not compile at kernel 4.9 - so nothing i can do till they fix their drivers (the oss drivers that i use have no support for v7)
Which error do you see? I tested the official drivers successfully about two weeks ago using this package.mk.
It may look familiar to you as it is "borrowed" from your GitHub repository.
Maybe checking udev's knowledge about the partitions gives an idea:
udevadm info /dev/sda1
udevadm info /dev/sda2no the 4.8 patch had a lot merge conflicts also without the tbs patch (at least milhouse told so)
Yes, it looks like the DVB API is changing on every mayor kernel release. The patch must match the kernel version. I can nearly promise the 4.9 patch will not work on 4.10 - but the 4.10 patch is already WIP.
But why does it work with less than 8.388.240 MB without any problems. I dont know the exact value when it is overturning but it must be between 8.388.240 MB (working) 8.399.999 MB (not working).
The device size is detected different (and you swapped the two log files 
1022 dmesg log:
[ 9.840137] sd 0:0:0:0: [sda] 17581277184 512-byte logical blocks: (9.00 TB/8.19 TiB)1031 dmesg log:
[ 9.733719] sd 0:0:0:0: [sda] 23441768448 512-byte logical blocks: (12.0 TB/10.9 TiB)But I have currently no idea what is causing this.