Stuart Naylor

I stopped tinkering for a while but https://magicmirror.builders/ perked my interest and been grinning at such a simple project and generally think its really great. I think they have made some odd options as the server and electron browser have been lumped together which is a really strange choice for absolutely no advantage. The server does need restarts and would seem far more often than you would expect and the use of electron means armv7l only which is a shame for the 0/1 owners. You can install using chromium and you certainly don't need the load of a desktop?! Dunno been wondering. I wanted to use a zero as love that tiny footprint and price and there are loads tutorials out there that seem to have much more than necessary and electron is chromium in a java wrapper with reduced architecture offerings so why no support? But hey. Not that bothered about that but why the have made the server and browser monolithic as a server restart now causes a cool device to display a desktop and even why desktop on a mirror has me scratching my head. https://github.com/StuartIanNaylor/MagicMirror-Install-Guide-Raspberry-0-to-3 if anything it will present a different take on the install as for some reason they depart from vanilla and I actually think it works better. Shame there isn't a Banana pi zero image or is there as loving that form factor. I do know it gets hot as hell but just tinkering by a tiny mind with tiny boards. PS if there is something near working give us a shout with Armbian and BPIZ

Great didn't know just me getting hissy with raspbian and zram-config_0.5_all.deb and didn't know. When you google zram-or search git-hub I missed any reference or the ability to grab it for raspbian. Wish you offered it as a standalone package as would of saved me quite a few hours Hey TK lzo or lz4 with zero I am finding lzo better if you have a bit more ooomf does lz4 make a better option? Dunno if you have one of your exhaustive tests anywhere? I have a banana pi zero here as having a brief love affair with that low end form factor but also seems no armbian that. Is that another lack of knowledge and misconception? Just had a look and that is great and your bash code is far more elegant than my hacks. Guys you should really release that to the wild as a standalone armbian package as its great. Only comment is zram_max_devs=${ZRAM_MAX_DEVICES:=4} as correct but there is no limit to stupidity and conversely shouldn't be either.

There was no intention really as not sure what you use just know the Armbian guys are often champions of lower end stuff. Its posted because often I see both Zram & Log2Ram but the init script of Zram comes after Log2Ram and there is no option to have Log2Ram on a compressed drive. Also there is no intention as its done but been playing with Pi Zero's and Raspbian and got annoyed with how much zram-config_0.5_all.deb sucks. There is a problem with separate installs as any logs of anything previous in the boot will be lost by the use of log2ram even log2ram struggles to gives logs and sends by Root mail. All linux versions come with zram but strangely the scripts for swap are often late in the boot and there is not a log2ram option to use it. Does Armbian give you a compressed Log2Ram drive? If not here is an option. You guys have prob got something better just my reaction to Raspbian and zram-config_0.5_all.deb as zram-config_0.5_all.deb sucks majorly. Its fixed at 50% of the ram for zram probably because the dev was trying to dodge floating point and never thought of using a factor and divide by 100. Also it applies is a zram cache for each processor which is relatively pointless for little cores and robs the big cores of precious ram swap. Didn't know you guys had something better but when I was googling for a compressed drive log2ram I spotted a couple of your articles. I assumed like many you where stuck with just zram-config_0.5_all.deb which I have hated with a passion for a long time and it has twizzled my nizzle that the simple addition of a compressed ram drive for log2ram isn't adopted. I messaged azlux on 'hey it would be cool to have log2ram on a zram drive' was impatient for a reply so gave an implementation example. Sent azlux another message just to grab and use whatever my branch may offer. If log2ram doesn't then you can that branch if you wish as maybe like me its bugged you that a simple config for zram and log2ram with zram drive doesn't exist. As I say no intention just me having a fit of frustration with Raspbian zram-config_0.5_all.deb and log2drive that totally miss some no brainer simple options. While I was at it I added the simple options for Zram factor, number of drives even if I have called in Big_Cores and comp_alg choice which for some reason often seem missing from choice and /etc options. I was going to ask you guys if there was any point in ext3 or if there is another alternative to get 1024k blocks maybe lower but actually not worth the install hassle of an extra partition. There is no big conspiracy as it is posted in general chit chat and at most that is its only intention.

