ari_verse

ASUS NUC 15 Pro Barebone Desktop PC - Black (Intel Core Ultra 5 225H/Intel Arc 130T Graphics)

For people installing Linux on this hardware, PSA: the ethernet controller uses the I226-V chipset (igc kernel driver) and, out of the box, has a severe problem: TCP connections downstream are limited to just around 40Mbps regardless of the ethernet port speed. Eg. I connect it directly to gigabit switch and was initially confused to see that download speed was terrible in this otherwise powerful little machine. speedtest-cli shows 35Mbps, terrible.

When I tested iperf3 locally with 20 simultaneous connections, I could see that the downstream could fill the 1Gbps pipe. Then testing iperf3 with just one connect, the speed slows down to about 40Mbps. Bizarre.

Two solutions:

• Disable PCIe ASPM in BIOS/UEFI. This works fine, speedtest-clie went up to 900Mbps, but also had a consequence in CPU temps, NVME temps and power consumption. Not terrible, some 6 C degrees, and some 5 Watts on average.

I monitor this box closely, it's my new home server / HTPC. It runs 24/7 homeassistant, frigate, a bunch of other docker containers, kodi flatpak, retroarch flatpak etc.

My solution: enable ASPM globally in UEFI (the default), but disable it for the I226-V after boot:

# find the address of the controller
#   sudo lspci -vv | grep -i ethern                                                                                                                                   
#    > 57:00.0 Ethernet controller: Intel Corporation Ethernet Controller I226-V (rev 04)
# then at boot do:

sudo setpci -s 57:00.0 CAP_EXP+10.w=0000

I'd think one needs a half decent car to be able to show speed. Or do the comparison with his peer in the team. For the former he showed something with Williams. For the latter, he is not far from Gasly, with a decade less experience. But yes clearly a rookie and a lot to learn

Albornoz, what a player!

This project shows a lot of promise and I am following it. I run HomeAssistant as well in my home server. At this time though (or:last time I checked) it didn't support cuesheets at all, it fell a little short for my use case.

For doing Kodi GUI setup changes in a headless setup in the RPis remotely, I use a VNC server installed in them that I start on-demand (when needed), e.g dispmanx. Needing this is a once-in-a-few-years type event, but yes you need this installed just in case.

My use case: collection based on single-flac + cuesheets, thousands, many of which are HD. Setup: all the music is in an NFS share in my HTPC, which also runs Kodi (flatpak) for both video and audio media. That machine is connected to my main audio setup via USB DAC.

The Kodi music DB is hosted externally in mariaDB in the same server. I use 2 headless Kodi (OSMC) clients with HiFiBerry DACs as streamers around the house, using the same DB/media. Lastly I also have an Nvidia Shield running Kodi also exposing the same collection/DB.

Over the years I have tested many alternatives, including navidrome, volumio, and others, but they all struggle handling my music collection, choke processing cuesheets or don't even support them, or can't handle NFS reliably or at all, or can't process 24 bit content etc.

I couldn't find any solution nearly as reliable, performant or flexible as this one. I use this setup pretty much daily. With incremental improvements, it's been running for more than 10 years.

Each Kodi client can be managed via its web interface (a little dated but fully functional and reliable), amd via Android app (I use Yatse).

The main server also exposes the music collection via DLNA.

I looked at jellyfin/Plex in the past as well but for muy use case, it's over-complicated and didn't add value.

Colapinto saved his head possibly. Good for him resisting all the pressure

"Loco" but with such a cjnsustent, deep method. Scientist

It would be nice to see a Bielsa masterclass. Trainer of trainers

Fair comment, I should qualified my answer: I use an ssh tunnel with auto-reconnect option, wrapped inside a systemd service. In all this years, I still have to run into a problem that wasn't external (server down, no internet at home etc) I agree that wireguard is the proper solution however it requires a lot of extra configuration and support in both ends, which now is prevalent but not so much 5+ years ago. Also for a single port solution, ssh is so much simpler, practical and reliable, you only need an ssh user at the other end.

ExecStart=/usr/bin/ssh -NT -o ServerAliveInterval=60 -o ServerAliveCountMax=3 -o ExitOnForwardFailure=yes -R localhost:YOUR_PORT:localhost:YOUR_PORT SOME_USER@YOUR_SERVER

This. Using simple ssh tunneling with port forwarding in a similar scenario. Working flawlessly with zero maintenance for 5 years and counting. Very reliable

Sorry my mistake. Real person here. Yes just joined lemmy.ca, I am a Lemm.ee refugee.