[DOCKER CONTAINER] Headphones


Recommended Posts

Docker for Headphones -> https://github.com/rembo10/headphones/wiki

 

Currently maintained by Rembo10

 

Completely based on needo's couchpotato docker so all credit goes to him...

 

This will install by default the last stable release

 

https://registry.hub.docker.com/u/sacretagent/needo-headphones/

 

This is a Dockerfile setup for headphones -

 

By default this Docker installs the latest stable version of headphones:

 

docker run -d --net="host" --name="headphones" -v /path/to/headphones/data:/config -v /path/to/downloads:/downloads -v /path/to/music:/music -v /etc/localtime:/etc/localtime:ro -p 8181:8181 sacretagent/needo-headphones

 

Edge

----

If you would like to run the latest updates from the master branch as well as enable in-app updates run:

 

docker run -d --net="host" --name="headphones" -v /path/to/headphones/data:/config -v /path/to/downloads:/downloads -v /path/to/music:/music -v /etc/localtime:/etc/localtime:ro -e EDGE=1 -p 8181:8181 sacretagent/needo-headphones

Link to comment

I have been playing with this headphones container.  The EDGE option does not seem to work for me, I am getting the following errors in the log:

 

root@Iron:/mnt/cache/vm/apps/appdata/headphones# docker logs headphones

*** Running /etc/my_init.d/00_regen_ssh_host_keys.sh...

No SSH host key available. Generating one...

Creating SSH2 RSA key; this may take some time ...

Creating SSH2 DSA key; this may take some time ...

Creating SSH2 ECDSA key; this may take some time ...

Creating SSH2 ED25519 key; this may take some time ...

invoke-rc.d: policy-rc.d denied execution of restart.

*** Running /etc/my_init.d/edge.sh...

Reading package lists...

Building dependency tree...

Reading state information...

The following extra packages will be installed:

  git-man liberror-perl patch rsync

Suggested packages:

  gettext-base git-daemon-run git-daemon-sysvinit git-doc git-el git-email

  git-gui gitk gitweb git-arch git-bzr git-cvs git-mediawiki git-svn ed

  diffutils-doc

The following NEW packages will be installed:

  git git-man liberror-perl patch rsync

0 upgraded, 5 newly installed, 0 to remove and 6 not upgraded.

Need to get 3642 kB of archives.

After this operation, 22.5 MB of additional disk space will be used.

Get:1 http://archive.ubuntu.com/ubuntu/ trusty-updates/main rsync amd64 3.1.0-2ubuntu0.1 [283 kB]

Get:2 http://archive.ubuntu.com/ubuntu/ trusty/main liberror-perl all 0.17-1.1 [21.1 kB]

Get:3 http://archive.ubuntu.com/ubuntu/ trusty/main git-man all 1:1.9.1-1 [698 kB]

Get:4 http://archive.ubuntu.com/ubuntu/ trusty/main git amd64 1:1.9.1-1 [2555 kB]

Get:5 http://archive.ubuntu.com/ubuntu/ trusty-updates/main patch amd64 2.7.1-4ubuntu1 [84.4 kB]

Fetched 3642 kB in 3s (1151 kB/s)

Selecting previously unselected package rsync.

(Reading database ... 16116 files and directories currently installed.)

Preparing to unpack .../rsync_3.1.0-2ubuntu0.1_amd64.deb ...

Unpacking rsync (3.1.0-2ubuntu0.1) ...

Selecting previously unselected package liberror-perl.

Preparing to unpack .../liberror-perl_0.17-1.1_all.deb ...

Unpacking liberror-perl (0.17-1.1) ...

Selecting previously unselected package git-man.

Preparing to unpack .../git-man_1%3a1.9.1-1_all.deb ...

Unpacking git-man (1:1.9.1-1) ...

Selecting previously unselected package git.

Preparing to unpack .../git_1%3a1.9.1-1_amd64.deb ...

Unpacking git (1:1.9.1-1) ...

Selecting previously unselected package patch.

Preparing to unpack .../patch_2.7.1-4ubuntu1_amd64.deb ...

Unpacking patch (2.7.1-4ubuntu1) ...

Processing triggers for ureadahead (0.100.0-16) ...

Setting up rsync (3.1.0-2ubuntu0.1) ...

Removing any system startup links for /etc/init.d/rsync ...

update-rc.d: warning: default stop runlevel arguments (0 1 6) do not match rsync Default-Stop values (none)

