1
0
mirror of https://github.com/spl0k/supysonic.git synced 2024-09-19 19:01:03 +00:00
Go to file
Carey Metcalfe 65d49a04c9 Implement a cache manager for album art and transcodes
Quick summary
-------------
- Adds a Cache class (plus tests for it) that provides an API for
  managing a cache of files on disk
- Adds two new settings to the configuration file: `cache_size` (default
  512MB) and `transcode_cache_size` (default 1GB).
- Creates two cache managers using the settings above: one for general
  stuff (currently album art) and one for transcodes
- Adds the caching of transcoded files to disk for future use
- Modifies the existing image caching to use the cache manager

Longer explanations and justifications
--------------------------------------
The reason I separated out transcodes into an entirely separate cache is
that I could imagine a single transcode pushing out a ton of smaller
images or other cached content. By separating them it should reduce the
number of deletes caused by adding something to the cache.

The cache manager allows for caching a value from a generator via
passthrough. This means that a generator can be transparently wrapped to
save its output in the cache. The bytes from the generator will be
written to a temp file in the cache and yielded back. When it completes,
the temp file will be renamed according to the provided cache key. This
is how caching transcoded music is implemented.

If multiple generators for the same key are started, they will all write
to individual temp files until they complete and race to overwrite each
other. Since the key should uniquely represent the content it indexes
the files will be identical so overwriting them is harmless.

The cache will store everything for a minimum amount of time
(configurable, default is set at 5 minutes). After this time has
elapsed, the data can be deleted to free up space. This minimum is so
that when you cache a file to the disk you can expect it to be there
after, even if another large file is added to the cache and requests
that some files are deleted to make space.

To ensure that a file will not be paged out of the cache regardless of
the minimum time, there is a `protect` context manager that will refuse
the delete the key from the cache as long as it's active.

The cache has a maximum size, however this is more of a recommendation
as opposed to a hard limit. The actual size will frequently exceed the
limit temporarily until something can be paged out.
2019-01-19 15:37:08 -05:00
bin I'm on a pony 2017-12-19 23:16:55 +01:00
cgi-bin Unified file headers 2018-03-04 21:49:56 +01:00
docs Added getSongsByGenre 2018-12-08 17:42:20 +01:00
supysonic Implement a cache manager for album art and transcodes 2019-01-19 15:37:08 -05:00
tests Implement a cache manager for album art and transcodes 2019-01-19 15:37:08 -05:00
.coveragerc Updates for Travis and codecov 2017-12-10 22:31:12 +01:00
.gitignore Merge branch 'pony' 2018-01-04 21:36:56 +01:00
.travis.yml Rewritten dependencies and don't use pip as a library 2018-04-29 14:51:30 +02:00
config.sample Implement a cache manager for album art and transcodes 2019-01-19 15:37:08 -05:00
LICENSE Setting a license 2014-03-02 18:31:32 +01:00
MANIFEST.in First throw at automatic database migrations 2018-08-29 17:46:59 +02:00
README.md Added method to list genres 2018-12-08 17:18:58 +01:00
setup.py Add support for downloadong folders and albums 2019-01-13 17:18:27 +01:00
travis-requirements.txt Rewritten dependencies and don't use pip as a library 2018-04-29 14:51:30 +02:00

Supysonic

Supysonic is a Python implementation of the Subsonic server API.

Build Status codecov Python

Current supported features are:

  • browsing (by folders or tags)
  • streaming of various audio file formats
  • transcoding
  • user or random playlists
  • cover arts (as image files in the same folder as music files)
  • starred tracks/albums and ratings
  • Last.FM scrobbling

Supysonic currently targets the version 1.9.0 of the Subsonic API. For more details, go check the API implementation status.

Table of contents

Installation

Supysonic can run as a standalone application (not recommended for a "production" server) or as a WSGI application (on Apache for instance).

To install it, either run:

$ python setup.py install

or

$ pip install .

but not both. Please note that the pip method doesn't seem to work with Python 2.7.

Prerequisites

You'll need these to run Supysonic:

All the dependencies (except watchdog) will automatically be installed by the installation command above.

You may also need a database specific package if you don't want to use SQLite (the default):

  • MySQL: pip install pymysql or pip install mysqlclient
  • PostgreSQL: pip install psycopg2-binary

Database initialization

Supysonic needs a database to run. It can either be a SQLite, MySQL-compatible or PostgreSQL database.

Please refer to the documentation of the DBMS you've chosen on how to create a database. Once it has a database, Supysonic will automatically create the tables it needs.

