Jason Fisher

I made a custom Plex Media Player build that leverages the decent performance we get with the fbdev/dri driver.
I tested Rockchip MPP gstreamer plugin.   The Rockchip Hardware VPU is very basic, it breaks with mkv playback, so I decided to use ffmpeg software decoding since it's extremely robust. Also 1080p playback through DRI isn't too shabby!.  If you want 4k video then you need to contact Rockchip.   They seem to be overwhelmed or not interested in bringing 4k support to Linux.   I built a .deb package that will install plexmediaplayer to /usr/local.  No worries about installing to somewhere and clobbering an official library or package.    Official Armbian dependencies will be installed to the proper location.  The plexmedia web-client will be installed to /usr/local/share/plexmediaplayer, the Qt5 binary will be installed to /usr/local/bin/plexmediaplayer
 
install with:
gdebi plex-media-player-install.deb
 
remove with:
apt-get remove plex-media-player-installer
 
To fix the installer package I basically reflashed my NanoPC-T4 with a clean Armbian image,  printed out the errors.
Updated the Debian control file with all the proper dependencies.  
 
Here's the binary install package.  
 
 
 
If you get a dependency error you can use the --ignore-depends dpkg argument and resolve after the install.
The files are installed in an easy location to clean up. 
plex-media-player-install.deb

After fighting with this with a few distros..  I am close here:
 
1. First, go to your linux-headers directory (e.g. /usr/src/linux-headers-4.4.129-rk3328/) and:
 
make scripts
 
If that fails (classmap.h missing for example), there is a problem with the headers package.  You may need to manually edit scripts/Makefile and comment out the line with selinux -- there is a problem with the kernel config not matching the header deb in my case.
 
# subdir-$(CONFIGS_SECURITY_SELINUX) += selinux
 
2. From the same headers directory, verify that include/generated/utsrelease.h matches the full kernal name from: uname -a
 
- My headers (from beta repo) had 4.4.129 as utsrelease.h and 4.4.129-rk3328 as the kernel version/release.  This causes modules to be built incorrectly and their vermagic to not match--you can use modprobe --force to get around this, but ill-advised to use that for more than a quick test with something like zfs.  My utsrelease.h now reads: 4.4.129-rk3328
 
3. Edit /var/lib/dkms/spl/<yourversion>/source/configure and search for KUID, for lines that look like this:
 
kuid_t userid = KUIDGT_INIT(0);
kgid_t groupid = KGIDT_INIT(0);
 
Erase those two lines, the test itself is broken on our environments.  Leave the lines surrounding it.  These appear twice in the configure script--remove both sets.   
 
Now look for these lines:
 
kuid_t userid = 0;
kgid_t groupid = 0;
 
Change them to:
 
kuid_t userid;
kgid_t groupid;
 
