ColdChuck

Members
  • Posts

    8
  • Joined

  • Last visited

Converted

  • Gender
    Undisclosed

ColdChuck's Achievements

Noob

Noob (1/14)

0

Reputation

  1. thanks for the links above, tracked it back via github and arch already have the patch in place, i wondered why i wasnt seeing the issue Np! By the way, for anybody wanting to roll back, it is as easy as appending ":52" to the "Repository" field and update the container. Thanks a lot Finally a fix / workaround to the underlying problem. I got it working by adding this suffix. Working for me too. Thanks! Sent from my SM-G935W8 using Tapatalk
  2. Note I said the "current installation". If you ever have to reinstall for any reason anything you did from docker exec would have to be reapplied. Making your own docker with the changes already applied is the way to make them stick for a reinstall. Oh got it It's very strange that I'm the first one that encounters problems with https trackers on this container Take a look here, this might be of interest https://github.com/binhex/arch-rtorrentvpn/issues/10 Issue solved (i think) by altering the tTorrent config. Sent from my SM-G900F using Tapatalk How did you fix it finally? Having the same issue. It was working fine with https trackers up to a couple days ago but since then all I got are timeouts. ok so assuming your issue is this, if it isn't then please ignore this fix (shown in rutorrent):- Tracker Status: Tracker: [Peer certificate cannot be authenticated with given CA certificates] If this is the issue then one way of fixing this is to edit rtorrent.rc file (rtorrent configuration file) and add the line:- network.http.ssl_verify_peer.set = 0 This basically tells rtorrent to ignore ssl verification for all trackers. Just to be clear this works for the docker image i created, so im not talking specifically about the LSIO version here, but i see no reason why this shouldn't also work for the LSIO docker image. Yeah I already tried that but it didn't fix the problem. The error I have is: Tracker: [Timeout was reached]
  3. Anything you do from the command line within a docker only affects the current installation of that docker. Thank you. Now just to figure out how to get gcc installed on the docker lol Note I said the "current installation". If you ever have to reinstall for any reason anything you did from docker exec would have to be reapplied. Making your own docker with the changes already applied is the way to make them stick for a reinstall. Oh got it It's very strange that I'm the first one that encounters problems with https trackers on this container Take a look here, this might be of interest https://github.com/binhex/arch-rtorrentvpn/issues/10 Issue solved (i think) by altering the tTorrent config. Sent from my SM-G900F using Tapatalk How did you fix it finally? Having the same issue. It was working fine with https trackers up to a couple days ago but since then all I got are timeouts.
  4. My setup is also similar to what you're planning. My unRAID server runs my Plex server in a Docker and I use a Windows 10 VM connected to my home theater as the client. It works great. My graphics card is a GT720 and it's passed through directly to my Windows VM. My server CPU is a Xeon E3-1230v2 so it's a little bit slower than your 4790. I allocated only 2 CPU cores to my HTPC VM and it's enough. In addition to the Plex Docker and the HTPC VM, my server hosts another Windows VM and several other Docker containers with no problem.
  5. I finally had the time yesterday to work on my server. I'm almost done rebuilding the drive. So far it's looking good. My question now is how to make sure that my parity is good? Sent from my Nexus 7 using Tapatalk 2
  6. Thanks Joe for all infos. I'll try to rebuild my drive tomorrow and I'll report back the results. Chuck Sent from my Nexus 7 using Tapatalk 2
  7. Hi, 1st post here. I had to replace my parity drive. I ran the pre-clear script twice before adding it to the array. I ran the "New config" script and started the array with the new parity drive. It ran the parity check and found 206 errors. When I check the log I see a lot a errors on one of my data disk: Sep 22 18:29:43 Tower kernel: md: disk4 read error (Errors) Sep 22 18:29:43 Tower kernel: handle_stripe read error: 3469467840/4, count: 1 (Errors) and Sep 22 18:29:37 Tower kernel: res 51/40:ef:00:e1:cb/00:02:ce:00:00/f0 Emask 0x9 (media error) (Errors) Sep 22 18:29:37 Tower kernel: ata3.00: status: { DRDY ERR } (Drive related) Sep 22 18:29:37 Tower kernel: ata3.00: error: { UNC } (Errors) What should I do next? Run another parity check? Run reiserfsck? Replace the drive? I attached the smart report of the drive giving me errors. I had to zip the files, my syslog was to large to attach. syslog_and_smart.zip