Sonarr, Lidarr, Radarr, Tautulli and Spotifyd packages for Fedora


Warning: Missing argument 2 for Jetpack_AMP_Support::render_sharing_html() in /home/content/15/11463415/html/site/wp-content/plugins/jetpack/3rd-party/class.jetpack-amp-support.php on line 309

I now have a new Plex server with lots of storage in a new small cube form factor, so it was now time to automate things a bit more and put the box to proper use.

Now in the multimedia repository you can now find Sonarr, Radarr, Lidarr and Tautulli. This allows you to populate and maintain automatically your TV Shows, Movies and Music libraries without effort. Tautulli is not particularly useful if you are not hosting Plex for third parties, but gives you anyway statistics and information in a nice GUI for consumption and also notifies you any time one of the other tools adds something to a library.

Now I can see how many times my kid has watched the Super Wings! TV show (a ridiculous amount of times, if you are interested):

The packages are built from the upstream releases. Being Sonarr, Radarr and Lidarr built on different Mono versions and requiring a different minimum version, I assembled the packages from their Mono binaries tarballs. The plan is to make all of these available also for CentOS, so packaging needs to be relaxed. Tautulli as well bundles a lot of specific Python dependencies.

All of them come with proper System units and Firewalld rule definitions. So should be a breeze to enable them on the system.

$ rpm -ql sonarr radarr lidarr tautulli | grep -E 'systemd|firewalld'
/usr/lib/firewalld/services/sonarr.xml
/usr/lib/systemd/system/sonarr.service
/usr/lib/firewalld/services/radarr.xml
/usr/lib/systemd/system/radarr.service
/usr/lib/firewalld/services/lidarr.xml
/usr/lib/systemd/system/lidarr.service
/usr/lib/firewalld/services/tautulli.xml
/usr/lib/systemd/system/tautulli.service

Along with those, there is also Spotifyd, which allows you to turn any system into a Spotify client and/or Spotify Connect speaker. Without any configuration file it just works like a WiFi speaker support Spotify Connect, with a configuration file that contains a Spotify Premium username and password you have a fully connected client that you can control with the Spotify phone app like any other client.

If the Plex server is always on and close to a set of speakers, why not use it also as a WiFi speaker? Would also be nice to have Google Cast support; so my family could also use it for listenting to Plex hosted music, but unfortunately Google locked out all APIs for casting and no open source implementation exists (as far as I know).

For example:

This list comes from my phone, and I’m in the same network of the laptop. Everything else is signed in with my account or has been playing something when I was close by, so it’s still logged in.

Also Spotifyd will eventually be available for CentOS/RHEL even if it does not have any Rust packages. The version currently in the repositories is built to also support PulseAudio as a backend, as the plan is to run this on a fully fledged Fedora/CentOS/RHEL system. The binary release offered on the Github project is built with only Alsa as a backend as it requires a considerable less amount of libraries as dependencies; making it suitable for running on a barebone Raspberry Pi.

HandBrake FFmpeg, no more Nvidia 32 bit drivers


Warning: Missing argument 2 for Jetpack_AMP_Support::render_sharing_html() in /home/content/15/11463415/html/site/wp-content/plugins/jetpack/3rd-party/class.jetpack-amp-support.php on line 309

HandBrake has been updated again to track the master branch, as it now uses FFMpeg 4 and no longer libAV 12. This could probably lead to other improvements, like NVENC/CUDA support, more formats, etc.

Starting with the Nvidia drivers version 396.24 there will be no more 32 bit support, the driver will be 64 bit only. The 32 bit libraries are still included, so Steam and other applications will keep on being supported.

In a few days, the updated drivers will be pushed in the Fedora repositories, and at the same time I will also remove the i386 folder from the repositories. Some i386 packages will still be provided in the x86_64 folder, as it is now for Fedora 28 and CentOS/RHEL 7. The packages that will be kept, are mostly multilib library packages.

The same will happen to CentOS/EPEL 6 at the moment a new 64 bit only driver series will be nominated as “Long Lived”.

Also the Spotify repository has already no more i386 support, upstream stopped providing updated clients. Judging from the web server logs, there seems to be almost no one using an i686 Fedora in conjunction with the repositories hosted here.

Fedora 24 and CentOS/RHEL 7 repositories


Warning: Missing argument 2 for Jetpack_AMP_Support::render_sharing_html() in /home/content/15/11463415/html/site/wp-content/plugins/jetpack/3rd-party/class.jetpack-amp-support.php on line 309

Fedora 24 repositories have been available for quite some time now, but here is the official statement that everything should be supported out of the box.

