Tautulli (previously PlexPy) [HTPC-Tautulli]

Note

These directions are way out of date. Do not use these! I have since switched to a different process or tool since writing this particular article, but keeping it up for posterities sake, until I can properly replace it.

What have I changed to you ask? Anything building I’ve tried switching over to Ansible to handle in a much more programatic way. Others might be tools that I just don’t use at all anymore, due to changing DNS hosts.

Tautulli is specifically for monitoring Plex. Plus, you can setup notifications so you can see when Plex adds files, has updates, items are played and stopped and what not, as well as if you have any friends or family who have access.

It also gives you a breakdown of what is played the most, how many concurrent streams have played at the same time, and a bunch of other things as well.

Prerequisites

Python2.7 is the biggy here.

sudo apt-get install python2.7 python-pip python-dev git git-core

Clone the Repo

Note

I keep all of my cloned git repos inside of one, singular directory:

~/git

This way, I don’t have to hunt all over my system for where my repos are located and it makes it easier to keep them updated. Then, I symlink the library to wherever the developer wants or requires it or where its easiest to run.

The other way of handing this is to clone your PROGRAMS into the /opt directory - so /opt/couchpotato, /opt/NzbDrone, /opt/plexpy and so on. Then clone your working repos for projects seperately into ~/git/[repo]

So, of course, you can amend the ending to the below code to wherever you want the repo to sit inside your system.

git clone https://github.com/Tautulli/Tautulli ~/git/tautulli

Note

If you previously installed this git repo before, you’ll notice that the entire repo and app name has changed from PlexPy to Tautulli. Both python scripts exist in the beta line of the repo. (Plexpy.py and Tautulli.py) So its really up to you on which naming scheme you want to use, currently. This info - obviously - will change in a future (unknown) update.

Edit the Default File

Now, you want to:

sudo touch /etc/default/tautulli

The /etc/default directory is where a LOT of programs like to store files that make adjustments from the defaulted norm of their programs. Items like the User that the system will run the program under. Or where the program will store .pid files, log files, etc.

That will make sure to stop any possible errors or warnings. It also is where you need to make any changes, in case you don’t use the default settings that are in the various init scripts. You can see the options inside of ./tautulli/init-scripts/init.ubuntu if you’re using Ubuntu.

Create Tautulli User

Next, I do like to create and use a seperate, tautulli user for running Tautulli.

Note

See User Management for notes on adjusting user permissions with regards to programs and allowing the web access to your machines.

But, use the adduser line below instead of from the User Management doc

sudo adduser --system --group tautulli --no-create-home tautulli

Testing the Program First

First, we want to, basically, blindly run tautulli to see if any settings files need adjusting or anything in our systems.

So, we do:

sudo python /opt/tautulli/Tautulli.py

This will start Tautulli where it will output all of its startup functions, like when you turn on a linux machine, to the console so you can see any errors right there.

AutoStart System Files

Next, we will perform a few different commands to add Tautulli to Ubuntu’s autostart system - so that the program starts at boot correctly, and runs nicely in the system.

init.d

The /etc/init.d directory is where the autostart scripts are stored. Thus, why I call them the init.d files. There is also a /etc/init location for Upstart scripts, which… Ubuntu seems to like to change their autostart programs every so often. And to add ontop of that, the base Debian system has THEIR own means, that is even useable inside Ubuntu - systemctl.

But, in most programs that you use git to install on your system, AND they include autostart files for you, often times the init.d based scripts will be referenced as just init, making the whole thing slightly more complex. The best way to know for sure if its init.d or init based? Just edit the file and take a look!

If the file looks like this:

#! /bin/sh
### BEGIN INIT INFO
# Provides: NzbDrone
# Required-Start: $local_fs $network $remote_fs
# Required-Stop: $local_fs $network $remote_fs
# Should-Start: $NetworkManager
# Should-Stop: $NetworkManager
# Default-Start: 2 3 4 5
# Default-Stop: 0 1 6
# Short-Description: starts instance of NzbDrone
# Description: starts instance of NzbDrone using start-stop-daemon
### END INIT INFO

############### EDIT ME ##################
# path to app
APP_PATH=/opt/NzbDrone

# user
RUN_AS=<Your UserName>

# path to mono bin
DAEMON=$(which mono)

# Path to store PID file
PID_FILE=/var/run/nzbdrone/nzbdrone.pid
PID_PATH=$(dirname $PID_FILE)

# script name
NAME=nzbdrone

# app name
DESC=NzbDrone

# startup args
EXENAME="NzbDrone.exe"
DAEMON_OPTS=" "$EXENAME

############### END EDIT ME ##################

NZBDRONE_PID=`ps auxf | grep NzbDrone.exe | grep -v grep | awk '{print $2}'`

test -x $DAEMON || exit 0

set -e

#Look for PID and create if doesn't exist
if [ ! -d $PID_PATH ]; then
    mkdir -p $PID_PATH
    chown $RUN_AS $PID_PATH
fi

if [ ! -d $DATA_DIR ]; then
    mkdir -p $DATA_DIR
    chown $RUN_AS $DATA_DIR
fi

if [ -e $PID_FILE ]; then
    PID=`cat $PID_FILE`
    if ! kill -0 $PID > /dev/null 2>&1; then
        echo "Removing stale $PID_FILE"
        rm $PID_FILE
    fi
fi

