Posts by redger

    For those coming to this thread via search,

    I experienced similar problems with internet radio and was able to address them by reducing the readfactor down to 4 (default), or you could try a lower factor eg. 3

    It appears that some sources are unable to fill the buffer fast enough (?)

    I wanted to run Zerotier on a Pi running Libreelec so a remote device (the Pi) could access content stored in another city

    The Zerotier network is "private" ie. every node must be authorised to access the network.


    I found a docker image which delivers Zerotier functionality on a Raspberry Pi --> bltavares zerotier docker image


    After installing the Docker addon and the above docker image, Zerotier is running BUT it will issue a new zerotier address each time Librelec reboots and this is not useable for a private Zerotier network because the new address will have to be authorised (on each reboot) ... not much use for a remote device


    It turns out that -

    1. There are 3 key files in the docker container which need to be "preserved" between boot sessions

    - /var/lib/zerotier-one/identity.public

    - /var/lib/zerotier-one/identity.secret

    - /var/lib/zerotier-one/authtoken.secret

    2. The container needs to "connect" to the network anew on each boot, once the above files are restored and the container has been restarted


    With that understanding we can retain the same ZeroTier node address and authorisation


    Additionally I have a need to mount some directories from a remote host ... so we do that after reconnecting the container to ZT


    The steps are


    * install the docker addon in Libreelec using the menu system

    o  From addons/install from repository/libreelec addons/services/docker 


    * log in via ssh and install the docker container

    > docker pull bltavares/zerotier


    then install the ZeroTier container

    Code
    docker run --device=/dev/net/tun \
    --net=host \
    --cap-add=NET_ADMIN \
    --cap-add=SYS_ADMIN \
    -v /var/lib/zerotier-one:/var/lib/zerotier-one \
    --restart always \
    --name zerotier-one \
    -d bltavares/zerotier


    * Now check and record the ZT node id (referred to as <node-id> later

    > docker exec zerotier-one zerotier-cli info


    * Join your network - and authorise this node using the tools at ZeroTier Central

    > docker exec zerotier-one join <your network id>


    * Then copy the 3 key files off to a new directory

    > mkdir /storage/.kodi/userdata/<your_dir>

    > mkdir /storage/.kodi/userdata/<your_dir>/zerotier

    > TEMP=$(docker exec zerotier-one cat /var/lib/zerotier-one/identity.public);echo $TEMP >  /storage/.kodi/userdata/<your_dir>/zerotier/identity.public

    > TEMP=$(docker exec zerotier-one cat /var/lib/zerotier-one/identity.secret);echo $TEMP >  /storage/.kodi/userdata/<your_dir>/zerotier/identity.secret

    > TEMP=$(docker exec zerotier-one cat /var/lib/zerotier-one/authtoken.secret);echo $TEMP >  /storage/.kodi/userdata/<your_dir>/zerotier/authtoken.secret 


    * Now we need to create/update the Libreelec autostart.sh

    > nano /storage/.config/autostart.sh


    Paste the following after existing code (add "#!/bin/sh" at the first line if this is a new file and execute chown ug+x /storage/.config/autostart.sh after saving it).

    You may wish to improve this code ... I hacked this together with my limited understanding of shell scripts and I left everything really basic and simple to aid understanding (and debugging). The main thing is that it seems to work and was reasonably easy to debug

    You will also need to replace the <node-id> and <network-id> values with your ids and <your-dir> with the name of the directory you created above



    Note that the above code will deliberately slow the boot process with the "sleep" commands. Not an issue for my remove device and it improved the reliability of the network connection and mounts

    You can run the above code from the command line to check that it "compiles" and runs ok .... and that it doesn't make a mess. Then try a reboot to prove that ZT will automagically connect again on reboot.


    * Reboot and check that we are connected back to the ZeroTier network

    > reboot


    Then ssh back into the machine (reboot will have logged you out of the previous session)


    * Check we have the expected node id

    docker exec zerotier-one zerotier-cli info


    * Check there is a "ztb....." adapter listed ... and an appropriate IP address for it
    ifconfig


    If you have the wrong node id or there's no zt adapter you'll need to start debugging to see what's wrong

    aha ... an hour or so later there's a new release ..

    LibreELEC-S905.arm-9.0-devel-20180218031232-r28165-gb635550.tar


    I've installed the new release ... and now the remote works out of the box ie. no other changes


    now I see

    Code
    # ir-keytable
    Found /sys/class/rc/rc0/ (/dev/input/event4) with:
    Driver: meson-ir, table: rc-empty
    lirc device: /dev/lirc0
    Supported protocols: lirc rc-5 jvc sony nec sanyo mce_kbd rc-6
    Enabled protocols: nec rc-6
    Name: meson-ir
    bus: 25, vendor/product: 0000:0000, version: 0x0000
    Repeat delay = 500 ms, repeat period = 125 ms
    #


    Thanks Adam 8)

    Help :)

    I have a mecool M8s pro+ (s905x), which has been flashed with Magendanz firmware (specifically "update_M8S_PRO+-V0928_TVStock-20171216_OTA.zip").


    The firmware update was successful.

    The remote works fine in Android => both the remote transmitter and receiver are working


    The remote was working with previous versions of the Leia Alpha builds (using meson)


    I'm using the LE DTB -> gxl_p212_2g.dtb generated on 14-Feb-18. The box seems to boot and behave fine in all respects except the IR Remote


    Now I'm trying to set the remote up using ir-keytable, but the utility cannot find a useable remote receiver

    Code
    # systemctl stop kodi
    # systemctl stop eventlircd
    # ir-keytable
    No devices found
    #

    I did find what appears to be a remote device in dmesg ("")


    so tried using that by setting a keytable directly eg.

    Code
    ir-keytable --clear --device=/dev/input/event0 --protocol=nec --write /usr/lib/udev/rc_keymaps/libreelec_multi_amlogic

    But this just results in a stalled process and a machine that can only be rebooted by removing the power ie. unplugging


    Any advice will be gratefully received :cool:


    PS I attempted to generate & paste a log file from within LE without success ... the process kept failing, so I've manually compressed dmesg and kodi.log together and attached themlog-2018-02-18-13.25.00.zip

    I have an M8S+ with a built in network adapter running kszaq's build 8.0.1b
    The built in adapter works.
    In my case I wish to use a USB adapter instead, so I can add an external high gain aerial.


    I have a TP-Link WN722N adapter (USB) which appears to work ok
    - no errors in dmesg
    - the appropriate drivers are loaded).


    <code>
    lsusb
    Bus 002 Device 003: ID 0cf3:9271 Qualcomm Atheros Communications AR9271 802.11n
    </code>


    <code>
    /blsmod/b
    Module Size Used by
    hci_uart 21893 1
    bnep 11028 2
    btsdio 3186 0
    dhd 711956 0
    bluetooth 243676 25 bnep,btsdio,hci_uart
    6lowpan_iphc 5791 1 bluetooth
    8021q 18855 0
    ath9k_htc 57701 0
    ath9k_common 2008 1 ath9k_htc
    ath9k_hw 388050 2 ath9k_common,ath9k_htc
    ath 20156 3 ath9k_common,ath9k_htc,ath9k_hw
    mac80211 376213 1 ath9k_htc
    cfg80211 360926 4 ath,dhd,mac80211,ath9k_htc
    wifi_dummy 806 0
    mali 198264 5
    amlvideodri 11586 0
    videobuf_res 5394 1 amlvideodri
    videobuf_core 16475 2 amlvideodri,videobuf_res
    videodev 145853 1 amlvideodri
    media 21002 1 videodev
    aml_nftl_dev 82844 0
    fbcon 37431 0
    bitblit 4484 1 fbcon
    softcursor 1208 1 bitblit
    font 7287 1 fbcon
    dwc_otg 230727 0
    </code>



    The boxes built-in adapter always seem to be wlan1 and the usb adapter is wlan0


    I have a valid connection file at /storage/.cache/connman/xxxxxxx which does indeed successfully connect to the wifi network


    I have tried -
    - Blacklisting the wlan1 adapter in connman setup at /storage/.cache/connman/settings with
    ....[global]
    ....NetworkInterfaceBlacklist=vmnet,vboxnet,virbr,ifb,ve-,vb-,wlan1
    - Using ifconfig to turn the interfaces off and on again with
    ....ifconfig wlan1 off
    ....ifconfig wlan0 off
    - Disable and re-enabling wifi via connman
    ....connmanctl disable wifi
    ....connmanctl enable wifi


    If I use the Kodi skin interface (Libreelec settings) to enable the adapter i sometimes see connections for the built in adapter (wlan1) and sometimes not


    No matter what i do -
    - connman will never successfully enable the USB adapter (wlan0)
    - connman will always choose the built-in adapter (wlan1) and enable it


    I don't see any errors in dmesg (I can post it if that will help)


    It seems like I'm missing something ... but I don't know what. Extensive web searches haven't turned up anything helpful


    Please can someone advise either (a) how I might achieve this or (b) where to look


    thanks


    ======================================================
    EDIT
    ======================================================
    oops, it turns out that
    - the process of blacklisting the inbuilt adapter has (mostly) worked.
    - I had set a channel on the router which the USB adapter could not access on this machine ... which is odd since the same channel worked fine with the same adapter on a raspberry pi
    - I periodically see stations for the inbuilt adapter (wlan1) in the list of available connections. I had to edit the originally created wlan1 connection and set it to manual so it would not automagically associate


    Now working. Sorry for wasting time of those who looked at this

    here's a bunch i've been collecting (updated 7-March-17)
    - beelink m18
    - coolead
    - mini m8s ii
    - m8s+
    - nexbox a5
    - nexbox a95x
    - ott mxq
    - qbox
    - tanix tx5pro
    - tronsmart s95
    - x96


    also "create_remoteconf_from_scratch.txt"


    Note that the mini m8s ii files are commented/documented, the others are "raw"

    Go to -
    - System
    - LibreELEC
    - Connections
    - Wired (say)


    Click on the "Wired" connection (or a specific Wireless connection if that's what you want to set)


    Then "Edit" and go to
    - IPv4 (say ... few people use IPv6)
    - IP Address method ... and change to "manual"
    Set fixed IP address if you wish (I do because I want a stable address for VNC, Samba etc)
    - Click save
    - DNS servers
    - Nameserver #1 and click
    Set DNS server address
    - Save


    You will now have set the DNS server


    You can accomplish the same outcome at initial setup if you click on the IP addressing info and change it as required

    Have you tried "manual" IP addressing ?


    I have successfully set DNS, no problem, just needs manual IP address (which will be copied from the DHCP address initially allocated, then you modify it)

    Where do you disable de-interlacing? Can't seem to find it anywhere in the settings or in the vide OSD..


    From memory - When the video is playing, press <m> for menu, go to the video icon, select and then select deinterlacing and set off. At the bottom of the list, click on "set as default for all videos"

    Mini M8s II 2Gb/8GB
    Just installed the 32 bit v11 build from scratch (not an upgrade)


    all working smoothly. Experienced some audio synch issues (passthrough audio) until de-interlacing turned OFF ... then all synch's ok


    No need for echo 1 > /sys/module/amvdec_h264/parameters/error_recovery_mode any more


    thanks kszaq


    envagyok I tried you clip, while logged in via SSH with the following results

    • Clip began playing, sound could be heard
    • No visual elements appeared
    • Play stopped after 5 secs (just before the end ?)
    • The machine was still available and responsive via SSH
    • Could not kill (pkill -9 kodi.bin) or restart (systemctl restart kodi / systemctl stop kodi) kodi successully. The commands all completed ok, but a kodi session was still visible (ps -e | grep ko)
    • Could commence the reboot process, and the screen would reset and SSH exit, but final shutdown & restart did not occur. Screen left in dark state and no ability to log back in via SSH.
    • Can't even ping the host at this stage (presumably all services are closed
    • Had to remove and restore power to force a restart


    You might want to generate a system log (see the forum post on how to generate a log)

    hi again kszaq ...


    any thoughts on the 720p/50 problem (looks like it might be a pull down issue, brief stutter every second) ?


    I have managed to work around it ....

    • In System / Video menu mpeg2 acceleration = off (for all resolutions)
    • whilst video is playing invoke video menu, set Deinterlace Video = off and then Set default for all videos


    The video is still arriving at the tv as deinterlaced, presumably the hardware is deinterlacing it by default. Quality is good and the hardware is able to decode 1080i/50 in software at about 30% cpu across each of the 4 cores.

    Please try entering this command over SSH and then play your video: echo 1 > /sys/module/amvdec_h264/parameters/error_recovery_mode.


    woohoo ... yes ! Thanks, that fixed the 1080i/50 synch problem. The video quickly recovers from the source error and continues to play "normally".
    I've now added that command to /storage/.config/autostart.sh


    Great Thanks :):D


    ΟΚ, I tested the clips and I saw the problems you described. The log is full of ffmpeg errors.

    Code
    T:545443455200 ERROR: ffmpeg[7EFEF6A0E0]: [h264] non-existing SPS 0 referenced in buffering period
    T:545443455200 ERROR: ffmpeg[7EFEF6A0E0]: [h264] non-existing PPS 0 referenced
    T:545443455200 ERROR: ffmpeg[7EFEF6A0E0]: [h264] decode_slice_header error
    T:545443455200 ERROR: ffmpeg[7EFEF6A0E0]: [h264] no frame!
    T:545443455200 DEBUG: ffmpeg[7EFEF6A0E0]: [mpegts] parser not found for codec dvb_teletext, packets or times may be invalid.


    This is a wild guess but I think the problem is the teletext\subtitles streams in the files. They mess up the timings.


    thanks, confirms it's not just me :P


    There seem to be 2 different problems (h264 vs. mpeg2). The h264 stream seems "unrecoverable" for a period of time whereas the mpeg stream recovers ok


    Interestingly the h264 clips play ok in version 7 (minor glitch - "instantly" recoverable), but not versions 9 or 10 ... whereas the mpeg stream has a problem in all the releases I've tested so far


    For the H264 file In my log file I found a whole lot of this (50-100 lines) at about the time the problem starts and no obvious indication of teletext problems

    Code
    20:49:54 T:546019434720 DEBUG: CDVDPlayerVideo::CalcDropRequirement - dropped in decoder, Sleeptime: 0.019167, Bufferlevel: 1, Gain: 0.062450
    20:49:54 T:546019434720 DEBUG: CDVDPlayerVideo::CalcDropRequirement - dropped in decoder, Sleeptime: 0.007966, Bufferlevel: 1, Gain: 0.021299
    20:49:54 T:546019434720 DEBUG: CDVDPlayerVideo::CalcDropRequirement - dropped in decoder, Sleeptime: 0.008298, Bufferlevel: 1, Gain: 0.021427


    in the Mpeg2 file I find this pattern repeating on playback

    Code
    08:03:11.671 T:3659453344 DEBUG: CVideoPlayerVideo::CalcDropRequirement - hurry: 1
    08:03:12.025 T:3659453344 DEBUG: Previous line repeats 19 times.
    08:03:12.031 T:3659453344 DEBUG: CPullupCorrection: detected pattern of length 24: 80000.00 20000.00 20000.00 20000.00 20000.00 20000.00 20000.00 20000.00 20000.00 20000.00 20000.00 20000.00 20000.00 20000.00 20000.00 20000.00 20000.00 20000.00 20000.00 20000.00 20000.00 -40000.00 20000.00 20000.00, frameduration: 20000.000000
    08:03:12.121 T:3659453344 DEBUG: CVideoPlayerVideo::CalcDropRequirement - hurry: 0
    08:03:12.147 T:3659453344 DEBUG: CVideoPlayerVideo::CalcDropRequirement - hurry: 1
    08:03:12.596 T:3659453344 DEBUG: Previous line repeats 17 times.


    I posted complete logs and discussion at LibreELEC and LibreELEC


    thanks again for following up with tests and feedback