[support] gfjardim's Docker Repository


Recommended Posts

Hi James and any others that are having trouble with the Triode Spotify Plugin within the docker container,

 

I have been battling this issue for about a month now and finally spent the day trying to get to the root.

If you change the network mode of the docker container to 'host' you will notice that the spotify plugin works great.  This confirmed that it was definitely a networking issue.  I realized that the whole plugin test was actually streaming from the remote player, it dawned on me that the player needs to stream from the LMS, duh.  You can see from the Information tab of LMS that the internal IP is NOT the same as the unraid host.  So, with docker bridge mode, it is NAT'ing into the container, and the ports you indicated as forwarding are indeed required, however, the IP that the spotify plugin is "announcing" to the client player is the internal IP which it cannot resolve.

 

So that was the long answer.

 

There is currently no way to configure the 'external IP' of the docker container to the player.  The solution was to jump into the code and hard code the external IP.  I found an example of this issue at http://forums.slimdevices.com/showthread.php?79706-Announce-Spotify-Premium-Plugin-%28Beta%29/page140

 

There were two files that I modified.

/mnt/user/appdata/LogitechMediaServer/cache/InstalledPlugins/Plugins/Spotify/Spotifyd.pm

/mnt/user/appdata/LogitechMediaServer/cache/InstalledPlugins/Plugins/Spotify/ProtocolHandler.pm

 

I changed the following lines:

from:

my $host = Slim::Utils::Network::serverAddr();

to:

my $host = "x.x.x.x";

 

where x.x.x.x is my unraid server ip routable from the player.

 

Hope this helps!

Jeff

 

Edit: I forgot to mention that the default port for the plugin is 9005.  Within the docker configuration, I forwarded both TCP and UDP on port 9005.

 

I don't use the Spotify plugin myself, but that's some awesome work there mate nailing down that...  ;D

Link to comment

Hi James and any others that are having trouble with the Triode Spotify Plugin within the docker container,

Yessss!!!!! :)

that's working great now. Thanks so much for finding the time to investigate this and to share your findings  8)

I can transfer everything across and fully decommission my old NAS now that all functionality is now replaced in my unraid install. great :)

thanks,

James

Link to comment

Hi James and any others that are having trouble with the Triode Spotify Plugin within the docker container,

 

I have been battling this issue for about a month now and finally spent the day trying to get to the root.

If you change the network mode of the docker container to 'host' you will notice that the spotify plugin works great.  This confirmed that it was definitely a networking issue.  I realized that the whole plugin test was actually streaming from the remote player, it dawned on me that the player needs to stream from the LMS, duh.  You can see from the Information tab of LMS that the internal IP is NOT the same as the unraid host.  So, with docker bridge mode, it is NAT'ing into the container, and the ports you indicated as forwarding are indeed required, however, the IP that the spotify plugin is "announcing" to the client player is the internal IP which it cannot resolve.

 

So that was the long answer.

 

There is currently no way to configure the 'external IP' of the docker container to the player.  The solution was to jump into the code and hard code the external IP.  I found an example of this issue at http://forums.slimdevices.com/showthread.php?79706-Announce-Spotify-Premium-Plugin-%28Beta%29/page140

 

There were two files that I modified.

/mnt/user/appdata/LogitechMediaServer/cache/InstalledPlugins/Plugins/Spotify/Spotifyd.pm

/mnt/user/appdata/LogitechMediaServer/cache/InstalledPlugins/Plugins/Spotify/ProtocolHandler.pm

 

I changed the following lines:

from:

my $host = Slim::Utils::Network::serverAddr();

to:

my $host = "x.x.x.x";

 

where x.x.x.x is my unraid server ip routable from the player.

 

Hope this helps!

Jeff

 

Edit: I forgot to mention that the default port for the plugin is 9005.  Within the docker configuration, I forwarded both TCP and UDP on port 9005.

 

I don't used this but for those who do, ya'll should buy him a beer!

Link to comment
  • 2 weeks later...
  • 2 weeks later...
  • 3 weeks later...

Happy New Year to all!

 

Thanks a lot for the BTSync docker. I've tried (with trail & error) one or two sync alternatives but now believe BTSync works best for me. How can I best get this updated to the most recent version? Additionally, is it possible for me to upgrade to the Pro version?

 

Again, many thanks!

 

gfjardim hasn't been seen for quite a while, you may be better off looking for containers from alternative sources, hopefully this is just a temporary thing, and gfjardim is still alive and well, just having to concentrate on other matters for a while, but dlandon has also had to take u the unassigned devices plugin due to gfjardims' leave of absence...

Link to comment
  • 2 months later...

Hi gfjardim,

 

I have your Transmission docker installed for months now without issue. However I have noticed my docker utilization getting larger and larger over time and it looks like Transmission was to blame. I had 4 movies downloading over the last few days and then my docker utilization hit 100%. After some testing I found that Transmission was storing some files in:

