Posts by frakkin64

Quote from JurKub

I don't think the Ethernet port is the issue, because using NFS for recording and Samba for replay at the same time everything woks fine

OK, so speculation it is then. This is where my part in the conversation ends. Good luck.

Quote from JurKub

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 bcmstat.sh on your Pi to get more insight? I would run it with: "bcmstat.sh 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

You have to grow the filesystem as well.

resize2fs /dev/sda2

Quote from JoeAverage

disagreed

You are the one who asked for comments, but if you think argumentative is the way to go then good luck with that.

Quote from JoeAverage

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.

Quote from pcihlar

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:

From e1104fe28c020339899f6814f1ab62b25d1778fd Mon Sep 17 00:00:00 2001
From: Chad Wagner <[email protected]>
Date: Mon, 14 Jun 2021 20:42:17 +0000
Subject: [PATCH] rtl8822bu: add driver

---
 distributions/LibreELEC/options             |  2 +-
 packages/linux-drivers/RTL8822BU/package.mk | 29 +++++++++++++++++++++
 2 files changed, 30 insertions(+), 1 deletion(-)
 create mode 100644 packages/linux-drivers/RTL8822BU/package.mk

diff --git a/distributions/LibreELEC/options b/distributions/LibreELEC/options
index 837e38076c..605a985019 100644
--- a/distributions/LibreELEC/options
+++ b/distributions/LibreELEC/options
@@ -48,7 +48,7 @@
 # for a list of additional drivers see packages/linux-drivers
 # Space separated list is supported,
 # e.g. ADDITIONAL_DRIVERS="DRIVER1 DRIVER2"
-  ADDITIONAL_DRIVERS="RTL8192CU RTL8192DU RTL8192EU RTL8188EU RTL8812AU"
+  ADDITIONAL_DRIVERS="RTL8192CU RTL8192DU RTL8192EU RTL8188EU RTL8812AU RTL8822BU"
 
 # Default size of system partition, in MB, eg. 512
   SYSTEM_SIZE=512
diff --git a/packages/linux-drivers/RTL8822BU/package.mk b/packages/linux-drivers/RTL8822BU/package.mk
new file mode 100644
index 0000000000..7ce0b665e6
--- /dev/null
+++ b/packages/linux-drivers/RTL8822BU/package.mk
@@ -0,0 +1,29 @@
+# SPDX-License-Identifier: GPL-2.0-or-later
+# Copyright (C) 2009-2016 Stephan Raue ([email protected])
+# Copyright (C) 2018-present Team LibreELEC (https://libreelec.tv)
+
+PKG_NAME="RTL8822BU"
+PKG_VERSION="24a1067268b90e977a15dd94d4674dc7c6fafa6d"
+PKG_SHA256="55273add2c5a1ab292548369df8045287a6744a89eb7a67c04a09c02780dfb4b"
+PKG_LICENSE="GPL"
+PKG_SITE="https://github.com/morrownr/88x2bu"
+PKG_URL="https://github.com/morrownr/88x2bu/archive/${PKG_VERSION}.tar.gz"
+PKG_LONGDESC="Realtek RTL8822BU Linux driver"
+PKG_IS_KERNEL_PKG="yes"
+
+pre_make_target() {
+  unset LDFLAGS
+}
+
+make_target() {
+  make V=1 \
+       ARCH=${TARGET_KERNEL_ARCH} \
+       KSRC=$(kernel_path) \
+       CROSS_COMPILE=${TARGET_KERNEL_PREFIX} \
+       CONFIG_POWER_SAVING=n
+}
+
+makeinstall_target() {
+  mkdir -p ${INSTALL}/$(get_full_module_dir)/${PKG_NAME}
+    cp *.ko ${INSTALL}/$(get_full_module_dir)/${PKG_NAME}
+}
-- 
2.33.1

Quote from sunny

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.

Quote from twilightened

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.

Quote from ProTofik

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,…

www.amazon.com

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 https://github.com/morrownr/88x2bu (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.

# iperf3 -c 192.168.0.1 -R
Connecting to host 192.168.0.1, port 5201
Reverse mode, remote host 192.168.0.1 is sending
[  5] local 192.168.0.40 port 40228 connected to 192.168.0.1 port 5201
[ ID] Interval           Transfer     Bitrate
[  5]   0.00-1.00   sec  27.0 MBytes   226 Mbits/sec
[  5]   1.00-2.00   sec  32.8 MBytes   275 Mbits/sec
[  5]   2.00-3.00   sec  33.6 MBytes   282 Mbits/sec
[  5]   3.00-4.00   sec  33.6 MBytes   282 Mbits/sec
[  5]   4.00-5.00   sec  33.6 MBytes   282 Mbits/sec
[  5]   5.00-6.00   sec  33.6 MBytes   282 Mbits/sec
[  5]   6.00-7.00   sec  32.6 MBytes   274 Mbits/sec
[  5]   7.00-8.00   sec  33.1 MBytes   278 Mbits/sec
[  5]   8.00-9.00   sec  33.5 MBytes   281 Mbits/sec
[  5]   9.00-10.00  sec  33.6 MBytes   282 Mbits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.01  sec   330 MBytes   277 Mbits/sec   27             sender
[  5]   0.00-10.00  sec   327 MBytes   274 Mbits/sec                  receiver

iperf Done.

Quote from ProTofik

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">
    <cache>
        <buffermode>1</buffermode>
        <memorysize>262144000</memorysize>
    </cache>
</advancedsettings>

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.

Quote from popcornmix

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.

Quote from popcornmix

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.

Quote from bg.lebowski

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/LibreELEC.tv · GitHub

Quote from bg.lebowski

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.

Quote from heitbaum

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

Quote from bg.lebowski

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 (https://download.samba.org/pub/rsync/NEWS) 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.

Ahh, your using rsyncd service (port 873). I am tunneling rsync over ssh (might want to see if Synology has that as an option). The official LE addon that I am using doesn't have a service option only console tools (network-tools addon). Not aware of a service add-on, if one existed prior to LE-10. The only other thing that comes to mind is perhaps you are following these instructions (or similar) to setup rsyncd as a service?

Personally, I would use rsync over ssh, it's a lot less hassle than running rsync as a service.