Did you reboot, or logout and log back in via ssh? If yes, then check if the rsync executable exists in /storage/.kodi/addons/virtual.network-tools/bin/.
The path is set by /etc/profile.d/*, so it requires a relog and/or reboot depending on how you are using the rsync executable for it to be in the system PATH.
rsync works fine on LE 10.
I thought I got a good deal on ebay for $75, but I just realized that the official RaspberryPi site
CanaKit is another good option for the US as well, I think they are Canada based. But I have gotten good deals from their Amazon store, better than their direct store.
v6.8.17 was released, which resolves the issue. Expect it would be available in the addon repositories soon.
I use "dtoverlay=disable-wifi" at the bottom of /flash/config.txt to disable on-board Wi-Fi.
Bluetooth can be disabled with addition of "dtoverlay=disable-bt", however I have not used it on LibreELEC. Not aware of anything to disable the on-board ethernet via dtoverlay's.
Well,
it all happened again. Disconnections are way less frequent, but intrestingly, it looks like I lose connection when I am playing a video while it's been recorded. The server keeps recording and storing the video to the NAS but the client cannot connect to the server anymore.
During August I will play with different configurations
Goes back to one of my early points, specifically about saturating the SDIO bus with the built-in WiFi. The built-in Wi-Fi is not usable for HD playback & recordings on the Raspberry Pi, in my opinion.
I would suggest plugging in an ethernet cable, or moving your video recording to a machine that is on your network. I don't know what encoding or bitrates & resolutions your recordings are, but HD 1080p MPEG2 can run around 20Mb/s and probably higher for some scenes. I could see this easily saturating your SDIO bus and causing timeouts with WiFi, especially if your recording a few channels and playing back video.
I think trying to make it "reconnect faster" is a poor solution to your problem, the fact that you made this script is generally a bad idea. You should resolve the cause of the disconnects.
I think from the earlier posts you have heard stories of various issues that cause WiFi drop outs, and in fact if you check the Raspberry Pi forums you will find many more, but to recap:
- HDMI causes interference in the 2.4GHz band (known to affect WiFi channel 1, maybe BT?), firmware fix AFAIK. Never an issue for me, but I wasn't an early adopter.
- USB3 causes interference with on-board Wi-Fi, no idea if this is still a thing or not but the RPi4 has 3 firmwares to my knowledge (Bootloader, USB, and Wifi/BT).
- BT itself has interference issues with WiFi on the same chip, think there was firmware fixes & parameter changes to address it.
- People have reported USB hubs or other devices being too close as the cause interference with WiFi.
- Perhaps your tuner HAT is causing the issue, no idea, don't have one.
That tells me you want to get on the latest software available for the platform with all of the firmware patches possible. You could have kernel related issues, or SDIO bus saturation which may manifest as problems as well [hard to know unless you can quantify your wireless performance at the time of the drop outs -- i.e. how much data is being sent/received]. So I think either running LE 10 or testing out a recent update of Raspberry Pi OS may help. It might also be worthwhile to poke in on the Raspberry Pi Forums and see if the engineers respond with any insight on your issue, a few of the Raspberry Pi engineers occasionally check in on issues and will reply.
As I mentioned earlier, I am running a similar setup, RPi4, Tvheadend client, Kodi 19.1 (LE 10b5), and have zero issues. Even before I bought a $15 USB dongle, it managed fine with a larger cache. No wireless drop outs, ever.
As a side note, your incorrect about the buffermode. 4 is the default, which means remote only, you want 1:
#define CACHE_BUFFER_MODE_INTERNET 0
#define CACHE_BUFFER_MODE_ALL 1
#define CACHE_BUFFER_MODE_TRUE_INTERNET 2
#define CACHE_BUFFER_MODE_NONE 3
#define CACHE_BUFFER_MODE_REMOTE 4
I don't think remote includes "sources", so this is something you might want to check is working right. There is a visual cue on the playback progress bar of the caching.
Anyways, good luck.
ciclista71 This post may help you with updating the firmware:
Basically what I read is you create a folder "/storage/.config/firmware/brcm/" and plop the 3 files you mentioned earlier in there. Reboot, check dmesg if the version reported is updated. If it doesn't work or creates more problems then just remove the files from that location.
Only catch is if the firmware is paired with any other components (like the kernel for example). I would have no idea, and hope that they make it backwards compatible.
I would just buy a USB dongle, and roll your own image, or find one that is already supported by LE 9.2.6. The on-board Wi-Fi is frankly useless if your using this for playing back FHD or higher media, and to make it work you will need to create a nice fat cache to smooth you through the high bit-rate scenes.
I was just doing regular 1080p playback over the on-board Wi-Fi with Pi4, and on high bit-rate scenes kworker queues would consume 30% of CPU, and the SDIO bus was totally saturated, and the result was hangs, freezing, NFS read errors, etc. (Never wireless drop outs). I ended up doing 3 things, 1) buying a TP-Link T3U USB dongle, 2) building my own images with Realtek RTL88X2BU drivers, 3) bumping the cache:
<advancedsettings version="1.0">
<cache>
<buffermode>1</buffermode>
<memorysize>524288000</memorysize>
</cache>
</advancedsettings>The cache is probably a bit excessive at 512M, but it buffers 2~3 minutes of FHD video and smooths out high bit-rate scenes. This I did before #1 & #2 and resolved my issues with stuttering and NFS read errors. I ended up doing #1 & #2 after, because eventually I might run UHD videos, and that will give me ~260Mbps transfer rates, which should be plenty hopefully (YouTube is suggesting 85Mbps for 60fps 2160p HDR).
What version of LE are you running? It sounds pretty old to have a firmware from 2018. The reason I mention it is older versions of the firmware were not capable of connecting to 80MHz channels. There are also co-existence issues with WiFi & BT, and hardware interference issues with HDMI, as far as I know these were addressed through various firmware fixes, but most of those issues affect the 2.4GHz band from what I recall. The other issue because the SDIO bus is the bottleneck, if you are saturating that 80Mbps bus then you might see various timeouts like WPA supplicant is telling you, I think the timeout for scheduled scan is 2 seconds.
I think, not certain, you would have to build your own image from source. From what I can tell it is part of the system image which is mounted via a loopback squash filesystem.
Another things that I have noticed is that the maximum speed it gets at 5Ghz is 140Mbps
Is your RPi overclocked? 140Mbps is impressive if that is an actual tested transfer rate with iperf3, since the on-board wireless on RPi4 is gated by the SDIO bus which is normally running at 41.6MHz clock rate w/ 4-bit bus, so at half-duplex your theoretical maximum is around 160Mbps. In my experience, I couldn't get more than 80Mbps on a 5GHz band with 80MHz bandwidth. Most people I have seen reporting actual numbers get 80Mbps, and maybe 110~120Mbps with overclocking (because I believe it bumps the SDIO bus clock rate, as it is using a frequency divider of the core clock rate).
I guess this is one of the design tradeoffs of the RPi4 to maintain a certain cost point. I personally ended up buying a 802.11ac USB dongle and can pull 260Mbps similar to my other devices. (Which I have read is about typical for 802.11ac).
I also presume you are looking at the link rate of 867Mbps, which isn't the actual speed in reality. I would suggest using iperf3 to test actual speeds, but it sounds like to me you are stating link rates.
I am using Hauppauge_WinTV-quadHD_(ATSC_ClearQAM) on Ubuntu 20.04, works perfectly, never had an issue with it. Drivers are available in 5.4 kernels and later. Tvheadend has no problems recognizing it and serving it to Kodi on LibreELEC.
This is of course the ATSC version of the card you noted.
Netflix works fine on LibreELEC 10 Beta. You have to download the repository ZIP file for Matrix and install from ZIP.
GitHub - CastagnaIT/plugin.video.netflix: InputStream based Netflix plugin for Kodi
I also believe Amazon is working, but don't personally use it.
This seems to be a resource leakage to me, but I am not sure since I am unfamiliar with how this works. Running on an RPi4, LibreELEC 9.95.2, and generally navigating through the library will create additional entries in pmap for /dev/dri/renderD128. Typically they are 4K pages. I believe it is related to thumbnail rendering, but not sure.
Is this normal? They never seem to go away. I tend to start out with ~100, and then after some browsing through the library end up with 2K-3K of these entries in pmap.
00000000a6f9b000 256 256 256 0 rw-s /dev/dri/renderD128
00000000a6fdb000 256 256 256 0 rw-s /dev/dri/renderD128
00000000a701b000 256 256 256 0 rw-s /dev/dri/renderD128
00000000a705b000 256 256 256 0 rw-s /dev/dri/renderD128
00000000a70ab000 36 36 36 0 rw-s /dev/dri/renderD128
00000000a70b4000 36 36 36 0 rw-s /dev/dri/renderD128
00000000a70c7000 36 36 36 0 rw-s /dev/dri/renderD128
00000000a70d0000 36 36 36 0 rw-s /dev/dri/renderD128
00000000a70d9000 36 36 36 0 rw-s /dev/dri/renderD128
00000000a7228000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a7229000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a722a000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a722f000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a7236000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a7237000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a7238000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a7239000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a723a000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a723b000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a723c000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a723d000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a723e000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a7240000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a7241000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a7242000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a7243000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a7249000 32 32 32 0 rw-s /dev/dri/renderD128
00000000a7270000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a7287000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a7288000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a7292000 12 12 12 0 rw-s /dev/dri/renderD128
00000000a7295000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a7296000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a7297000 4 4 4 0 rw-s /dev/dri/renderD128
00000000a7298000 12 12 12 0 rw-s /dev/dri/renderD128It's beta in the sense that some of the video pipeline is not fully flushed out, but it's highly subjective to your use case & media setup. The latest nightly is running smooth for everything I need. But I think your issue is probably because you upgraded, when they are asking users to do fresh installs. Most of the posts I have seen with folks upgrading run into problems with skins & addons, which is more to do with the skin & addon authors than anything else.
The warnings are all over the blog post, and Forum post, but it sounds like you missed that.
You will need to download & install the ZIP file to point to the Matrix repository, the author has 2 separate repositories and you have to manually switch after upgrading to Matrix.
Install add-on via repository - provide automatic installation of updates:
The matrix version of the add-on works fine with 9.95.2 for me.
strange works for me with network tools installed O_o
Same here, have network tools addon installed, works fine without any extra arguments. rsync is in the PATH, you might need to logout/login or perhaps reboot after installing the addon?
LibreELEC (community): nightly-20210502-8f609ae (RPi4.arm)
htpc-livingroom:~ # which rsync
/storage/.kodi/addons/virtual.network-tools/bin/rsync
htpc-livingroom:~ # echo $PATH
/usr/bin:/usr/sbin:/storage/.kodi/addons/virtual.network-tools/bin
Syntax isn't quite right. This is what I do:
rsync -av --delete -e ssh [email protected]:/path/to/stuff/ /where/you/want/to/put/it/