/var/lib/docket/btrfs/subvolumes/<TransmissionID>/data

Found about 12GB of my 15GB consumed in there..

 

Any ideas?

Link to comment

Hi gfjardim,

 

I have your Transmission docker installed for months now without issue. However I have noticed my docker utilization getting larger and larger over time and it looks like Transmission was to blame. I had 4 movies downloading over the last few days and then my docker utilization hit 100%. After some testing I found that Transmission was storing some files in:

/var/lib/docket/btrfs/subvolumes/<TransmissionID>/data

Found about 12GB of my 15GB consumed in there..

 

Any ideas?

 

No idea on what's happening. It's being an era since I updated this container, and I'm considering deprecating it. I do recommend you to migrate to Linuxserver's one.

 

Best regards.

 

Link to comment

Hi gfjardim,

 

I have your Transmission docker installed for months now without issue. However I have noticed my docker utilization getting larger and larger over time and it looks like Transmission was to blame. I had 4 movies downloading over the last few days and then my docker utilization hit 100%. After some testing I found that Transmission was storing some files in:

/var/lib/docket/btrfs/subvolumes/<TransmissionID>/data

Found about 12GB of my 15GB consumed in there..

 

Any ideas?

 

No idea on what's happening. It's being an era since I updated this container, and I'm considering deprecating it. I do recommend you to migrate to Linuxserver's one.

 

Best regards.

 

Okay cool, thanks for getting back so quick  :D

Link to comment

Hi gfjardim,

 

I have your Transmission docker installed for months now without issue. However I have noticed my docker utilization getting larger and larger over time and it looks like Transmission was to blame. I had 4 movies downloading over the last few days and then my docker utilization hit 100%. After some testing I found that Transmission was storing some files in:

/var/lib/docket/btrfs/subvolumes/<TransmissionID>/data

Found about 12GB of my 15GB consumed in there..

 

Any ideas?

 

docker caches volumes

 

and you get heavy numbers with things like transmission because they tend to download big files

Link to comment

I keep having dropbox exit with an error. 

 

2016-03-25 11:13:16,962 INFO supervisord started with pid 1
2016-03-25 11:13:17,964 INFO spawned: 'config' with pid 14
2016-03-25 11:13:17,965 INFO spawned: 'Dropbox' with pid 15
2016-03-25 11:13:17,965 INFO spawned: 'DropboxStatus' with pid 16
Continous console status not requested
2016-03-25 11:13:17,968 INFO success: config entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2016-03-25 11:13:19,043 INFO success: Dropbox entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2016-03-25 11:13:19,043 INFO success: DropboxStatus entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2016-03-25 11:13:22,969 INFO exited: DropboxStatus (exit status 0; expected)
2016-03-25 11:13:23,548 INFO exited: config (exit status 0; expected)
/opt/dropbox.sh: line 9: 21 Killed /home/.dropbox-dist/dropboxd

2016-03-25 11:13:32,773 INFO exited: Dropbox (exit status 137; not expected)
2016-03-25 11:13:32,809 CRIT reaped unknown pid 87)

 

Any suggestions?

Link to comment

Hi gfjardim,

 

I have your Transmission docker installed for months now without issue. However I have noticed my docker utilization getting larger and larger over time and it looks like Transmission was to blame. I had 4 movies downloading over the last few days and then my docker utilization hit 100%. After some testing I found that Transmission was storing some files in:

/var/lib/docket/btrfs/subvolumes/<TransmissionID>/data

Found about 12GB of my 15GB consumed in there..

 

Any ideas?

 

Think I've figured this out. Looks CouchPotato / Me was to blame.

 

I had set CouchPotato to use Transmission as it's download client. I had set the download location as /data from the CP GUI thinking that it would translate to the /data directory mapped to CP (/mnt/user/Downloads).

 

However it just told Transmission to download to /data.. which is not a directory mapped to Tranmission so it obviously just chose /var/lib/docket/btrfs/subvolumes/<TransmissionID>/data.

 

Testing now..

Link to comment

hmm... the dropbox docker doesn't seem to be syncing when adding files.  However, if I delete files... it seems to sync fine.

 

Suggestions? 

 

Here is what I see on the web log.

 

2016-03-30 20:28:35,178 INFO success: config entered RUNNING state, process has stayed up for > than 0 seconds (startsecs)
2016-03-30 20:28:36,182 INFO success: Dropbox entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2016-03-30 20:28:36,182 INFO success: DropboxStatus entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2016-03-30 20:28:40,179 INFO exited: DropboxStatus (exit status 0; expected)
2016-03-30 20:28:42,403 INFO exited: config (exit status 0; expected)

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.