sparklyballs

This docker has been rebased to ubuntu xenial with s6 overlay, please make sure you backup your appdata first before you update to this latest image. For more information, please read : http://lime-technology.com/forum/index.php?topic=50793.0

and i'd expect a new install to do that... "The current latest image has the setting hash check = yes" and the only other time that hash check was an option in the config (on or off) was back in january.

That's good to know. I have that option set to off like I said so...makes no sense why it should recheck on start. It never did that before, and does it on a new install as well. So if there are no issues, and it's not working as designed, what is the next step? The current latest image has the setting hash check = yes by default, the only other time the setting was in the config file (either on or off) was back in january. so i'd fully expect a new installation to hash check, and considering the recommended upgrade path was a new setup of appdata from scratch, until you do that i can't predict the stability of any resultant setup until you use the upgraded image as recommended and designed.

no it doesn't... it has the hash set to check in the rtorrent.rc file. turn it off if it's a pain. This one? check_hash = no I believe that option is only to do a recheck on completion of a download. Either way, the setting is off according to my rtorrent.rc file. "The check_hash option executes a hash check when a torrent download is complete or rTorrent is started. When starting, it checks for errors in your completed files. " source... https://wiki.archlinux.org/index.php/RTorrent

no it doesn't... it has the hash set to check in the rtorrent.rc file. turn it off if it's a pain.

permissions are all or nothing, all of your torrents would behave the same if that were the case. i suspect it's more to do with the nature of docker itself , stop / restart the container on some instances can be likened to basically pulling the plug on a running computer.

my best bet is one of the default kodi addons is broken and is crashing the container. that's only a guess, but whatever it is, it seems to be something fairly universal and related to jarvis, a fresh pull of the alpine test container for Jarvis does the same, so do two of the competition (ie, not LSIO containers).

suggests to me reverse proxy, something not right there would be my best bet.

i suggest posting on the relevant forums for sonarr or nzbget about this issue.

xbmc/xbmc

This docker has been rebased to alpine with s6 overlay, please make sure you backup your appdata first before you update to this latest image. For more information, please read : http://lime-technology.com/forum/index.php?topic=50793.0

lol, damnit, it was in, i took it out because i thought i had put two copies in the dependency list, turns out i didn't... putting it back in again.

read from here onwards. http://lime-technology.com/forum/index.php?topic=47299.msg488637#msg488637

what is the problem ? they are created in /downloads on startup by default, you don't have to use them though, you can map another volume for instance and use that. the rtorrent.rc config is very specific and for more details check out.. https://github.com/rakshasa/rtorrent/wiki/CONFIG-Template

This docker has been rebased to alpine with s6 overlay, please make sure you backup your appdata first before you update to this latest image. For more information, please read : http://lime-technology.com/forum/index.php?topic=50793.0

Reading the various links, it's a php bug beyond our control. Nextcloud should take the lead on this, I don't think workarounds like that are something we should be looking at as a rule. Ya I agree with that. I was doing a bit more digging and owncloud is working using LDAP in the same AD environment and the main difference I see is related to a iconv problem I think. In the alpine image the php extention for inconv is undefined. iconv iconv support => enabled iconv implementation => unknown iconv library version => unknown Directive => Local Value => Master Value iconv.input_encoding => no value => no value iconv.internal_encoding => no value => no value iconv.output_encoding => no value => no value The implementation is unknown. From what I can find the way to resolve this is to use the libiconv extension instead. This seems to be an issue on Alpine. Is it possible to build using this instead of iconv? no, because it's not just an alpine issue, the bug is in many implementations of php from 2008 onwards and including php7. it is up to nextcloud to resolve this, if it were "fixed" and nextcloud then made neccessary changes, the "fix" would have been a waste of time and effort.

I am having the exact same issue... Tested with both sab and nzbget...nzbs from Hydra do not work when sonarr pushes to either downloader.... If i remove Hydra from the mix and use the individual indexers it works again.... They both error out and say the nzbs are empty... I posted on hydras GitHub issues thread, but no resolution yet.... Sent from my Nexus 6P using Tapatalk thread about it here. https://github.com/theotherp/nzbhydra/issues/336

This docker has been rebased to alpine with s6 overlay, please make sure you backup your appdata first before you update to this latest image. For more information, please read : http://lime-technology.com/forum/index.php?topic=50793.0

I can't reproduce this behaviour, just pulled this to test and set a password and it's working.... Are you changing anything else other than the password? Not changing the base path override or anything else? I also can set a password and log in and out etc...

This docker has been rebased to ubuntu xenial with s6 overlay, please make sure you backup your appdata first before you update to this latest image. For more information, please read : http://lime-technology.com/forum/index.php?topic=50793.0

Reading the various links, it's a php bug beyond our control. Nextcloud should take the lead on this, I don't think workarounds like that are something we should be looking at as a rule.

This docker has been rebased to alpine with s6 overlay, please make sure you backup your appdata first before you update to this latest image. For more information, please read : http://lime-technology.com/forum/index.php?topic=50793.0

something very specific to unraid about the location of the WORKDIR folder, didn't affect everyone as it works for CHBMB. anyways, i've taken it out and repushed the image to the hub. and 514 B is possible if you have other containers using our python base.

you don't. http://imgur.com/a/FLANd set your folder in the add/edit docker screen like this. then, don't change the /data in the setup screen for nextcloud. /data and /mnt/user/nextcloud are the point where the folder inside the container and the folder outside the container become the same point, provided you set it as shown in the add/edit screen.

don't change the storage location in that window from /data /mnt/user/nextcloud doesn't exist inside the container