The following section is the next-up revision of the network attached storage transformation of the Axagon EE35-XA3 hard-drive chassis.

The Beelink T4 mini Pro is an excellent solution for a very quick deployment of a Servarr stack such as the minimal and complete Servarr stack especially because it has an Intel GPU that supports QSV thereby allowing the hardware transcoding of media. Unfortunately, the Beelink T4 mini Pro is limited to 4GB of RAM which seems insufficient for an extended stack. It is possible to cram everything in with ZSWAP but the resource consumption will be pushed to the limit. In any case, the result will be a good Servarr stack that won't be able to do much else except be a good media center.

The plan here is to extend the NAS into a "media gateway", a label for a self-configuring router that also acts as a media center for storing files ranging from documents to entertainment, such that the 4GB of the Beelink T4 mini Pro does not cut the project planning at all. Another consideration is that it would be nice to have some expansion capabilities, such as AP-mode WiFi with a large number of clients, which the Beelink T4 mini Pro cannot achieve with the built-in Intel wireless card given its client limitations. With that said, and with some of the hardware at hand, an Orange Pi 5 was used to transfer the NAS from the Beelink T4 mini Pro to the new "media gateway" format.

Unfortunately, working with the Beelink T4 mini Pro was easier because incidentally the power input for the Beelink was rated at whereas the Orange Pi 5 only takes . On the other hand, is not bad to have given that the Orange Pi 5 will be cooled by two fans that are also rated at and because plenty of hardware runs at .

There are some calculations to mind here, in particular, the maximum current intake that the Orange Pi 5 is rated at is , which, using Ohm's law, results in about that must be supplied by any stepdown DC-DC buck converter that would step to . However, is just for the Orange Pi 5, such that finding something with a little higher rating is much preferable.

A XL4015 rated at would suffice to power both the Orange Pi 5 and any other additional electronics that would have to be added. The XL4015's default schematic from the datasheet shows two adjustable points where the voltage and current can be chosen. For the XL4015, more is clockwise and less is counter-clockwise, as in more voltage or more amperes let though. The idea behind the XL4015 with a current limiter is not too bad because it implies a sort of fuse that will cut off supply current after a certain limit is reached. Ideally, the voltage should be chosen first using one of the adjustable screws, then all consumers should be connected to the XL4015 and using a screwdriver the current should be limited just to the the point where the XL4015 buck converter is about to cut off the current in order to achieve the fuse-like effect that will protect the circuitry in case of a short.

If you remember the previous design, the fan on the other side of the enclosure that is supposed to fan the hard-drive was mounted just above the chassis by using nylon spacers. However, there was plenty of space between the fan and the chassis such that any air pushed though by the fan would end up being spilled to the side.

The design wasn't too bad because fanning the chassis was a good idea as well but perhaps for this version something can be done about the spilled air and focus it onto the cut out hole in the hard-drive chassis.

A flexible solution has been to glue some rubber slices after being cut onto the fan sides in order to create a collimator that would focus the air onto the cut out hole. Using rubber instead of plastic seems to be a good choice because depending on the nylon PCB standoffs, the rubber has been cut to size in order to make sure that it covers all the distance from the fan to the chassis.

With the fan mounted onto the side of the chassis, the screws are tightened until the baffle rests onto the chassis itself thereby preventing air from escaping.

A double-fan piece was mounted on top of the Orange Pi 5 that was originally meant to cool down a hard-drive and connected to the power supply in order to blow cold air onto the Orange Pi. This is up to anyone's best guess and in principle a passive solution could also be chosen using a large radiator meant for the Orange Pi.

Fortunately, someone shot a thermal image of the Orange Pi 5 such that the heat distribution across the PCB can be observed (after 15 minutes of playing a video).

This looks like a mindful design with the heat almost being spread out uniformly across the board without any nasty peaks of heat. It seems that the peak temperature without any overheat mitigations reaches and given the Orange Pi 5 specification it seems that CPU throttling occurs over , which means that the Orange Pi 5 can run even without a heatsink given some notion of baseline mean-average usage. This mean that while the previous design that uses a two-fan assembly that is supposed to cool the board is ingenious, it is also a bit of a waste considering the thermal parameters of the Orange Pi sch that finding a more compact and less wasteful solution would be ideal.

