Posts by frakkin64

    Then I wonder, why affecting 1.9G to /tmp, or 1.8G to /var and only 27M to /storage?

    Not really mentioned here, but /tmp and /var are "tmpfs" filesystems. Which is basically like a ramdisk and is not persistent storage or using any real disk partitions.

    There is a safeguard in the resize script that will not do the resizing if the /storage partition already has some key folders. Where things go wrong is when you re-image and decide to copy files over and then recover files from a backup before first boot. This is likely your situation, and it requires a manual partition resizing & filesystem resizing.

    I wondering using NFS for recording and Samba for replay at the same time everything woks fine.

    The problem exists only when using NFS for recording and for replay at the same time !

    One other thing to consider here is perhaps NFS locking is an issue, especially if you are trying to watch a file that is being written to (i.e. trying to watch a live recording being written by VDR). Probably worthwhile to ask this question on the VDR forums, as you will probably find someone with similar setups. Tvheadend & MythTV work completely differently, everything is streamed by Tvheadend or MythTV, client doesn't access the recorded media files directly.

    There is just too much opportunity for speculation here with very little data, unfortunately.

    I am running Tvheadend with 6 tuners (2 tuners are over Ethernet, and 4 tuners are in a PCI card in the computer) on an AMD 8-Core machine with 20TB storage, it has no problem recording all tuners at the same time, plus serving 2 medacenter devices over NFS. It serves both my media library and Tvheadend content (which is over HTSP [TCP]).

    Have you ran on your Pi to get more insight? I would run it with: " xce ieth0", you might need to change the eth0 to your network device. I would run that on your Pi hosting the storage, it will give you good visibility to your RX/TX network plus CPU/MEM usage. You might need to check your kernel settings for the number of NFS daemons running (on a Debian based system this is in /etc/default/nfs-kernel-server, changing RPCNFSDCOUNT). I run with 8 myself which is probably overkill since I don't have the overhead of writing to NFS over the network from Tvheadend like you do.

    This article has some advice on tuning nfsd threads:

    Document Display | HPE Support Center

    comments/rotten fruits ?

    I prefer the current format (%Y%m%d%H%M%S), it makes sense, is very readable. I deal with data files typically all the time that contain this exact timestamp format in their filename, it is a pretty common approach and is generally done sort you can easily sort the list of files by timestamp.

    I agree with Klojum, if anything it would be useful to indicate some additional details such as a device unique identifier (maybe hostname, mac, or sn). I personally don't know if I would care about a device type, if I had a unique identifier, but I could see LE version being useful especially when you don't want to make a mistake of pushing a 9.2 backup to 10.

    Hi, I´m using RPI4 with LibreElec (LibreELEC (official): 10.0.0 (RPi4.arm)) and Kodi. I would like to connect it by WiFi USB Adapter AC1300. Is it possible? If yes, can you navigate me to same manual how to do it. Thaks!

    Pretty sure this requires RTL8822BU drivers (I think I have these same USB dongles), not currently in LE 10. You have to build your own image, below is the basic patch required to libreelec-10.0 branch:

    As others have said, the WiFi antenna on the Pi4 is very small, so range is limited.

    I wonder what folks consider "limited". My Pi4 is downstairs from the router, going through at least 1 wall, probably a distance of 35 feet. I would assume the router is another factor. But even with the crappy USB dongle no problems, which is also a very small Wi-Fi antenna.

    So I am guessing people are running much larger distances, wall construction, crappy routers, more congestion/interference, or something else. Even in the built-in Wi-Fi was fairly stable for me, but I have read a whole bunch of posts of people with problems (HDMI interference, Bluetooth interference, USB is new to me, etc).

    I do boot from an SD card, so far it hasn't been a problem but interested in dealing with the eventual failure. :)

    I confirm that wifi on raspberry pi 4 is an absolute nightmare. There is so much variance, in my case it can go down to 2mbps and up to 35mbps on a 2.4ghz network, and i have no idea why it is so janky.

    You should make sure you have the latest firmware, which is best done if your on LE 10. Earlier firmwares definitely have co-existence issues @ 2.4GHz w/ Bluetooth and even HDMI itself. My understanding is those issues were addressed through the magic of firmware. 2.4GHz is also pretty overcrowded. I know another user had problems on LE 9.2 and managed to update the firmwares which improved the situation.

    I have never used 2.4GHz channels on the RPi4, so not sure how reliable it will be. RPi4 does work well @ 5GHz w/ 80MHz channels (which 80Mhz channels is a later firmware addition as well). It was fairly stable for me, the problem I had was the 80Mbps restriction of the internal bus. But in short you can't run on Wi-Fi alone without bumping the cache.

    By the way, which USB adapter have you bought that gets 250Mb/s on Pi?

    I am using these (802.11ac):

    TP-Link AC1300 USB WiFi Adapter(Archer T3U)- 2.4G/5G Dual Band Wireless Network Adapter for PC Desktop, MU-MIMO WiFi Dongle, USB 3.0, Supports Windows 10, 8.1, 8, 7, XP/Mac OS X 10.9-10.14
    TP-Link AC1300 USB WiFi Adapter(Archer T3U)- 2.4G/5G Dual Band Wireless Network Adapter for PC Desktop, MU-MIMO WiFi Dongle, USB 3.0, Supports Windows 10, 8.1,…

    They have absolutely no external antenna at all. Probably if I were to crack it open just a large trace on the PCB. :) I believe what Klojum posted is using drivers already in LibreELEC (RTL8812BU?). You can get similar USB sticks with external antennas for the same price.

    But you have to roll your own build with the RTL8822BU drivers from (he has the latest driver version). I don't know why Realtek rolls so many Wi-Fi stacks. One thing to mention is 8822BU is USB 2.0, where as I believe 8812BU is USB 3.0. So 8812BU is the better chipset to buy, I may be rubbing up against the theoretical limit of USB 2.0.

    My rPI4 is now attached to a TV that is nowhere ethernet socket, so I need to find another solution. I took my Pi out of the case to maximise antenna's reception however when attempting to stream videos via Wi-Fi, I can't get anything with bitrate more than 8-10Mbps to stream smoothly off my NAS. I believe that Pi4's built-in Wi-Fi is just not capable of doing it. Definitely not a problem with my house's Wi-Fi setup (Cisco 3802 with vWLC).

    You don't really mention what version of LE your running. RPi4 will cap out at roughly ~80Mbps for Wi Fi performance, regardless of connection speed. If your OC'd then I have heard of up to 100Mbps. It is limited by the SDIO bus speed, and as I understand it there is nothing you can do about this. The performance will vary based on congestion, distance, etc.

    What I would do is install iperf3 on your NAS, and then test both directions from your RPi4. I am in a similar situation, and I have used the internal Wi-Fi before but typically my content is HD or FHD, and ran into buffering problems even with sustained 80Mbps bandwidth. You can try to combat that with adjusting the cache memory size via advancedsettings.xml, on a 2GB RPi4 you have plenty of RAM available so something like this should be OK:

    <advancedsettings version="1.0">

    Some folks will say this will slow down video load times (I haven't noticed anything, and I actually run with 512MB cache), or it requires 3x memory (I think the Kodi Wiki says this, it may have been true with older versions of Kodi -- but doesn't appear to be the case anymore). But reality is the cache memorysize is the fixed memory allocation, 1/4 of the buffer is for the back cache (rewind), and 3/4 is the forward cache.

    With that all being said, this might be enough to make it work with HD/FHD content. Not sure about UHD (4k) content. I personally bought a USB stick, and can get up to 250Mbps with it. USB bus has a lot more bandwidth than the built-in Wi-Fi.

    I use sendtokodi (so I can browse videos from phone and then choose share/sendtokodi and video plays on TV).

    sendtokodi was hit by the youtube throttle, but I described a fix here

    Yeah, I was thinking perhaps this is part of my problem. I don't think Cast Kodi is passing the n parameter, but I was assuming that the Youtube plugin was using the video id and scraping the HTML page to yank that parameter out. Is that not the case?

    Worth mentioning what Cast Kodi does is sends a plugin:// URL to the playlist.

    Youtube is deliberately throttling unofficial clients.

    There are some workarounds and alpha1/alpha2 versions of the plugin fixed it for me (although some are still reporting issues).

    Yeah it's still happening even with the alpha2 version for me, it's tough when I am vegging out watching retro computer videos from a playlist.

    The best UX for YouTube is Cast Kodi browser plugin, hardly ever use the addon's browsing features.

    Wow ... thats the solution ...

    use chroot = no (in Module section) works !!!

    Great, glad that worked for you.

    Technically this bug is with glibc-2.32 and could affect anything that uses a chroot without /proc mounted and tries to do lchmod on Linux, which is what rsync is doing. Doesn't look like the upstream glibc bug has made any movement.

    Created an issue on your behalf in LE's GitHub:

    [BUG] glibc-2.32 and later has a regression with lchmod when /proc is not mounted (such as a chroot) · Issue #5675 · LibreELEC/ · GitHub

    Okay, I post the rsync logs for two different systems ... one with LE 9.2.6 one with LE 10.0 ...

    As a workaround, can you set in your rsyncd.conf:

    use chroot = no

    And see if that makes any difference?

    Edit: Looking at the Fedora bug, it looks like "use chroot = yes" is the workaround. It's kind of confusing the way it is worded. But try both, I think "no" is the right option based on the Ubuntu description of the issue. My guess is this option is "yes" by default in rsync --daemon.

    The default systemd config was made stricter by default. For instance, ProtectHome=on (which hides content in /root and /home/USER dirs), ProtectSystem=full (which makes /usr, /boot, & /etc dirs read-only), and PrivateDevices=on (which hides devices). You can override any of these using the standard systemctl edit rsync and add one or more directives under a [Service] heading (and restart the rsync service).

    This may be relevant for you, it appears to be a bug with glibc 2.32 (which is what LE 10 is using):

    FS#69135 : [rsync] failed to set permissions on ... after update

    Newer glic versions provide a lchmod() that needs /proc mounted (their bug) · Issue #109 · WayneD/rsync · GitHub

    26401 – Regressions in lchmod and fchmodat when /proc is not mounted

    Arch is cherry picking these 2 commits on top of rsync 3.2.3, it seems:

    + # Force HAVE_LCHMOD off for Linux (for now).

    + git cherry-pick -n 85b8dc8abaca96fc3ea7421e09101b6ac41b6718

    + # Work around glibc's lchmod() issue a better way.

    + git cherry-pick -n 9dd62525f3b98d692e031f22c02be8f775966503

    Hmm ... I just imagine that I did a test upgrading from LE 9.2.6 to LE 9.95 but before disabling autoupdate for "network tools".

    After LE upgrade to LE 9.95 "network tools" (rsync v .104) where marked as "incompatible" !!!

    So there must be a change !!!

    Well it may be a newer version of rsync, so that's a possible change. You will probably need to look what version of rsync was running with 9.2.6, and go through the upstream rsync projects changelogs ( and documentation to see what new features were introduced that is affecting you. (network-tools 104 and earlier is rsync 3.1.3, 105 and later is rsync 3.2.3)

    Try using "log file" configuration directive and logging something may give you a hint what the issue is. Also, perhaps using strace or tcpdump to see if you can find out whether anything is actually getting to the daemon, and perhaps a basic "telnet" test to see if the port is open & responds, this is where I would start.