echo $NZBDRONE_PID > $PID_FILE

case "$1" in
    start)
    if [ -z "${NZBDRONE_PID}" ]; then
        echo "Starting $DESC"
        rm -rf $PID_PATH || return 1
        install -d --mode=0755 -o $RUN_AS $PID_PATH || return 1
        start-stop-daemon -d $APP_PATH -c $RUN_AS --start --background --pidfile    $PID_FILE --exec $DAEMON -- $DAEMON_OPTS
    else
        echo "NzbDrone already running."
    fi
    ;;
    stop)
        echo "Stopping $DESC"
        echo $NZBDRONE_PID > $PID_FILE
        start-stop-daemon --stop --pidfile $PID_FILE --retry 15
    ;;
    restart|force-reload)
        echo "Restarting $DESC"
        start-stop-daemon --stop --pidfile $PID_FILE --retry 15
        start-stop-daemon -d $APP_PATH -c $RUN_AS --start --background --pidfile $PID_FILE --exec $DAEMON -- $DAEMON_OPTS
    ;;
    status)
        # Use LSB function library if it exists
        if [ -f /lib/lsb/init-functions ]; then
            . /lib/lsb/init-functions
            if [ -e $PID_FILE ]; then
                status_of_proc -p $PID_FILE "$DAEMON" "$NAME" && exit 0 || exit $?
            else
                log_daemon_msg "$NAME is not running"
                exit 3
            fi
        else
            # Use basic functions
            if [ -e $PID_FILE ]; then
                PID=`cat $PID_FILE`
                if kill -0 $PID > /dev/null 2>&1; then
                    echo " * $NAME is running"
                    exit 0
                fi
            else
                echo " * $NAME is not running"
                exit 3
            fi
        fi
    ;;
    *)
        N=/etc/init.d/$NAME
        echo "Usage: $N {start|stop|restart|force-reload|status}" >&2
        exit 1
        ;;
    esac

exit 0

then its an init.d file. Specifically with the ###### BEGIN INIT INFO block of text.

But, if it looks like this:

# tautulli
#
# This is a session/user job. Install this file into /usr/share/upstart/sessions
# if tautulli is installed system wide, and into $XDG_CONFIG_HOME/upstart if
# tautulli is installed per user. Change the executable path appropiately.

start on desktop-start
stop on desktop-end

env CONFIG=""$XDG_CONFIG_HOME"/tautulli"
env DATA=""$XDG_DATA_HOME"/tautulli"

pre-start script
    [ -d "$CONFIG" ] || mkdir -p "$CONFIG"
    [ -d "$DATA" ] || mkdir -p "$DATA"
end script

exec Tautulli.py --nolaunch --config "$CONFIG"/config.ini --datadir "$DATA"

Then thats an init upstart file. Much shorter, and without all that required text at the top.

But, for now, we use /etc/init.d and the commands sudo service since its what I know to how to use.

Make init.d file Executable

First, we need to make the init.d file executable by the system. This basically changes the way the script is called, while still being a bash shell script. Its how the system can use /etc/init.d files without having to use bash or sh in the terminal command - or even ANY file thats technically a script without first calling the scripts program/compiler in the command line.

sudo chmod +x ~/git/tautulli/init-scripts/init.ubuntu

The chmod is modifing the access flags for the file. The +x means ‘add the executable flag’. There is also +w and +r which is write and read, in that order. And, there is another way to change that information as well. But thats for another document.

Update Ubuntu’s Autostart Program

And now we add Tautulli to the autostart system that Ubuntu uses, update-rc.d being the command to add it. If you want to remove it, you run sudo update-rc.d tautulli remove AFTER deleting the tautulli file from /etc/init.d.

sudo update-rc.d tautulli defaults
sudo service tautulli start

SystemCTL

If you want to use Ubuntu/Debian’s newest startup system, SystemCTL (systemctl being the command), follow these instructions.

Note

I am in no way fully learned in how to utilize this newest startup system, nor do I know all of the proper places to store these startup files. But what follows is what has worked for me.

These files do not need to be flagged as executable, as the init.d scripts did from above. I believe, in fact, that it possibly will throw an error message if you do so.

If you want to look at some example files, the /lib/systemd/system directory is where the files are stored.

Link or Copy

Tautulli’s premade systemd script is located at ~/git/tautulli/init-scripts/init.systemd. Of which, there are some items you’ll probably want to change, depending on your setup.

With systemd, you are able to include using a defaults file, like the init.d files from above, but I was unable to get that to work properly here.

To link the existing file from Tautlli’s repo on your filesystem:

sudo ln -s ~/git/tautulli/init-scripts/init.systemd /lib/systemd/system/tautulli.service

making sure to add the .service to the end of the name.

Update SystemCTL’s Autostart Program

And now, adding the service file to systemctl system, you use:

sudo systemctl daemon-reload
sudo systemctl enable tautulli.service

The systemctl command has a bunch of command line options. If you want to dive into how to use it, you can man systemctl to start you down the rabit hole.

The above command will actually create another symlink from /lib/systemd/system to /etc/systemd/system, which enables the service script to run.

Accessing

Now, you can access the web interface at http://localhost:8181 with 8181 being the port it is running on.

[HTPC-Tautulli]

These instructions were copied, mostly, from the original DrZoidberg33’s GitHub Repo, but he no longer manages this, it seems. So, you can look at Tautulli’s Github