One item that struck our interest was a full-body aluminum heatsink for the Orange Pi 5 that was very cheap on Amazon compared to the other solutions. very interestingly, it had one single review that, when translated, claims that the heatsink does not fit the Orange Pi 5 however that seemed highly suspicious given that the pictured aluminum heatsink seemed to have the notches spot-on matching the hardware ports on the Orange Pi 5. Also suspiciously incidental, the price for this item was half the price of similar heatsinks, with the next-up aluminium body going for 20 Euros which made us wonder whether the review was not … well, tactical.

We purchased the item after all and, lo and behold, the heatsink fits perfectly on the Orange Pi 5 such that the review is outright wrong when it mentions that the heatsink does not fit the Orange Pi 5. Clearly, the item does fit the Orange Pi 5 but the Orange Pi 5 is actually a series of boards, starting from the Orange Pi 5, then Orange Pi 5B, then Orange Pi 5 Plus, etc, such that it is even difficult to determine which board one has.

The heatsink fits top and bottom with screws sandwiching the board between a bottom plate and a top heatsink. The top heatsink is designed to sit on top of the chips on the board by using some heat-transfer foam blocks that are meant to be placed on top of the important chips. The bottom plate and the top sink are then screwed in place.

For some criticism, whilst the top aluminum sink is definitely going to do its job because it sits directly onto the chips, the bottom plate seems to be just a way to enclose the Orange Pi 5 but it cannot do much because it does not make any thermal contact with any component on the bottom of the Orange Pi 5. In fact, the bottom plate is a little annoying because the highest feature on the bottom of the Orange Pi 5 is the NVME slot, such that the bottom plate ends up just leaning against the NVME slot (made out of plastic, mind you) while being fixed into this position using the through-hole screws. Furthermore, even though the plates are painted though electrolytic galvanization, aluminum is still a conductive material and applying pressure onto PCB trace with protruding component connectors is most of the time a bad idea: just pressing onto the PCB might lead to a short that might burn out the board.

Another inconvenience that seems to be bad design, but admittedly, there is not much that could have been done to please customers that would not rework the product, is the fan that is supposed to be lodged into the aluminum top plate in order to push air along the crevices etched into the aluminum. As per the instructions of the producer, the fan is a fan that is supposed to be plugged into the Pi header connector in order to sap the necessary voltage, which is fairly bad because it will end up occupying two pins and hence not even allowing any extension to be placed on top. Nevertheless, as mentioned, for a "read to go"-product, solutions would seem moot given that the Orange Pi 5 does not offer any voltage breakout except on the Pi header.

An easy job, with a very pointy tip the existing cables are removed from the fan PCB and replaced with some tricks-of-the-trade pure-copper Ethernet wire in order to pull the leads out to the step-down. On the other hand, the blue thermal pads are preserved because they achieve multiple beneficial effects such as creating a common level due to their compressible nature as well as acting as heat conductors from the CPU and other chips to the aluminum heatsink. Initially, the idea was to toss away the blue pads as well and just use some thermal paste but the thought that the pads are compressible and would thus realize a flat surface regardless of the difference of height of the components, overruled the choice of throwing them away.

With that said, the bottom plate is discarded and kept in storage, whilst the top aluminum heatsink is screwed into the existing PCB standoffs onto which the Orange Pi 5 was initially mounted. The result is most satisfying because access to the Pi header is now restored, the build is much smaller than mounting the two hard-drive fans on top and the existing tall standoffs can even be used to mount a large PCB on top for some IoT and other extensions. Having further extensions in mind, the tall PCB standoffs are not removed.

Testing the performance of the new heat dissipating solution, it seems that the sensors report an average temperature of compared to the average temperature reported with the two hard-disk fans of . Intuitively, given the thermal distribution across the board, it seems that the fans did not manage to cool the board too well, either due to the distance between the PCB and the fans or maybe even because the PCB is so compactly designed that just blowing air on top of it is not that efficient.

The Orange Pi 5 has a Rockchip 3588 that delivers great performance and support for on-the-fly transcoding. Furthermore, having 8 cores to play with is also a great step-up from the Beelink T4 mini Pro. However, there are some drawbacks that will be mentioned here:

• The choice of operating system is a matter of preference and we'd have actually rather used the original Orange Pi vendor-supplies Chinese Debian image but for some reason the drive manager module that accepts encrypted targets is not compiled neither into the kernel nor separately as a module. You will find plenty of Internet searches and unanswered blog posts about dm-crypt.ko not being available as a module on the official Orange Pi Debian distribution and, unfortunately, aside from switching the Linux distribution there is no way to get LUKS encryption working. It was settled to use Armbian, a Linux distribution for ARM architectures that claims to be closest as possible to vanilla Debian and for what it is worth, it seems that it contains all the necessary firmware.
• The architecture on the Orange Pi 5 is Aarch64, which means that the Docker images provided either by Wizardry and Steamworks or the images from the minimal and complete Servarr stack or other official images might have to be rebuilt using the corresponding Dockerfiles or the containers will refuse to run.
• One big problem is that the Plex Media Server does not support Rockchip 3588 transcoding, which means that a switch to Jellyfin is necessary. Furthermore, in order to be able to transcode with Jellyfin within Docker, OpenCL and its requirement firmware blobs will have to be installed. After the requirements are installed, Jellyfin can be ran as a container using the following example SystemD file:

  [Unit]
  Description=Jellyfin
  After=docker.service
  Requires=docker.service
  StartLimitIntervalSec=0
  
  [Service]
  Restart=always
  RestartSec=5s
  ExecStartPre=/usr/bin/docker pull jellyfin/jellyfin:latest
  ExecStart=/usr/bin/docker run --name=jellyfin \
    --rm \
    --hostname jellyfin \
    --interactive \
    --user 0:0 \
    --privileged \
    --security-opt systempaths=unconfined \
    --security-opt apparmor=unconfined \
    --device=/dev/dri:/dev/dri \
    --device=/dev/dma_heap:/dev/dma_heap \
    --device=/dev/mali0:/dev/mali0 \
    --device=/dev/rga:/dev/rga \
    --device=/dev/mpp_service:/dev/mpp_service \
    -p 8096:8096 \
    -p 8920:8920 \
    -p 7359:7359/udp \
    -v /mnt/docker/data/jellyfin/config:/config \
    -v /mnt/docker/data/jellyfin/cache:/cache \
    -v /mnt/docker/data/cronicle/scratch/tv/:/cronicle \
    -v /mnt/archie/Books:/books \
    -v /mnt/archie/Music:/music \
    -v /mnt/archie/Movies:/movies \
    -v /mnt/archie/Shows:/shows \
    -v /mnt/archie/TV:/tv \
    jellyfin/jellyfin:latest
  ExecStop=/usr/bin/docker stop jellyfin
  ExecStop=/usr/bin/docker rm -f jellyfin
  TimeoutSec=300
  
  [Install]
  WantedBy=multi-user.target
  

  and then transcoding can be configured to use "Rockchip MPP (RKMPP)" within the Jellyfin → Dashboard → Settings → Playback → Transcoding section. A bit surprisingly but the transcoding feels superior to the Intel QSV of the Beelink T4 mini Pro by far, allowing quick searching within a watched stream like never before.

Some optimizations can be performed, in particular for the distribution itself in order to squeeze the most out of the Orange Pi 5. First, some kernel-level optimizations can be carried out by editing /boot/armbianEnv.txt and modifying the extraargs line to match the following:

extraargs="cma=256M mitigations=off zswap.enabled=1 zswap.compressor=zstd zswap.max_pool_percent=50 zswap.zpool=zsmalloc"

which will:

• disable any spectre and meltdown mitigations via mitigations=off (note that ARM architectures should be immune but it doesn't hurt to pass the variable anyway in case it toggles something within the kernel that would be suboptimal),
• enable ZSWAP in order to compress most pages stored in memory

Another parameter that is poorly named and that can be added to /boot/armbianEnv.txt is docker_optimizations=on that does not optimize anything in terms of performance but rather enables some quirks, such as control groups (cgroups) or Docker swap memory, that can be used to manage Docker containers better.