michaelmob / docker-funkwhale

All-in-one funkwhale docker image.
92 stars 18 forks source link

Import Music -- Align with Funkwhale Recommendations #33

Open tnyeanderson opened 4 years ago

tnyeanderson commented 4 years ago

From the funkwhale docs:

While in-place import is faster and less disk-space-hungry, it’s also more fragile: if, for some reason, you move or rename the source files, Funkwhale will not be able to serve those files anymore.

Then:

We recommend you symlink all your music directories into /srv/funkwhale/data/music and run the import_files command from that directory. This will make it possible to use multiple music directories, without any additional configuration on the webserver side.

Finally:

On docker setups, it will require a bit more work, because while the /srv/funkwhale/data/music is mounted in containers, symlinked directories are not. ... To fix that, you can use bind mounts instead of symbolic links, as it replicates the source directory tree.

Unfortunately, I look and see that /srv/funkwhale/data/music is not available on this container. Is the root folder for funkwhale media manually set to /music for this container, so that none of this is a problem?

If not, we should find a way to better align with this process. Just tell me where to look.

Thanks for all the hard work! :)

geoff-maddock commented 3 years ago

Came to this issue after setting up this container on my synology, and not being clear on how to import my music

I have my collection on a volume on my synology: /volume1/homes/audio/music

What steps would I need to take to set up the docker instance to use that and/or import it?

tnyeanderson commented 3 years ago

Going from memory (and my internal documentation), you just have to mount the volume to the /music directory in the container.

For instance, with docker-compose:

version: "3"

services:
  funkwhale:
    container_name: funkwhale
    restart: unless-stopped
    # add the version number in your .env file, or hardcode it
    image: funkwhale/all-in-one:0.19.1
    env_file: .env
    environment:
      # adapt to the pid/gid that own /srv/funkwhale/data
      - PUID=1000
      - PGID=1000
    volumes:
      - ./data:/data
      -  /volume1/homes/audio/music:/music:ro
    ports:
      - "5000:80"

I use caddy to reverse proxy, so if you serve directly you will have to make a couple changes, but this is my .env file:

FUNKWHALE_HOSTNAME=funkwhale.mydomain.com
FUNKWHALE_PROTOCOL=https # or http
NGINX_MAX_BODY_SIZE=100M
FUNKWHALE_API_IP=127.0.0.1
FUNKWHALE_API_PORT=5000 # or the container port you want to expose on the host
DJANGO_SECRET_KEY=MYKEY # generate and store a secure secret key for your instance using $(openssl rand -hex 45)
# Remove this if you expose the container directly on ports 80/443
NESTED_PROXY=1

Then create a super user:

docker exec -it funkwhale manage createsuperuser

Then, I remember having to add the library (via the /music directory) through the web interface of Funkwhale once it was set up. I forget exactly how this was done, but it was easy. It was somehwhere in the settings after logging in as my newly created super user. Once the library is created, get the library ID from the URL of your newly created library (its like a UUID).

Then import your music using the UUID, for instance:

docker exec -it funkwhale manage import_files $LIBRARY_ID "/music/**/**/*.mp3" --in-place --async

Disclaimer: I don't use funkwhale anymore (though I wish the project the best and hope I can come back to using it later, it just wasn't ready when I tried it). This info could be outdated. I committed the most recent version of my internal documentation for this 1 year ago.

I hope this helps, I'm sure someone will eventually update the docs to reflect the most correct/up-to-date process.

tnyeanderson commented 3 years ago

Also just realized that the info I provided is for the all-in-one container, but either way it should get you going, and I think the process would be the same for thetarkus version..... Honestly this information has been off my mind for quite some time, so I don't remember a lot of the nuance. Hopefully this helps and I didn't say anything horribly incorrect....

Sieboldianus commented 3 years ago

I found the docs of funkwhale overall excellent. Knowing a little bit about Docker, SSL etc. it made things really fun because they left open where user input was required, but provided guidance where it was necessary.

However, I finally stumbled into this issue: The importing command did not work with my Docker-Mono-Install.

i.e.:

docker-compose run --rm api python manage.py import_files $LIBRARY_ID "/data/music/" --recursive --noinput

Would output: no api service

docker-compose run --rm funkwhale python manage.py import_files $LIBRARY_ID "/data/music/" --recursive --noinput

Would error out with "managy.py" not found.

I then exec' into the funkwhale docker and searched for manage.py:

/app/api/manage.py

I run the command directly in the docker:

python /app/api/manage.py import_files $LIBRARY_ID "/data/music/" --recursive --noinput

But I guess one can also do:

docker-compose run --rm funkwhale python /app/api/manage.py import_files $LIBRARY_ID "/data/music/" --recursive --noinput

Perhaps the last command can be added to the docs, as a "Note for Mono-Docker Installs"?

[Edit] I changed my setup to the multi-container setup, primarily because I found it easier to debug. All commends in the doc work as expected for multi-docker. So perhaps, a hint should be added to the mono-container install that some commands may not work exactly as written in the docs.

Also, this:

On docker setups, it will require a bit more work, because while the /srv/funkwhale/data/music is mounted in containers, symlinked directories are not. ... To fix that, you can use bind mounts instead of symbolic links, as it replicates the source directory tree.

should be changed to:

On docker setups, it will require a bit more work, because while the /srv/funkwhale/data/music is mounted to /music in containers, symlinked directories are not available in the container. ... To fix that, you can use bind mounts instead of symbolic links, as it replicates the source directory tree.