Adding system startup for /etc/init.d/rsync ...

  /etc/rc0.d/K20rsync -> ../init.d/rsync

  /etc/rc1.d/K20rsync -> ../init.d/rsync

  /etc/rc6.d/K20rsync -> ../init.d/rsync

  /etc/rc2.d/S20rsync -> ../init.d/rsync

  /etc/rc3.d/S20rsync -> ../init.d/rsync

  /etc/rc4.d/S20rsync -> ../init.d/rsync

  /etc/rc5.d/S20rsync -> ../init.d/rsync

invoke-rc.d: policy-rc.d denied execution of restart.

Setting up liberror-perl (0.17-1.1) ...

Setting up git-man (1:1.9.1-1) ...

Setting up git (1:1.9.1-1) ...

Setting up patch (2.7.1-4ubuntu1) ...

Processing triggers for ureadahead (0.100.0-16) ...

fatal: Not a git repository (or any of the parent directories): .git

chown: cannot access '/opt/headphones': No such file or directory

*** /etc/my_init.d/edge.sh failed with status 1

 

*** Killing all processes...

root@Iron:/mnt/cache/vm/apps/appdata/headphones#

 

Link to comment

I installed the 2nd version that enables in-app updates.  Everything appears to be working, but the headphones.log file is filling with the following error:

 

 08-Jul-2014 06:48:32 - INFO    :: MainThread : Checking to see if the database has all tables....
08-Jul-2014 06:48:32 - INFO    :: MainThread : Retrieving latest version information from GitHub
08-Jul-2014 06:48:32 - ERROR   :: MainThread : Request raise HTTP error with status code 403 (local request error).
08-Jul-2014 06:48:32 - WARNING :: MainThread : Could not get the latest version from GitHub. Are you running a local development version?
08-Jul-2014 06:48:32 - INFO    :: MainThread : Using forced port: 8181
08-Jul-2014 06:48:32 - INFO    :: MainThread : Starting Headphones on http://0.0.0.0:8181/

 

Link to comment
  • 4 weeks later...

Please fix the major bug within headphones docker, if I stop the docker or try and remove it it completely destroys the access to the GUI and the only fix is a complete reinstall of unRAID.

 

This is a major bug that needs fixing.

 

Please, no scare mongering. I and I am sure many others use this with no issues.

 

Wild claims like this is just going to convince the volunteers who do this work for free to just mot bothering publishing their work.

Link to comment

Not a wild claim.  I've installed heaphones three times and every time I stop it, it completely locks me out of unraids webgui.  Even after multiple reboots I still have no access so have to reinstall.

 

I would post logs if I knew where they where :)

 

Edit: Found them

 

http://pastebin.com/2pckzugD

 

It's a wild claim. No one else has reported an issue like this.  I've been running fine for a while now.

 

There has never been a report of a buggy container forcing people to reinstall unRAID.

 

Quite simply, shooting off with wild accusations is going to have developers not bother sharing their work which would be a real shame for people who rely on others to make unRAID compatible dockers to get the most out of their unRAID servers.  Like me.

 

Your log shows nothing out of the ordinary.

Link to comment

Stop it and try and reload it, that is where the problem arises on my system. 

 

Update: I don't think it is stopping correctly through the container.  When I stopped it through Putty the WebGUI loads properly.

 

When I tried to update to the latest version of Headphones it happened again.

 

Last update before I go bed [02:40]

 

It appears to stop the browser loading from viewing the page, the GUI loads in another browser after force closure through Putty once a couple of minutes have passed and browser history/cache etc have been cleared WebGUI reloads. 

 

This only happens with Headphones..

 

Last night this didn't work and I was forced to reinstall unRAID.

headphones_crashing_unraid_gui.png.5744f6a3e4a688fccc2414d0cf06e4d7.png

Link to comment

all i can say it is working fine for me and a bunch of other people

 

it would be nice to know though what your docker run line is...

just a wild guess but you probably messed up ports .....

 

just a FYI

i just got the little popup asking me to update in headphones (33 commits behind)

clicked update and everything updated fine and no issues with any of the gui....

only thing i can think of really in your case is that or you are using this port 8181 already for something else

or you made a mistake in the docker run port assignment

Link to comment

Seems to be working fine here on a new install (installed it about an hour or so ago, and have started/stopped it a few times since).

 

Has anybody looked at running their own docker'ed musicbrainz server?  There's one on the docker repo, I have it installed, just not sure what I need to edit to make a correct DBDefs.pm file for it in a docker configuration..

 

