can you provide some dmesg output ?
1. unplug the device and reboot
2. plug the device in again and enter dmesg | paste at ssh and post the URL here
3. restart the device and dmesg | paste at ssh and post the URL here again
could be a driver problem/bug, maybe there is an easy fix
likely due arch linux 
no idea actually, maybe try LE master if it works there
I know how to change it but no idea how to do it a LE 
/etc/systemd/logind.conf
#HandleLidSwitchExternalPower=suspend
#HandleLidSwitchDocked=ignoreto
HandleLidSwitchExternalPower=ignore
HandleLidSwitchDocked=ignorelike said no idea how to change at LE
Digibit R1 is also a good choice if you search for some tuners 
I'm not even dead certain it's the TV Tuner locking up the whole RPi, but it seems like the area of greatest probability?
Thats something I had seen in the past years maybe 1 or 2 times. So this is very unlikely, not impossible.
Just to name the biggest problems for this kind of issue:
- SD card
- power supply
- heat/temperature
If it is kind of reproduce able I would change those parts (if possible) and have a look.
Also you could write some small script and add it to crontab -e
* * * * * /storage/crash.sh >/dev/null 2>&1
/storage/crash.sh
#!/bin/bash
file="/storage/crash_$(date +%m-%d-%Y-%H_%M_%S).txt"
dmesg | tail -n40 > "$file"
echo -e "\n\n\n== RAM ================" >> "$file"
free -m >> "$file"
echo -e "\n\n\n== CPU ================" >> "$file"
mpstat >> "$file"Hmm same situation 
Could you test it at an other device ? Besides that I have really no idea, I ping the WinTV driver Maintainer, maybe he can have a look.
It looks like its an RPi specific problem. Others have the same issue at Rpi too (not LE).
So I guess we need to play with the RPi options
looks very strange
usbcore: registered new interface driver dvb_usb_nova_t_usb2
afterwards it just stop
there should be some line
dvb-usb: Hauppauge WinTV-NOVA-T usb2 successfully initialized and connected
so I guess its not directly related to the dvb drivers (standard should be good enough)
Pls try disconnect, reboot, attach to different usb port (USB2/USB3) and have a look at the demesg if more output is generated
If you use some USB hub etc pls remove and directly attach it.
this is expected, those "addons" do not support LibreELEC so it won't find the binary for Chrome
do you have some settings where you specify the location of the binary ?
it looks half fine at dmesg, not sure whats wrong
try to remove the stick and reboot
wait some seconds after reboot (10-20) and then plug the stick again to the system
wait ~10sec and post an dmesg | paste again
So we get it more clear what happens here, DVB-Latest or Standard should do it, likely.
pls use the "driver addon" and not activate the addons itself - currently you have 2 addons activated and this will not work properly
the dvb-latest addon should do it for that stick, if not just post an dmesg again (dmesg | paste)
CvH you might be interested in this as you supply a TVH4.3 addon.
do talk about that ? LibreELEC.tv/download.py at master · LibreELEC/LibreELEC.tv · GitHub
via launcher
what launcher do you use ?
If you just start the Chrome addon from our repo it should just work.
yes/no
as long Kodi don't try to write something to the db you are fine, but thats a slippery slope
Just adding that these captchas are from Cloudflare.
So if your Tor Node is used by some spammers and attacking a random site that is also "protected" by Cloudflare you get the "robot checks".
You are basically using an IP that can't be trusted and is/was used by spammers, thats why you get the warning.
Nothing we can do about it without lowering the "defense" of our servers.
Thats strange, can't find autogen.sh - so something went wrong at unpacking that package (disk full??).
try
PROJECT=Generic ARCH=x86_64 scripts/clean avahi
PROJECT=Generic ARCH=x86_64 scripts/build avahi
if this worked
PROJECT=Generic ARCH=x86_64 make image
there you can choose the "theme"