https://github.com/StuartIanNaylor/log2ram/tree/log2zram git clone --single-branch --branch log2zram https://github.com/StuartIanNaylor/log2ram /etc/log2ram.conf says it all. # Configuration file for Log2Ram (https://github.com/azlux/log2ram) under MIT license. This configuration file is read # by the log2ram service Size for the ram folder, it defines the size the log folder will reserve into the RAM. If it's # not enough, log2ram will not be able to use ram. Check you /var/log size folder. The default is 40M and is basically # enough for a lot of applications. You will need to increase it if you have a server and a lot of log for example. # Above is log2ram original size increased to 80M zram. Assuming 3:1 LZO compression ram usage should be reduced to # 26.66M. Size is in MB SIZE=80 # This variable can be set to true if you prefer "rsync" rather than "cp". I use the command cp -u and rsync -X, so I # don't copy the all folder every time for optimization. You can choose which one you want. Be sure rsync is installed # if you use it. USE_RSYNC=false # If there are some errors with available RAM space, a system mail will be send Change it to false and you will have # only a log if there is no place on RAM anymore. MAIL=true # Big cores should only be counted really but this is where you can dictate zram stream count Default is 1 and settings # can be edited to personal taste. # BIG_CORES=0 Disables zram BIG_CORES=1 # Free mem factor deb is 505 I concur that 75 is better but its open. Free mem factor is just the fraction of # free mem used for swap drive total Drive size = Free_Mem * mem_factor / 100 / Big_Cores # So if you want .75 of total mem make mem_factor 75 as divided by 100 to avoid float usage MEM_FACTOR=75 # Compression algorythm either LZ0 or LZ$ COMP_ALG=lzo # ZLTG flag means use ZRAM ramdisk for log2ram true=enable / false=disable ZLTG=true # SWAP_PRI sets swap_priority of zram streams set by big_cores default=75 SWAP_PRI=75 Just gives you a bit more control than zram-config_0.5_all.deb but basically is just that and log2ram in a single package. Any issues tips or ideas give us a shout here or github

Many thanks but going to try and get a RK3399.

Aah cheers for the heads up as was staying clear of the pre-releases. You having no probs then as when I last tried pre xMas they where out of sync with Artful and not working at all. Looks like Ayufan is just supporting LTS as artful is now bionic which is prob wise. Shame as I was actually just running Kodi via X on its own but guess it will be april before anything solid. Guess I could try backporting from artful now that the xenial image seems a little more stable and get back to remembering what arm libs where missing from xbmc maybe not with artful.

Z-28 is prob more like RK3328 refererence design. Z-28 pro is prob more like Rock64.