If you want to use PostgreSQL you'll have to add the citext extension to the database once created. This can be done when connected to the database as the superuser with the folowing SQL command:

supysonic=# CREATE EXTENSION citext;

If you absolutely have no clue about databases, you can go with SQLite as it doesn't need any setup other than specifying a path for the database. Note that using SQLite for large libraries might not be the brightest idea as it tends to struggle with larger datasets.

Configuration

Once you have a database, you'll need to create a configuration file. It must be saved under one of the following paths:

  • /etc/supysonic
  • ~/.supysonic
  • ~/.config/supysonic/supysonic.conf

A roughly documented sample configuration file is provided as config.sample.

The minimal configuration using a SQLite database would be:

[base]
database_uri = sqlite:////some/path/to/a/supysonic.db

For a more details on the configuration, please refer to documentation.

Running the application

As a standalone debug server

It is possible to run Supysonic as a standalone server, but it is only recommended to do so if you are hacking on the source. A standalone won't be able to serve more than one request at a time.

To start the server, just run the cgi-bin/server.py script.

$ python cgi-bin/server.py

By default, it will listen on the loopback interface (127.0.0.1) on port 5000, but you can specify another address on the command line, for instance on all the IPv6 interfaces:

$ python cgi-bin/server.py ::

As an Apache WSGI application

Supysonic can run as a WSGI application with the cgi-bin/supysonic.wsgi file. To run it within an Apache2 server, first you need to install the WSGI module and enable it.

$ apt install libapache2-mod-wsgi
$ a2enmod wsgi

Next, edit the Apache configuration to load the application. Here's a basic example of what it looks like:

WSGIScriptAlias /supysonic /path/to/supysonic/cgi-bin/supysonic.wsgi
<Directory /path/to/supysonic/cgi-bin>
    WSGIApplicationGroup %{GLOBAL}
    WSGIPassAuthorization On
    Require all granted
</Directory>

You might also need to run Apache using the system default locale, as the one it uses might cause problems while scanning the library from the web UI. To do so, edit the /etc/apache2/envvars file, comment the line export LANG=C and uncomment the . /etc/default/locale line. Then you can restart Apache:

$ systemctl restart apache2

With that kind of configuration, the server address will look like http://server/supysonic/

Other options

If you use another HTTP server, such as nginx or lighttpd, or prefer to use FastCGI or CGI over WSGI, FastCGI and CGI scripts are also provided in the cgi-bin folder, respectively as supysonic.fcgi and supysonic.cgi. You might need to edit those file to suit your system configuration.

Here are some quick docs on how to configure your server for FastCGI or CGI.

Docker

If you want to run Supysonic in a Docker container, here are some images provided by the community.

Quickstart

To start using Supysonic, you'll first have to specify where your music library is located and create a user to allow calls to the API.

Let's start by creating a new admin user this way:

$ supysonic-cli user add MyUserName -a -p MyAwesomePassword

To add a new folder to your music library, you can do something like this:

$ supysonic-cli folder add MyLibrary /home/username/Music

Once you've added a folder, you will need to scan it:

$ supysonic-cli folder scan MyLibrary

You should now be able to enjoy your music with the client of your choice!

For more details on the command-line usage, take a look at the documentation.

Client authentication

The Subsonic API provides several authentication methods. One of them, known as token authentication was added with API version 1.13.0. As Supysonic currently targets API version 1.9.0, the token based method isn't supported. So if your client offers you the option, you'll have to disable the token based authentication for it to work.

Watching library changes

Instead of manually running a scan every time your library changes, you can run a watcher that will listen to any library change and update the database accordingly.

The watcher is supysonic-watcher, it is a non-exiting process. If you want to keep it running in background, either use the old nohup or screen methods, or start it as a simple systemd unit (unit file not included).

It needs some additional dependencies which can be installed with the following command:

$ pip install -e .[watcher]

Upgrading

To upgrade your Supysonic installation, simply re-run the command you used to install it (either python setup.py install or pip install .).

Some commits might introduce changes in the database schema. Starting with commit e84459d627 (August 29th, 2018) migrations will be automatically applied.

If your database was created prior to this date, you'll have to manually apply unapplied migrations up to the latest. Once done you won't have to worry about future migrations as they'll be automatically applied. Migration scripts are provided in the supysonic/schema/migration folder, named by the date of commit that introduced the schema changes. There could be both SQL scripts or Python scripts. The Python scripts require arguments that are explained when the script is invoked with the -h flag.