(I filed a bug here https://github.com/zfsonlinux/spl/issues/653#issuecomment-333973785 )
 
Now you can run:
 
dkms build spl/<yourversion>
dkms install --force spl/<yourversion>
modprobe spl
# should be no errors here, check dmesg otherwise
 
dkms build zfs/<yourversion>
dkms install --force zfs/<yourversion>
 
When configure runs, you should now see:
checking whether kuid_t/kgid_t is available... yes; mandatory
 
Some notes:
 
- I ended up switching to beta (sources.d) and doing an update/upgrade/dist-upgrade first because there were no kernel headers for the WIP rock64 image I installed.
 
- If you use kernel 4.11.x you will need to use SPL/ZFS 0.7.x.  I am using the standard zfs-dkms/spl-dkms 0.6.5.9 packages for now..  install SPL and let it fail, then dkms install it after the steps above and then install the ZFS package.
 
Just started with Armbian today .. in retrospect it looks like it has drawn me in..
 

After fighting with this with a few distros..  I am close here:
 
1. First, go to your linux-headers directory (e.g. /usr/src/linux-headers-4.4.129-rk3328/) and:
 
make scripts
 
If that fails (classmap.h missing for example), there is a problem with the headers package.  You may need to manually edit scripts/Makefile and comment out the line with selinux -- there is a problem with the kernel config not matching the header deb in my case.
 
# subdir-$(CONFIGS_SECURITY_SELINUX) += selinux
 
2. From the same headers directory, verify that include/generated/utsrelease.h matches the full kernal name from: uname -a
 
- My headers (from beta repo) had 4.4.129 as utsrelease.h and 4.4.129-rk3328 as the kernel version/release.  This causes modules to be built incorrectly and their vermagic to not match--you can use modprobe --force to get around this, but ill-advised to use that for more than a quick test with something like zfs.  My utsrelease.h now reads: 4.4.129-rk3328
 
3. Edit /var/lib/dkms/spl/<yourversion>/source/configure and search for KUID, for lines that look like this:
 
kuid_t userid = KUIDGT_INIT(0);
kgid_t groupid = KGIDT_INIT(0);
 
Erase those two lines, the test itself is broken on our environments.  Leave the lines surrounding it.  These appear twice in the configure script--remove both sets.   
 
Now look for these lines:
 
kuid_t userid = 0;
kgid_t groupid = 0;
 
Change them to:
 
kuid_t userid;
kgid_t groupid;
 
(I filed a bug here https://github.com/zfsonlinux/spl/issues/653#issuecomment-333973785 )
 
Now you can run:
 
dkms build spl/<yourversion>
dkms install --force spl/<yourversion>
modprobe spl
# should be no errors here, check dmesg otherwise
 
dkms build zfs/<yourversion>
dkms install --force zfs/<yourversion>
 
When configure runs, you should now see:
checking whether kuid_t/kgid_t is available... yes; mandatory
 
Some notes:
 
- I ended up switching to beta (sources.d) and doing an update/upgrade/dist-upgrade first because there were no kernel headers for the WIP rock64 image I installed.
 
- If you use kernel 4.11.x you will need to use SPL/ZFS 0.7.x.  I am using the standard zfs-dkms/spl-dkms 0.6.5.9 packages for now..  install SPL and let it fail, then dkms install it after the steps above and then install the ZFS package.
 
Just started with Armbian today .. in retrospect it looks like it has drawn me in..
 

Just wanted to confirm that everything is working well with ZFS here on ARM64.  Successfully running two MediaRAID 8x eSATA/USB3 enclosures off of a USB3 hub, 16 drives/20TB .. 10+ year old raidz2 pools that has moved between a dozen machines .. VM under Windows, Mac, Linux .. adozen controllers (PMP SATA, eSATA, USB3) survived 7 total drives dying, no data loss.  4GB RAM is plenty for media streaming -- 2.6GB RAM was fine with some tuning (VM in Windows that ran Plex and shared ZFS back to host).
 
Benchmarks eventually .. but downloading with sabnzbd/sonarr, using Chromium, and streaming 1080p to Plex at just under 3GB RAM in use.

I posted my ZFS solution here- able to compile/use the standard zfs-dkms packages with some modifications:
 
 

After fighting with this with a few distros..  I am close here:
 
1. First, go to your linux-headers directory (e.g. /usr/src/linux-headers-4.4.129-rk3328/) and:
 
make scripts
 
If that fails (classmap.h missing for example), there is a problem with the headers package.  You may need to manually edit scripts/Makefile and comment out the line with selinux -- there is a problem with the kernel config not matching the header deb in my case.
 
# subdir-$(CONFIGS_SECURITY_SELINUX) += selinux
 
2. From the same headers directory, verify that include/generated/utsrelease.h matches the full kernal name from: uname -a
 
- My headers (from beta repo) had 4.4.129 as utsrelease.h and 4.4.129-rk3328 as the kernel version/release.  This causes modules to be built incorrectly and their vermagic to not match--you can use modprobe --force to get around this, but ill-advised to use that for more than a quick test with something like zfs.  My utsrelease.h now reads: 4.4.129-rk3328
 
3. Edit /var/lib/dkms/spl/<yourversion>/source/configure and search for KUID, for lines that look like this:
 
kuid_t userid = KUIDGT_INIT(0);
kgid_t groupid = KGIDT_INIT(0);
 
Erase those two lines, the test itself is broken on our environments.  Leave the lines surrounding it.  These appear twice in the configure script--remove both sets.   
 
Now look for these lines:
 
kuid_t userid = 0;
kgid_t groupid = 0;
 
Change them to:
 
kuid_t userid;
kgid_t groupid;
 
(I filed a bug here https://github.com/zfsonlinux/spl/issues/653#issuecomment-333973785 )
 
Now you can run:
 
dkms build spl/<yourversion>
dkms install --force spl/<yourversion>
modprobe spl
# should be no errors here, check dmesg otherwise
 
dkms build zfs/<yourversion>
dkms install --force zfs/<yourversion>
 
When configure runs, you should now see:
checking whether kuid_t/kgid_t is available... yes; mandatory
 
Some notes:
 
- I ended up switching to beta (sources.d) and doing an update/upgrade/dist-upgrade first because there were no kernel headers for the WIP rock64 image I installed.
 
- If you use kernel 4.11.x you will need to use SPL/ZFS 0.7.x.  I am using the standard zfs-dkms/spl-dkms 0.6.5.9 packages for now..  install SPL and let it fail, then dkms install it after the steps above and then install the ZFS package.
 
Just started with Armbian today .. in retrospect it looks like it has drawn me in..