Yeah puzzled by the community images as the git repo's seem to be there for the Rockchip graphics framework. Just trying to use libmali and get glamour going for X11 and sort of given in. The status matrix sort of looks like a solution can be compiled even though mainline is still a WIP http://opensource.rock-chips.com/wiki_Status_Matrix libmali-rk-utgard-2th-r7p0 - The mali library for Rockchip RK3328 (32bit) either doesn't like the kernel space driver or the xserver / mali / kernel is somewhere out of sink. Xorg & kernel logs don't tell me a lot apart from I bang out with a segmentation fault. [ 10.987] (II) xfree86: Adding drm device (/dev/dri/card0) [ 10.988] (II) no primary bus or device found [ 10.988] falling back to /sys/devices/platform/display-subsystem/drm/card0 [ 10.988] (II) LoadModule: "glx" [ 10.988] (II) Loading /usr/lib/xorg/modules/extensions/libglx.so [ 10.992] (II) Module glx: vendor="X.Org Foundation" [ 10.992] compiled for 1.19.3, module version = 1.0.0 [ 10.992] ABI class: X.Org Server Extension, version 10.0 [ 10.992] (II) LoadModule: "modesetting" [ 10.993] (II) Loading /usr/lib/xorg/modules/drivers/modesetting_drv.so [ 10.993] (II) Module modesetting: vendor="X.Org Foundation" [ 10.993] compiled for 1.19.3, module version = 1.19.3 [ 10.993] Module class: X.Org Video Driver [ 10.993] ABI class: X.Org Video Driver, version 23.0 [ 10.993] (II) modesetting: Driver for Modesetting Kernel Drivers: kms [ 10.994] (II) modeset(0): using drv /dev/dri/card0 [ 10.994] (WW) VGA arbiter: cannot open kernel arbiter, no multi-card support [ 10.994] (II) modeset(0): Creating default Display subsection in Screen section "Default Screen Section" for depth/fbbpp 24/32 [ 10.994] (==) modeset(0): Depth 24, (==) framebuffer bpp 32 [ 10.994] (**) modeset(0): Option "AccelMethod" "glamor" [ 10.994] (==) modeset(0): RGB weight 888 [ 10.994] (==) modeset(0): Default visual is TrueColor [ 10.995] (II) Loading sub module "glamoregl" [ 10.995] (II) LoadModule: "glamoregl" [ 10.995] (II) Loading /usr/lib/xorg/modules/libglamoregl.so [ 11.014] (II) Module glamoregl: vendor="X.Org Foundation" [ 11.014] compiled for 1.19.3, module version = 1.0.0 [ 11.014] ABI class: X.Org ANSI C Emulation, version 0.4 [ 11.014] (II) glamor: OpenGL accelerated X.org driver based. [ 11.049] (EE) [ 11.049] (EE) Backtrace: [ 11.049] (EE) [ 11.049] (EE) Segmentation fault at address 0x10 [ 11.049] (EE) Fatal server error: [ 11.049] (EE) Caught signal 11 (Segmentation fault). Server aborting But the kernel is loading and libmali-rk-utgard-2th-r7p0 is installed but is grabbing from the glx module Oct 6 04:19:00 rock64 kernel: [ 3.984499] mali-utgard ff300000.gpu: resource[4].start = 0x0x0000000000000013 Oct 6 04:19:00 rock64 kernel: [ 3.990333] mali-utgard ff300000.gpu: resource[5].start = 0x0x0000000000000014 Oct 6 04:19:00 rock64 kernel: [ 3.996105] mali-utgard ff300000.gpu: resource[6].start = 0x0x0000000000000015 Oct 6 04:19:00 rock64 kernel: [ 4.001815] mali-utgard ff300000.gpu: resource[7].start = 0x0x0000000000000016 Oct 6 04:19:00 rock64 kernel: [ 4.007480] mali-utgard ff300000.gpu: resource[8].start = 0x0x0000000000000017 Oct 6 04:19:00 rock64 kernel: [ 4.013018] D : [File] : drivers/gpu/arm/mali400/mali/platform/rk/rk.c; [Line] : 518; [Func] : mali_platform_device_init(); to add platform_specific_data to platform_device_of_mali. Oct 6 04:19:00 rock64 kernel: [ 4.019593] mali-utgard ff300000.gpu: Looking up mali-supply from device tree Oct 6 04:19:00 rock64 kernel: [ 4.021553] Mali: Mali device driver loaded Oct 6 04:19:00 rock64 kernel: [ 4.028062] ALSA device list: Oct 6 04:19:00 rock64 kernel: [ 4.033448] #0: HDMI Oct 6 04:19:00 rock64 kernel: [ 4.038635] #1: I2S Oct 6 04:19:00 rock64 kernel: [ 4.043777] #2: SPDIF Oct 6 04:19:00 rock64 kernel: [ 4.049603] Freeing unused kernel memory: 1152K (ffffff8008fb0000 - ffffff80090d0000) aint a clue to what D : [File] : drivers/gpu/arm/mali400/mali/platform/rk/rk.c; [Line] : 518; [Func] : mali_platform_device_init(); to add platform_specific_data to platform_device_of_mali. is supposed to mean mali450 but maybe that is just generic.

/usr/lib/dri/rockchip_dri.so just doesn't exist but not really sure if the xorg package is the xenial one or rockchip one. If it is the rockchip one then for some reason rockchip_dri.so isn't being built. On a startx it gives it a good go but always drops out to software rendering because its missing the above.

Yeah they have added a few new boards have you seen this one? https://www.aliexpress.com/store/product/Newest-arrive-Banana-PI-BPI-R2-Opensource-Router/302756_32823351577.html?spm=2114.12010608.0.0.412779ceyHOvoD http://www.banana-pi.org/r2.html https://www.cnx-software.com/2017/01/03/banana-pi-bpi-r2-router-board-powered-by-mediatek-mt7623a-quad-core-processor-comes-with-5-gbe-ports-sata-and-more/ https://www.phoronix.com/scan.php?page=news_item&px=ARM-Hardware-Linux-4.14 do you think we might actually get working software? https://www.phoronix.com/scan.php?page=news_item&px=Linux-4.14-rc2-Released Still slightly bemused as the RTD1296 is just a STB with Sata and still struggle to see the differentiation