**EDIT** Looks like I spoke too soon, now I'm seeing the same problems the other guy has.  My run line was:

 

<code>docker run -d --net="host" --name="headphones" -v /mnt/docker/data/headphones:/config -v /mnt/user:/media -v /etc/localtime:/etc/localtime:ro -e EDGE=1 -p 8181:8181 sacretagent/needo-headphones</code>

 

Not sure how to get back to a running system from here.  I didn't have it on it set up to run automatically, so not sure WHY it would affect the system after a restart.

 

I'm going to try manually removing the docker container, and do a forced restart, but I see a parity check in my future...

 

Link to comment

Seems to be working fine here on a new install (installed it about an hour or so ago, and have started/stopped it a few times since).

 

Has anybody looked at running their own docker'ed musicbrainz server?  There's one on the docker repo, I have it installed, just not sure what I need to edit to make a correct DBDefs.pm file for it in a docker configuration..

 

**EDIT** Looks like I spoke too soon, now I'm seeing the same problems the other guy has.  My run line was:

 

<code>docker run -d --net="host" --name="headphones" -v /mnt/docker/data/headphones:/config -v /mnt/user:/media -v /etc/localtime:/etc/localtime:ro -e EDGE=1 -p 8181:8181 sacretagent/needo-headphones</code>

 

Not sure how to get back to a running system from here.  I didn't have it on it set up to run automatically, so not sure WHY it would affect the system after a restart.

 

I'm going to try manually removing the docker container, and do a forced restart, but I see a parity check in my future...

 

mm wonder if it is not the cookie thing

how you access your headphones ? aka <ip>:8181 or <hostname>:8181 ?

if you use <hostname>:8181

then try accessing your unraid GUI by <ip>

or vice versa

 

Link to comment

I was just coming to report that I think it's cookie related.  I went through the manual docker removal process, still wouldn't come up.  Removed my docker.cfg to reset it back to defaults, still nada.  Figured I'd try IE, worked fine there.  Removed all references to anything I've installed today, and still no joy in Chrome.  Cleaned chrome history (cached files only though), still no workie, lol.  I then cleared ALL history including cookies, and the unraid UI comes back up fine.  Wish I had looked at WHAT cookies were in there for the unraid IP (I access my unraid box by the IP address, same for all of my docker stuff too, IPAddy:port).  Guess I'll use my hostname for unraid proper from now on, and IP address for any docker stuff that's running.

 

When I couldn't access the main emhttp pages, I WAS still able to access all my docker configs that were running, so it's just some cookie that's set by the headphones setup (or the headphones software proper) that emhttp doesn't like...

 

It's definitely cookies, just had the same exact problem with deluge docker.  Cleared cookies just for my unraid box's IP address, and the UI was able to be contacted.  Not sure exactly WHICH cookie it was, but that's the issue.

 

 

Link to comment

Headphones large cookies have always been a problem and it is not really about this docker but instead about headphones use of cookies. The trick of using different browsers to access headphones and your other unRAID websites, or using IP address instead of hostname, works because these cookies are kept separate. Firefox and Chrome cookies are separate. Also, any browser will keep cookies for different domains separate, and IP address is treated as a separate domain from the hostname.

 

If anyone is going to fix this it must be the responsibility of the developers of headphones, not the developers of this docker or even of unRAID.

 

Link to comment

In fact, next time it happens, try clearing your browser cookies instead of whatever other more drastic action you have been taking, and see if you can access the unRAID webGUI.

 

That's what I ended up doing when Deluge client did the same thing on my system.  So basically there's nothing wrong with the docker here, or deluge, it's actually how emhttp handles those large cookies that don't belong to it.  If emhttp's handling is fixed, then this won't happen.  Separate browsers for docker access and emhttp gui access fixes the problem, as does using hostnames for one or the other.  ANY docker that you create/use that uses larger cookies will break emhttp..

 

Link to comment

You may want to go back and change your post about needing 'stable' versions of Lazy Librarian, Mylar & Headphones, as it's not necessarily the docker/program, but their large cookies that are making the unraid webgui unstable.  (This is directed towards hilljd00).

 

I figured out it was cookies after the next thing I loaded after headphones caused the same exact issue (was Deluge in my case, if you add any columns in it, it'll kill unraid's gui as well).

 

It's actually not killing anything on the unraid box, since you can either clear all the cookies on your unraid IP (or hostname if you're getting to it that way) or just the larger-date cookies and get it back without touching the server at all.

 

 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.