lonix

Community Developer
  • Posts

    260
  • Joined

  • Last visited

Everything posted by lonix

  1. Feel free to make suggestions\requests for docker over at: http://feathub.com/linuxserver/linuxserver.github.io
  2. I run this: docker run --rm -v /var/run/docker.sock:/var/run/docker.sock -v /etc:/etc spotify/docker-gc
  3. I recently converted from Needos to the Linuxserver Plex docker. My only issue was waiting long enough after starting the Linuxserver Plex docker for the first time, it took about 5 minutes or so before I could access Plex. I think the docker may have been scanning (or changing file permissions or something) on my huge Plex metadata database. But all my setup and watched status all transferred flawlessly. yea the first time you start we fix the library to be more standard
  4. It Should go fairly easy, there should be a guide thingy on our website
  5. I'm not actually to far from adding something like this. But I'm currently looking at a advanced feature set that might happen. I will let you know if that happens
  6. It will update when the server starts up as the docker service and ergo all the containers will be restarted. As regards the auto-updating we make comment of this on the first line of our docker hub page that is linked on the first page of this thread. Ah...Good to know as that could become an issue if it updates and for whatever reason the update may not be wanted. I have, guess like you all have, seen some bad updates come out. Even Kodi had some poor released right down to video or audio stopping. I am guessing there is not a way in your containers to turn that off so it only looks when you tell it to or click on RESTART vs just doing it on every load? But then again, maybe it is not as bad as I am thinking it could be. I am just basing it on history of some updates that broke things. Thanks again for the help. I'll probably get spanked by linuxserver for saying this, but you are correct... Occasionally (thankfully not often) auto updates can cause problems with the program not working correctly. If you want to avoid auto updates, then you're probably going to have to switch to binhex's versions (but then you'll be a couple of versions behind). Myself, I run a mixture of containers from the various authors, and I absolutely love the support from linuxserver, but also have some reservations about the auto update features. But, that hasn't stopped me from running a few of their containers. You wont get spanked for giving your opinion. You are even right.Automaticly updateing the core apps (the app the container is about) is and always has been a "risk" a chance or a gamble if you will. however considering the 40+ containers we have, that has happened a total of 2 times the last year or so. 1. was a broken couchpotato. (fixed in less than 24 hours) 2. Was some users haveing trubble with the "new transcode" in plex. (we allready supply pickable version for that container) (fixed in 4 days). Anyhow here is the thing. When i first started the container collective (the one that turned into linuxserver.io), i had to choose how i wanted to approach these containers. Automatically updating the containers certainly had its downside. - A update could break the intended software. - And even worse, it could ruin what we call "appdata" for the user. Not automatically updating would mean: - I would have to monitor all the software's for new versions to avoid noise from anyone complaining about the "old" containers. - I would have to test every single update to ensure it did not break anything (because if a human build it, it can't go wrong) - If i do happen to publish anything with broken stuff, people would yell at me. (I don't like that) This\docker\i\myteam has since evolved a bit and we are always open to suggestions. and somewhat change. The current idea regarding automatic updates, if we find a problem (like with the plex thingy) we will look for a way to give users a static option for that container. (I am also looking into making general purpose no-update setting) But one thing that will never change is the philosophy behind our primary containers. Up-to-date, High quality\avalibilty, and great support.
  7. Please make a issue on github. And I'll look into it tomorrow.
  8. Try mapping it to /downloads ---> /mnt/user/appdata/SABnzbd/downloads The /downloads mapping must be identical on all containers
  9. Back to topic, i am useing thsis image on unraid, ill post my template soon
  10. Map it with host rather than bridge
  11. It gives the container access to the hardware clock
  12. lonix: any chance you plan on implementing this anytime soon. Maybe it warrants a separate docker image? I'm considering taking a look but if you're planning in it I may wait for your solution. Feel free to join our irc channel to discuss and potentially make a branch with me. But I'm abit uncomfortable promising anything with a fragile product like this.
  13. It's builder on top of Ubuntu and we use the plex bins provided by plex them self
  14. When you stop a container its like pushing the power button and all the appropriate things will happen.
  15. No longer "neutral": https://www.linuxserver.io/index.php/2015/11/20/changes-to-the-sickrage-container/
  16. Also as a sidenote nobody in the team does actually use the container
  17. we actually so that now. It helps pay for the servers and stuff. Check out linuxserver.io/donations
  18. I have one syncthing instance that syncs multiple user folders so running as one or the other wont work. For now I think I solved it by doing "ignore permissions" checkbox and unraid does default umask(though it's kind of dumb that it's 777 . Since only root has access to ssh, I guess it's ok. may I suggest several instances of syncthing?
  19. Be pasient it may take some time depending on the speed of your local mirror
  20. try rebooting the system. I can promise you that is not the fault of container
  21. Im interested, but can't do much here untill we get a invite or it becomes public