@tkaiser Dunno all bananas & oranges to me and may it was the orangepi's that has a sata that really was just like the HC1 which was just a USB adapter in chip form on board. I remember your benchmarks and thinking yeap pants for sata. There is a single PCIe2.1 port on the RK3399 and I presume its a x4 hence the 4 lanes. The RK3399 does have supposedly a 2.1 x4 and there is only one way we will find out. "PCIe 2.1 (4 full-duplex lanes )" as the specs quote. Firefly used a x2 cost? I just dunno but was wondering if anyone had tested. Doh nope they split it into 2 ports one for m.2 and the other for LTE. So its got about 400Gb/s max raw as its PCIe1.0x2 So maybe your right as either its cost or it just can not do it.

You where not fooled for too long its just like the Odroid HC1 where its just a crappy usb3.0 to Sata bridge with banana's being off USB2.0 It is native and actually the RK3399 is interesting if someone actually goes beyond the Google/Rockchip reference design. The dev boards are practically the same as the chromebook versions. The reviews on the chromebooks in terms of performance for Arm are extremely good, but you could be right and how optimised those 4 5Gbs lanes are who knows. Anyone got a firefly and tried the sata expansion board and post any ioperf? Maybe those lanes are already taken with the raft of connectors on the 'reference' board? It would be interesting to get some real world figures on this thing.

http://www.ebay.co.uk/itm/HP-Proliant-N54L-Microserver-/272860806947 2nd user one that will prob accept an offer of £80

I would have a look at a Rock64 or oDroid almost a quarter of the RK3399 price. It would be great for someone to do a really good RK3399 dev board as it has 4 PCIe 2.1 lanes that seem untapped apart from sole use for LTE. I think the Firefly has a 2xSata - PCIe optional card dunno about videostrong as the SDK and software offerings are supposedly flakey at best. As a SoC the RK3399 is pretty amazeballs and sure its price will drop as more qty's are pushed, not sure about the dev boards though and don't think anyone has really cracked it. There are 2 RK3399 tv-boxes that do have Sata VorkeZ3 & Nagrace NT-V9 that are much cheaper than the dev boards but still pretty dear and best of luck with a linux image for them.

Yeah what is really interesting you got it working good job and +10 from me. Dunno about reboot but you have access to start hacking why. The ethernet "Mac address" change can be read about on the Rock64 forum as the early images where the same. The rock64 has 128Mb SPIflash which with my dodgy memory is where the mac is being stored but prob doesn't exist on the z28. Guess just hardwired mac address /etc/init.d/networking stop ifconfig eth0 hw ether 02:01:02:03:04:08 /etc/init.d/networking start or is it /etc/init.d/network stop ip link set eth0 address 02:01:02:03:04:08 /etc/init.d/network start I get all confussed what debian & ubuntu are using now. Or create a permanent entry in /etc/network/interfaces hwaddress ether 02:01:02:03:04:08 Apparently linux-image-4.13.0-rockchip-ayufan-130-g4f68418_0.5.13_arm64.deb will not load from eMMC but SD works prob due to the EVB inclusions in 4.12 dunno if that helps with those who are trying to load Linux.

Ram is a prob with the Pi http://docs.ceph.com/docs/hammer/start/hardware-recommendations/ so post on your findings. I agree about glusterFS extremeFS is actually active but using the Rock64 with 4Gb LizardFS seemed simpler than Ceph. I would get in there IRC chat and see what they say.

@rosimildo http://wiki.pine64.org/index.php/ROCK64_Main_Page#ROCK64_Software_Images has it with links to github. https://github.com/Raybuntu/LibreELEC.tv/releases has much done with the work from kwiboo, longchair & omegamoon The majority is inplace and they aim to have it complete for the introduction of Kodi Leia. http://linux-sunxi.org/Mali_binary_driver or https://developer.arm.com/products/software/mali-drivers PS did you guys just disable the eMMC? Is it an easy job as if SD0 doesn't exist it should boot from SD1 like on the Rock64 or is it more involved. The TV box that really interests me is the Bqeel MVR9 (NT-N9) as there is also a 4Gb version but finding it anywhere on sale apart from toaboa.com is another matter. The teardown specs look really good. https://www.cnx-software.com/2017/07/14/bqeel-mvr9-tv-box-review-part-1-specifications-unboxing-and-teardown/

