PeterB

Community Developer
  • Posts

    2714
  • Joined

  • Last visited

Everything posted by PeterB

  1. This is such wonderful news! I'll wait for the official rc2, but I'm getting excited!
  2. I've already been running 6.9.2 for some time and have just encountered this problem today - all containers are showing version as "not available" Is there a new fix?
  3. Are you able to provide guidance on installing/using this docker? I'm getting fed up with having to reboot my clients every time the unRaid nfsv3 craps out. I still don't understand why there is such resistance to implementing nfsv4 natively on a file server OS. Perhaps someone can create an unRaid version of this docker, and include it in Community Applications.
  4. Is anyone here still using CouchPotato docker? I find that it is a lot of the movies it offers to download are either 'Unknown' or totally the wrong movie. Until a few weeks ago, it was still working pretty well with just th occasional 'Unknown' being offered. For instance "Marksman, The (2021)" is offering a download entitled "Zack Snyder's Justice League (2021)". As far as I am aware, the only connection between those two movies is the release year. This makes CP rather useless - does anyone know how to fix it? I use RARBG and ThePirateBay as my main search tools, both with and without Jacket.
  5. HELP! I was trying to get binhex-couchpotato to connect through binhex-delugevpn once again. I made edits as described in Q24, but couldn't find the 'VPN_INPUT_PORTS' env var. I believed that I had to delete the delugevpn container and re-install it, and tha this would pick up my old settings again. However, now when I go to the unRAID 'Docker' page I simply see a never-ending hourglass and there is no delugevpn showing. Oh, and binhex-couchpotato always says 'rebuilding' under the version column. What do I need to do to get delugevpn back (with all my settings)? Edit: I managed to get into couchpotato settings and blank the 'Extra Parameters'. This seems to have fixed the hourglass problem. I now seem to be in a position to re-install delugevpn with my original settings .... I will carry on and see where I get to ....... Further Edit: Ah, but I still don't have VPN_INPUT_PORTS .... still stuck .... ... and no, I don't have a container version specified in the repository.
  6. 6.8.3 to 6.9.0 was over a year ... don't hold your breath!
  7. One of my private plugins requires certain users to be configured in the /etc/passwd file. I used to achieve this be ensuring that the required users were present in /boot/config/passwd and, during system startup, that file was copied to /etc. Since upgrading to 6.9.0, this passwd file copy no longer seems to be happening. I don't remember whether I performed the copy, or whether the standard system was doing it. Has something been changed which would account for this?
  8. Possible, but why have I not seen it happen before? It was running for a full ten hours immediately after the reboot from the v6.9.0 update.
  9. Hmmm ... weird! I've just stopped/restarted the CP docker, and the reads appear to have stopped!
  10. I have just upgraded to unRAID v6.9.0. It appears that CP is now keeping all my media drives spinning permanently with around 2k reads per hour on each drive. This wasn't happening previously. Does anyone have a clue as to why this is happening and, better still, how to prevent it?
  11. Thanks for the response. Yes, I do have directory caching enabled. Researching possible conflicts, but not found any information yet. UPDATE: It appears that this issue is being caused by the BinHex Couch Potato docker.
  12. Just upgraded from 6.8.3 to 6.9.0 today. Now, none of my drives are spinning down. Openfiles doesn't show anything open on the drives I would expect to see spin down, but something is reading from them (~20k reads on each drive, in a little under ten hours). Turbowrite is disabled (Data drives spun down: script not running, Write mode: unraid determined). How do I identify what is accessing the drives in question? Should I revert to 6.8.3?
  13. I've just (ten minutes ago) loaded the latest update, and the AutoAdd plugin seems to be working once again.
  14. Is anyone else using the AutoAdd plugin? It used to work a treat for me but, sometime recently, it has stopped recognising new .torrent files. I don't think I have changed any settings but, in any case, changing settings shouldn't stop it recognising new files entirely. It cannot be an installation problem since AutoAdd is a 'standard' plugin - part of the Deluge distribution. I would love to have it working again - any ideas/suggestions?
  15. So why does mine keep creating (corrupt) .torrent files?
  16. I must be missing something - for the life of me, I cannot see where/what to set to use magnets.
  17. I have posted some of this info in a reply in the delugevpn thread, but I think it really belongs here. I find that the Jacket rarbg fetcher sometimes fetches a 1.3kB file containing html which says something about enabling cookies, instead of the legitimate torrent file of around 80kB. I'm still struggling with this. Resetting the configuration of the rarbg fetcher in Jacket seems to make it work once, then the next time it fails again. In case it makes a difference, I'm using Jacket with CouchPotato. Has anyone else encountered this or, better, found a solution. I've never had any success with the 1337 or isohunt fetchers.
  18. I'm not sure whether it is the same issue, but I find that Jacket sometimes fetches a 1.3kB html file from rarbg which says something about enabling cookies, instead of the legitimate torrent file of around 80kB. I'm still struggling with this. Resetting the configuration of the rarbg fetcher in Jacket seems to make it work once then the next time it fails again. Further, testing a fetcher from within Jacket seems to set the watch inactive in the deluge AutoAdd plugin.
  19. Okay, so I left the WAN for port 1337 redirected for more than an hour. This time a /tmp/portfailure file popped up (no /tmp/dnsfailure), but even that disappeared when I re-enabled the WAN, and everything started running again.
  20. So, I reset the port 1337 route back to WAN2, the 'dnsfailure' file disappeared and torrents have restarted - exactly as intended. Hmmm .... what else?
  21. Scrub all the following - the 'dnsfailure' file has just appeared! Ah, I've just realised that this probably won't work. If the dns query isn't going via the tunnel, then simply changing the routing for the tunnel won't cause it to fail. This may have something to do with why I'm experiencing this issue - let me explain .... My main internet connection is unmetered fibre on WAN2. If that connection goes down, I (manually) revert to a metered LTE connection on either WAN3 or WAN4. I don't want to use the metered (PAYG) connection for torrents - first of all, it is much slower and secondly, relatively expensive. To prevent torrenting via LTE, I have a route set up so that any traffic from Tower to destination port 1337 will only go via WAN2. However, if I bring up WAN3 or WAN4 the DNS query will still succeed and failure may or may not be registered, depending on how soon I (manually) bring the alternative WAN into use. I suspect that you are correct, though, that deletion of the temporary file may be failing. To test, without taking the rest of my network offline, I guess that I will have to route all Tower traffic to the unconnected WAN. This will stop my email and a few other services for a while, but shouldn't cause a major issue. Just to confirm, the dns query will go to the configured NAME_SERVERS (currently 1.1.1.1 & 1.0.0.1), and not to my local dns server?
  22. Too late - I'd already restarted! I'll try replicating the problem .... If I change the routing so that the tunnel goes to an unconnected wan, it should have the same effect as Internet outage.
  23. Yes, I'm using wireguard now. As far as I can tell, the Internet went down around 10:32 on Jan 23 and it came back around 8pm on Jan 24. I cannot see any change in behaviour to indicate that the docker was aware that the Internet service had returned. supervisordCopy.log.zip
  24. Hey @binhex Some time ago I reported an issue where the tunnel didn't automatically re-establish after a length period of Internet outage. You identified a change which might address the issue. Unfortunately, the problem still appears to persist. We had an Internet outage which started around 11am on Saturday and it came back around 8pm on Sunday. The deluge vpn still doesn't seem to be back up, almost two hours later. I'm sure that the vpn will come up if I restart the container. I have taken a copy of the supervisord.log - unfortunately without debug turned on. I can send it if it might be of use to you. If needs be, I could try to reproduce the problem artificially, with debug enabled.
  25. Okay - I refuse to use radarr because I hate having a new folder created for each movie - what's the point? It seems ridiculous, to me, to maintain a lot of folders, each with just a single mkv file which, as far as I'm aware, is still enforced by radarr. If radarr handles the separation of incomplete and complete folders, then fine - as long as you don't mind unnecessary nodes in your file structure.