1
0
mirror of https://github.com/spl0k/supysonic.git synced 2024-09-19 10:51:04 +00:00
supysonic/README.md

234 lines
8.0 KiB
Markdown
Raw Normal View History

# Supysonic
2013-05-15 16:07:47 +00:00
2018-02-14 18:45:39 +00:00
_Supysonic_ is a Python implementation of the [Subsonic][] server API.
2013-05-15 16:07:47 +00:00
2017-12-10 21:31:12 +00:00
[![Build Status](https://travis-ci.org/spl0k/supysonic.svg?branch=master)](https://travis-ci.org/spl0k/supysonic)
[![codecov](https://codecov.io/gh/spl0k/supysonic/branch/master/graph/badge.svg)](https://codecov.io/gh/spl0k/supysonic)
2018-01-18 20:13:19 +00:00
![Python](https://img.shields.io/badge/python-2.7%2C%203.5%2C%203.6-blue.svg)
2017-12-10 21:31:12 +00:00
2013-06-14 17:36:14 +00:00
Current supported features are:
* browsing (by folders or tags)
* streaming of various audio file formats
2018-02-14 18:45:39 +00:00
* [transcoding]
* user or random playlists
2013-05-15 16:07:47 +00:00
* cover arts (`cover.jpg` files in the same folder as music files)
2013-06-14 17:36:14 +00:00
* starred tracks/albums and ratings
* [Last.FM][lastfm] scrobbling
2013-05-15 16:07:47 +00:00
2018-02-14 18:45:39 +00:00
_Supysonic_ currently targets the version 1.8.0 of the _Subsonic_ API. For more
details, go check the [API implementation status][docs-api].
[subsonic]: http://www.subsonic.org/
2018-02-14 18:45:39 +00:00
[transcoding]: docs/trancoding.md
[lastfm]: https://last.fm/
[docs-api]: docs/api.md
2013-06-12 21:14:27 +00:00
2017-06-24 18:24:10 +00:00
## Table of contents
* [Installation](#installation)
+ [Prerequisites](#prerequisites)
+ [Database initialization](#database-initialization)
2018-02-14 18:45:39 +00:00
+ [Configuration](#configuration)
2017-06-24 18:24:10 +00:00
* [Running the application](#running-the-application)
+ [As a standalone debug server](#as-a-standalone-debug-server)
+ [As an Apache WSGI application](#as-an-apache-wsgi-application)
+ [Other options](#other-options)
* [Quickstart](#quickstart)
* [Watching library changes](#watching-library-changes)
2017-06-24 18:24:10 +00:00
* [Upgrading](#upgrading)
## Installation
2013-05-15 16:07:47 +00:00
2018-02-14 18:45:39 +00:00
_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, run:
2017-06-24 18:06:34 +00:00
2017-06-24 19:23:50 +00:00
$ python setup.py install
2013-05-15 16:07:47 +00:00
### Prerequisites
2018-02-14 18:45:39 +00:00
You'll need these to run _Supysonic_:
2017-06-04 18:00:24 +00:00
2018-01-18 20:13:19 +00:00
* Python 2.7 or >= 3.5
* [Flask](http://flask.pocoo.org/)
2017-12-14 21:28:49 +00:00
* [PonyORM](https://ponyorm.com/)
2017-06-04 18:00:24 +00:00
* [Python Imaging Library](https://github.com/python-pillow/Pillow)
* [requests](http://docs.python-requests.org/)
* [mutagen](https://mutagen.readthedocs.io/en/latest/)
* [watchdog](https://github.com/gorakhargosh/watchdog)
2017-12-14 21:28:49 +00:00
You can install all of them using `pip`:
2017-06-04 18:00:24 +00:00
2017-12-14 21:28:49 +00:00
$ pip install -r requirements.txt
2017-06-04 18:00:24 +00:00
You may also need a database specific package:
2018-02-14 18:45:39 +00:00
* _MySQL_: `pip install pymysql` or `pip install mysqlclient`
* _PostgreSQL_: `pip install psycopg2`
2017-06-25 18:47:10 +00:00
2018-02-14 18:45:39 +00:00
### Database initialization
2013-05-15 16:07:47 +00:00
2018-02-14 18:45:39 +00:00
_Supysonic_ needs a database to run. It can either be a _SQLite_,
_MySQL_-compatible or _PostgreSQL_ database.
2018-02-14 18:45:39 +00:00
_Supysonic_ does not automatically create the database and tables it needs to
work. Thus the database and tables must be created prior to running the
application. Please refer to the documentation of the DBMS you've chosen on how
to create a database and how to use a command-line client. 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;
2013-05-15 16:07:47 +00:00
2018-02-14 18:45:39 +00:00
Table creation scripts are provided in the `schema` folder for _SQLite_,
_MySQL_ and _PostgreSQL_. Just feed them to any client you're able to use.
2018-02-14 18:45:39 +00:00
If you absolutely have no clue about databases, you can go with _SQLite_.
You'll just need the `sqlite3` command-line tool. Install it and create the
database and tables with the following commands:
2017-11-29 19:09:48 +00:00
2018-02-14 18:45:39 +00:00
$ apt install sqlite3
$ sqlite3 /some/path/to/a/supysonic.db < schema/sqlite.sql
2018-02-14 18:45:39 +00:00
Remember the path you've used for the database file
(`/some/path/to/a/supysonic.db` in the example above), you'll need it in the
configuration file.
Note that using _SQLite_ for large libraries might not be the brightest idea as
it tends to struggle with larger datasets.
2018-02-14 18:45:39 +00:00
### Configuration
2018-02-14 18:45:39 +00:00
Once you have a database, you'll need to create a configuration file. It must
be saved under one of the following paths:
2018-02-14 18:45:39 +00:00
* `/etc/supysonic`
* `~/.supysonic`
* `~/.config/supysonic/supysonic.conf`
A roughly documented sample configuration file is provided as `config.sample`.
The minimal configuration using the _SQLite_ database created on the example
above whould be:
```ini
[base]
database_uri = sqlite:////some/path/to/a/supysonic.db
```
For a more details on the configuration, please refer to
[documentation][docs-config].
2014-06-12 14:06:46 +00:00
2018-02-14 18:45:39 +00:00
[docs-config]: docs/configuration.md
2014-06-12 14:06:46 +00:00
## Running the application
2014-03-04 20:42:47 +00:00
### As a standalone debug server
2013-05-15 16:07:47 +00:00
2018-02-14 18:45:39 +00:00
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.
2013-05-15 16:07:47 +00:00
2015-04-05 14:20:12 +00:00
To start the server, just run the `cgi-bin/server.py` script.
2014-03-04 20:42:47 +00:00
2017-06-24 19:23:50 +00:00
$ python cgi-bin/server.py
2013-05-15 16:07:47 +00:00
By default, it will listen on the loopback interface (`127.0.0.1`) on port
2018-02-14 18:45:39 +00:00
5000, but you can specify another address on the command line, for instance on
all the IPv6 interfaces:
2013-05-15 16:07:47 +00:00
2017-06-24 19:23:50 +00:00
$ python cgi-bin/server.py ::
2013-05-15 16:07:47 +00:00
2018-02-14 18:45:39 +00:00
### As an _Apache_ WSGI application
2013-05-15 16:07:47 +00:00
2018-02-14 18:45:39 +00:00
_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.
2013-05-15 16:07:47 +00:00
2018-02-14 18:45:39 +00:00
$ apt install libapache2-mod-wsgi
2017-06-24 19:23:50 +00:00
$ a2enmod wsgi
2013-05-15 16:07:47 +00:00
2018-02-14 18:45:39 +00:00
Next, edit the _Apache_ configuration to load the application. Here's a basic
example of what it looks like:
2013-05-15 16:07:47 +00:00
2017-06-24 18:15:03 +00:00
WSGIScriptAlias /supysonic /path/to/supysonic/cgi-bin/supysonic.wsgi
<Directory /path/to/supysonic/cgi-bin>
WSGIApplicationGroup %{GLOBAL}
WSGIPassAuthorization On
Order deny,allow
Allow from all
</Directory>
2013-05-15 16:07:47 +00:00
2018-02-14 18:45:39 +00:00
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_:
2018-02-14 18:45:39 +00:00
$ systemctl restart apache2
2018-02-14 18:45:39 +00:00
With that kind of configuration, the server address will look like
*http://server/supysonic/*
2013-05-15 16:07:47 +00:00
2014-03-04 20:42:47 +00:00
### Other options
2018-02-14 18:45:39 +00:00
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.
2014-03-04 20:42:47 +00:00
2018-02-14 18:45:39 +00:00
Here are some quick docs on how to configure your server for [FastCGI][] or
[CGI][].
[fastcgi]: http://flask.pocoo.org/docs/deploying/fastcgi/
[cgi]: http://flask.pocoo.org/docs/deploying/cgi/
2014-03-04 20:42:47 +00:00
2017-06-24 20:23:28 +00:00
## Quickstart
2017-06-24 19:23:50 +00:00
2018-02-14 18:45:39 +00:00
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.
2017-06-24 20:23:28 +00:00
Let's start by creating a new admin user this way:
2017-06-24 19:23:50 +00:00
2018-02-14 18:45:39 +00:00
$ supysonic-cli user add MyUserName -a -p MyAwesomePassword
2017-06-24 19:23:50 +00:00
2017-06-24 20:23:28 +00:00
To add a new folder to your music library, you can do something like this:
2017-06-24 19:23:50 +00:00
2018-02-14 18:45:39 +00:00
$ supysonic-cli folder add MyLibrary /home/username/Music
2017-06-24 19:23:50 +00:00
2017-06-24 20:23:28 +00:00
Once you've added a folder, you will need to scan it:
2017-06-24 19:23:50 +00:00
$ supysonic-cli folder scan MyLibrary
2013-05-15 16:07:47 +00:00
2017-06-24 20:23:28 +00:00
You should now be able to enjoy your music with the client of your choice!
2018-02-14 18:45:39 +00:00
For more details on the command-line usage, take a look at the
[documentation][docs-cli].
[docs-cli]: docs/cli.md
## Watching library changes
2015-04-05 14:28:04 +00:00
2018-02-14 18:45:39 +00:00
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.
2018-02-14 18:45:39 +00:00
The watcher is `bin/supysonic-watcher`, it is a non-exiting process and doesn't
2018-02-14 18:45:39 +00:00
print anything to the console. 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).
2015-04-05 14:28:04 +00:00
## Upgrading
2018-02-14 18:45:39 +00:00
Some commits might introduce changes in the database schema. When that's the
case migration scripts will be provided in the `schema/migration` folder,
prefixed by the date of commit that introduced the changes. Those scripts
shouldn't be used when initializing a new database, only when upgrading from a
previous schema.
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.
If a migration script isn't provided for a specific database engine, it simply
means that no migration is needed for this engine.
2018-01-18 20:13:19 +00:00