I would have a look at the docker swarm modes and kubernetes as the pi has had a lot of work with them. Not sure to be honest as used to be pretty on the ball with Samba4 but lost track if they have failover clustering sorted presume they will have. Samba isn't the problem as that is just a share but the actual storage maybe DRBD https://en.wikipedia.org/wiki/Distributed_Replicated_Block_Device Have a browse through this blog https://fghaas.wordpress.com/ but I am starting to think a FS such as LizardFS or Ceph is a better option with newer distributed SoCs. https://medium.com/@bossjones/how-i-setup-a-raspberry-pi-3-cluster-using-the-new-docker-swarm-mode-in-29-minutes-aa0e4f3b1768

I would take a look at LizardFS as it is already in most mainline distro's and has a lot of support. I did a tour of many distributed filesystems weighing up pro's and cons from xtremeFS, Ceph to GlusterFS and GlusterFS came in low on the ratings chart. You can separate the chunk & metadata server into containers and start with a single device, it holds metadata in ram and is much faster than many. Its also the easiest to setup and admin and it does have mainstream distro support. The automation of failure and admin is provided by central commercial services of LizardFS where they provide enterprise datacenter grade services. I think its a prime candidate for a home / SoHo automated admin system that will not compete with LizardFS core commercial services. Needs something like Wi-Fi Protected Setup™ (WPS) where a device can be introduced to the cluster & storage pool by pairing with a NAC (Network Area Controller) and is as simple in use. The performance/cost ratio of SoC devices is unprecedented and singular monolithic server structures are dead in the water and the future is a distributed model. A whole retake on storage and usage needs to be taken as small fast local storage will work in parallel with relatively high latency bulk storage and its highly likely files like database files will not be on the same service layer as say media files or office documents and if you think about it its sort of ridiculous that it is. If its Kubernetes, Docker swarms matched with LizardFS, Ceph will depend on role of employment based on sector of use and likely to have different emphasis on how that sector uses devices & storage. The idea SoC NAS & Media centers are going to be mini singular versions of there historical higher cost x86 brothers is fairly bat shit crazy mad. We have hit a level of performance/cost in the sub $50 SoC which is just going to increase where extensible expansion is vertical in stacks and also horizontal as additional devices. This is from home to SoHo and there will be distro's and systems that encompass this and extensible expansion will be a case of JAA (just add another) From Kodi boxes, Alexa microphones, Home automation the modern home is full of devices which for a private lan distributed node count equates to performance. The 1gig ethernet backbone and high speed storage of the current new crop of SoC's is fit purpose for individual ownership and it is a paradigm shift in infrastructure to what has gone before and we are going to start seeing systems now and they are very likely to be opensource.

@Da Alchemist Have you tried raybuntu's libreelec as he has been grabbing and mixing some of the work done by Kwiboo, Longchair & omegamoon https://github.com/Raybuntu/LibreELEC.tv https://github.com/Raybuntu/LibreELEC.tv/releases/download/rb-krypton18/LibreELEC-ROCK64.arm-8.2-rb-krypton18.img.gz Thats a z28 & not pro which has more similar layout to the Rock64 and maybe would have the network, anyone with a pro given it a go? http://kszaq.libreelec.tv/sources/ssv6xxx-1041e7d.tar.gz?

Waiting for a Rock64 but the Z28 pro has been on my shopping list. Not sure as its the RK3328 that I think dictates boot from SD0 so not sure how the others are working. https://www.gearbest.com/tv-box-mini-pc/pp_640682.html?vip=2663187&gclid=EAIaIQobChMImaXhqt2r1gIVr7_tCh2_0QHUEAAYASAAEgL32fD_BwE is the 1 I have been eyeing up with 2gb 8gb rom. On the Rock64 if the eMMC isn't avail at sd0 then it will boot from the sd card at sd1 (I think) Not sure how you can maybe short out or disable the eMMC if you can then it will prob boot from SD card.

Guess question between Z28 or Z28 pro is Fast ethernet or Gig. If I was going armbian and tinkering then Z28 pro and presuming there is little difference between this and the Rock64? Kwiboo & Longchair have made great inroads with the rockchip VOP & MALI the LibreElec guys have almost got it cracked but they are aiming for Leia for completion but much is working already. https://forum.libreelec.tv/thread/4248-libreelec-krypton-leia-agile-build-for-odroid-c2-rock64-wetek-hub-wetek-play2/?pageNo=10 If you guys get armbian going on that for £26.25 wow that would be amazing bang for buck.