As part of the repository availability, I would like to say that starting from Fedora 24, the repositories are self-sustained and do not require RPMFusion to be enabled. I try to preserve compatibility between the two, so if you step into any problem just open an issue to the specific package on Github, send me an email or drop a message in the comment section of the various pages. Please note that “compatible” means that actually you shouldn’t get any conflict when installing packages, and not that I will not overwrite/obsolete the packages provided in the other repositories.

CentOS/RHEL 7 repositories have been available stand alone since the beginning and do not require external repositories to be enabled. Again, if an RPMFusion (or whatever will be mainstream at the moment) CentOS/RHEL 7 repository will appear, I will try to be compatible with it.

Scope of support

My basic idea is to have what I’m using normally everyday as a package in Fedora, enabling software combinations that would be otherwise impossible to distribute in official repositories due to license/patent issues. This for example includes NVENC (Nvidia Encoder) FFMPeg enabled builds that I use almost everyday.

Being a daily CentOS/RHEL 7 user I also want to support the latest and gretest of the same software on that platform, which also means rebuilding some official CentOS/RHEL 7 packages like VP8/9, VDPAU and VA-API libraries.

Due to the various package builds being different (or simply containing newer software releases) from what the other repositories offer, I also try to be completely independent, you can basically install the operating system and just use my repositories.

Build system changes

The (internal at the moment) build system uses Github as its primary system for storing the package information. There is a Negativo17.org public organization where all the work goes, so if you want to look at the development or the SPEC files, just browse to Github. If you have an issue or proposed change as well, you’re welcome to open an issue or create a merge request in the specific package Git page.

Skype Web Pidgin plugin

skype

The Skype repository used to contain purple-skype for Fedora and CentOS/RHEL distributions which at the time required an installed Skype to work. Now, I helped a new Fedora contributor into integrating the newly developed Skype web plugin, which is based on the Skype web client. The package in Fedora obsoletes and provides correctly the skype4pidgin plugin and as such I don’t need to provide anything else in the repository.

The installation instructions have been updated to reflect this.

Skype is available only in 32 bit format, so on a 64 bit a 32 bit client will always be installed. Since the merging with MSN, the HTML welcome screen requires a 32 bit WebKit GTK build to start. This is not included in the 64 bit only CentOS/RHEL 7 repositories; so for this reason, if you are running CentOS/RHEL 7, it requires the multimedia repository to be enabled and have the dependency solved. This used to be self-contained in the Skype repository, but this is no longer feasible for me to mantain considering there is a different rebuild of WebKit GTK in the Multimedia repository.

Spotify Client

spotify-client

The Spotify repository used to contain FFMpeg for CentOS/RHEL distributions and a requirement on FFMpeg’s RPMFusion as a Fedora dependency. FFMpeg is no longer included in the CentOS/RHEL 7 repositories so the multimedia repository has to be enabled to have the dependency solved. As for Skype, this no longer feasible for me to mantain considering there is a different rebuild of WebKit GTK in the Multimedia repository.

Here as well the installation instructions have been updated to reflect the change.

aKMOD kernel module packages

The kernel binary module packages generated by aKMOD are now compressed with XZ, like in the original Fedora kernel packages that contain kernel modules. I’ve become a DKMS contributor, so, as time permits, I will add the same functionality to DKMS for Fedora distributions.

At the moment, this applies to Nvidia and X-Pad kernel modules.

Gstreamer plugins and multimedia libraries

The Multimedia repository now provides GStreamer (1.0) plugins for Bad, Ugly, libAV and VA-API plugin bundles with all options enabled. This is split into the following GStreamer runtime packages:

  • gstreamer1-plugins-bad
  • gstreamer1-plugins-ugly
  • gstreamer1-vaapi
  • gstreamer1-libav
  • gstreamer1-plugins-bad-fluidsynth (pulls in the whole FluidSynth distribution)
  • gstreamer1-plugins-bad-nvenc (x86_64 only, pulls in the Nvidia binary driver; and at the moment it does not work properly)

They all have an Epoch of “1”, due to the various reasons explained at the top. They are not yet available for CentOS/RHEL 7 due to time constraints; I will try to prepare them in the next weeks.

Fedora 24 OpenH264 repository

A note on the Fedora 24 OpenH264 repository. As described in its wiki page, there is an extra repository that can be enabled directly in Fedora 24 that allows you to install OpenH264, its relevant Gstreamer 1.0 plugin and a Mozilla plugin for Firefox. Following the same logic, at the moment the same Gstreamer 1.0 plugin is provided/obsoleted (in newer form) by the gstreamer1-pluings-bad package. There is a conflict for the OpenH264 binaries which I will address soon.