Posts by chewitt

  • Picture breakup watching live TV from a Raspberry Pi 4 running TVHeadend Client in LibreELEC

    I watch live TV on an RPi4 in Dubai from a TVH server (DVB-C) shared by one of Kodi developers in Helsinki with all traffic routed via a WireGuard tunnel that egresses in the UK, but without any noticeable issues that aren't easily explained by other things consuming bandwidth on the Dubai to UK leg, or bad weather in Finland. Why? .. because there is no terrestrial TV in Dubai and no option to use a Satellite receiver in the development where I live so it's the only way I get to test DVB related things. I also have access to a TVH server in Germany but the Finns don't dub everything and my schoolboy German sucks so the Helsinki server is more usable :)

    No need to whitelist the non-1080p resolutions. Set Kodi GUI to 1080p60.

    Re-reading the original post, I think you need to solve the server side issues as bad signal/reception or processing in the server is going to result in issues that can't be resolved client side. I doubt the client is the issue, although some of your original config wouldn't help.

    I'm not much good with the server end as I never self-host it..

  • Wireguard - changes the default route although not configured

    I've been told the AllowedIP setting is for internal WireGuard logic and WireGuard is not controlling the routing table. However, the WG connection is higher in the list of connman services (as it was created most recently) which means it becomes the primary service and default route. To change this we can change the service order via connmanctl, e.g.

    Code
    connmanctrl move-after vpn_138_116_14_12_wg_domain_tld ethernet_1cf05e0b93f0_cable
Moved vpn_138_116_14_12_wg_domain_tld after ethernet_1cf05e0b93f0_cable

    So syntax is: connmanctl move-after <service_to_move> <service_to_move_it_after>

    So for scenarios where you want to connect via WireGuard to access content on a remote server, but otherwise still want/need the Internet connection to be as-normal from the local network, we can add another ExecStart in the connman.service file, e.g.

    Code
    [Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/usr/bin/connmanctl connect vpn_138_116_14_12_wg_domain_tld
ExecStart=/usr/bin/connmanctl move-after vpn_138_116_14_12_wg_domain_tld ethernet_1cf05e0b93f0_cable
ExecStop=/usr/bin/connmanctl disconnect vpn_138_116_14_12_wg_domain_tld

    NB: I haven't tested this, but it makes sense to me, so please have a play and report back.

    NOTE: I have subsequently been told that the move-after changes are persistent, so would only need to be done once.

  • LibreELEC 7.0 (Jarvis) release

    The one upgrade you can do that would make a difference is to replace the ATA drive with an SSD, as the stock drive is 5400rpm (and likely around a decade old - the fact it hasn't failed is a miracle) and although RAM is an unresolvable issue, swapping on an SSD is greatly improved. I've used SATA SSDs via an adapter in the past, but Amazon/eBay show mSATA to IDE/ATA drive converters now which would be easier to fit inside the case.

  • LibreELEC 7.0 (Jarvis) release

    The OE 6.0.1 image is the best-performing release for the AppleTV that I created as it has hacks like nVidia shader caching and a startup sequence in Kodi designed to force things into swap to create free RAM headroom that helps subsequent playback. However it's all a fudge/compromse and both OE and OSMC have the same fundamental issue: the CHD drivers are not perfect and 256MB RAM is not enough for good Kodi operation.

    NB: An RPi Zero (€15 new, prob. cheaper used) with 512MB RAM would be a huge improvement over a mk1 AppleTV.

  • How to revive an S912?

    The Android box market moved onto newer/shinier things so S912 is long-forgotten as the top device in Amlogic's line-up, but there is still commercial interest in S912 from industrial users. LibreComputer is about to release a new board (tartiflette) and because GXM is only a minor evolution from GXL it's a solid/stable platform, which is key for that audience. I've been passed some S912 devices recently and even without an Android dtb or schematics it's been fairly trivial to get all the core hardware working.

    However, the tricky bit is always the boot firmware. You either need to self-compile a recent mainline u-boot and experiment with fip sources. The only public ones are for VIM2 and Tartiflette so that shouldn't be a lengthy exercise. Or you extract something from an Android image. Until you solve that piece of the puzzle building higher-level distro's (meta-meson, LE, Armbian, etc.) isn't going to be fruitful.