@TonyMac32 you just used transcoding as a delivery method it could of been IPFS where you have access to your file system. You could of just downloaded the file with asynchronous playback and enjoyed it at full quality. We might all be part of a P2P device network where location makes little difference We may get devices that can cluster and transcode to many but really what we seeing with devices all the way down to IoT are distributed autonomous devices. You where able to call up a video on your server because its based on a model of centralized high value, where the central hardware limits the qty of possible parallel trans-codes. Transcoding centrally for remote streams could be a dead duck but yeah it is still floating, the cheap silicon we are seeing might be the duck shoot. Maybe trans-coding was pushing the boundaries a little to far but what I was trying highlight with the whole storage argument we could be looking at a very different model. Processing be it trans-coding or not is adopting a decentralized model and these devices aggregate at much lower cost blur the lines of defined limits from centralized hardware. Your home setup is based on client/server infrastructure for many reasons with the Rock64 its a node and that is why network i/o is of prime importance. If you have a P2P network that maximizes infrastructure bandwidth then maybe you wouldn't need to transcode the Rock64 should not have any assumptions that it is a single gig Ethernet / single disk client device. It can offer a lot of bandwidth at low cost and for swarms that is gold and not using or testing that bandwidth is wasting it. Shouldn't of mentioned any specific technologies and stayed with the 'Thingy' and that cheap connectors are not really the importance of what 'Thingies' can do now or how they are employed or in the future.

When it comes to backup I am not sure we should be looking at any type of onsite service. http://sia.tech/ & https://storj.io/ are completely private p2p blockchain storage methods where we just keep private keys. Both offer interesting solutions that are disruptive technologies to current assumed storage methods. If you download the 3GB blockchain you could become a suppler & a consumer, but they are merely an example of vastly different ideas in resource sharing. Sia & Storj are maybe just the start in P2P storage where depending on timeslot, bandwidth, store size you vastly reduce costs by offering sections of free space. Also I think trans-coding centrally is another dead duck as the RK3328 has and extremely capable VPU. Why need the process power to transcode multiple streams? 4k is 66-85 Mbps, 1080p is 15 Mbps, source is chosen for devices employed but even 4k can be transcoded locally by extremely humble devices now. Cables & Barrel jacks are not part of an OS, its seriously doesn't matter about physical connectors purely the bandwidth and manners to employ it. Decentralised storage has physical storage in decentralized locations but is presented and acts exactly the same as a centralised store. Because its decentralized bandwidth is partitioned over the amount of devices it compromises of and the connections that gives. There are various FUSE / Union file systems that can use decentralized storage units and pool as a centralised store that with technology such as the RK3328 is more than capable for home requirements with the right balancing mechanisms. Storage could be home P2P network swarms, http://www.xtreemfs.org/, it could be Aufs with individual files stored on network shares over a round robin policy. Redundancy could be blockchain storage of Snapraid parity files who knows what crazy ideas might take place. Those technologies are purely choice and all I am saying is if a device has the possibility of bandwidth then that should be explored to its maximum. Armbian should always be tweaked so it can take full opportunity of maximum performance and bandwidth based on the limits of the best power supplies & cabling available. You shouldn't be limiting your scope of involvement on the assumption of the cheapest imports available. I will leave you with this to think about a RK3328 device could be a Falcongate router firewall appliance, could be a volumio appliance, kodi, webserver and many more. Each appliance could have local storage that is shared across all devices and pooled with other device storage, that is backed up to a bockchain cloud that is subsided by your own free space. Some devices might have higher bandwidth and connections that can be utilized, hence why I mentioned about a 2nd USB gig Ethernet and port trunking. There are switches for £50 and less that can do gigabit LACP, there is 30Gb 200MB/S SSD for £15, 60GB 300MB/S for £25 as an example of cheap high bandwidth drives. There are hybrid drives and raid units that have cost and bandwidth that fit with the maximums of the RK3328 and should be explored irrespective of possible defects and quality of source. Armbian just needs to be an tried and tested and optimized OS that can meet this demands and more. A cheap usb ssd or raid0 stripe would be needed to match the network throughput and maybe should be tested and optimised irrespective of external concerns. https://tahoe-lafs.org/trac/tahoe-lafs, https://www.resilio.com, https://syncthing.net/, https://librevault.com/ ...