Xed

Members
  • Posts

    10
  • Joined

  • Last visited

Everything posted by Xed

  1. Same problem, I selected to download 515.57 from the Available Versions section and it appears to have worked but I have not rebooted yet. Switching back to v515.65.01, it keeps throwing CHECKSUM ERROR and "Can't download Nvidia Driver Package v515.57".
  2. I have been using Tdarr AIO to reencode my libraries, first Movies, and now TV library. I did not notice this with the Movies but with Plex, every TV episode that gets converted to H.265 shows up a "new episode" based upon sorting by "By Last Epsiode Date Added", I guess because the file timestamp that is getting written for the re-encoded H.265 file has been updated. Is there any way to preserve the timestamp in Tdarr from the original H.264 file? It is very hard to track new TV show releases because every few minutes there is an older show that has since been assigned a new timestamp and now Plex thinks it is new again?
  3. Network type with what used to work (custom docker network - per Spaceinvader One video - Reverse proxy with LetsEncrypt) using "docker network create <name of network>" and choosing that as specific network causes the Docker to fail to bind a listening port on the correct network. I fiddled around with it until I tried "Bridge" as the network type for the docker and then it came up. So I am staying with 2.14 until a solution becomes obvious.
  4. Do you happen to be using a custom docker network (e.g. custom : proxynet), like with LetsEncrypt instead of the default "bridge"? This is the reason why the network does not come up properly with 3.0. I have tinkered around with this some more and choosing Network type = Bridge allows the docker to start-up correctly with a network. I don't have a solution to this if I want the Docker to be on the correct network for external access...
  5. I downgraded back to 2.14 for now, put the following string in the Repository field: haugene/transmission-openvpn:2.14
  6. Same issue, reverted to older image.
  7. I am seeing no difference if I use IP to access the share. I have noticed something else though. When I am connecting to the share via WIFI (Unifi AP), it does not take several seconds to refresh and resort the directory within Windows 10. I noticed this when I tested with my work laptop to the same share (on the same home network). I then plugged in an ethernet jack to the network and now I see the same behaviour with the laptop as well as my desktop PC. So there could be something in Windows or a network driver that is not queuing the data properly or out of order or maybe MTU mismatch, I don't know!
  8. Similar issues that I am observing with UnRAID 6.8.0 vs. 6.6.7 - Was not using 6.7.2 due to concurrent write issues observed. As I don't have a video to demonstrate 6.6.7 without downgrading my system from 6.8.0, I am showing you a similar example of the same media content but served from a Synology 1815+ over the same network (Gigabit) path back to my Windows 10 Pro PC and you can see the performance difference that I am currently observing with 6.8.0 and SMB shares. Synology performance that was equivalent to what I was used to seeing with UnRAID 6.6.7: Now with UnRAID 6.8.0, watch in the bottom left corner of the File Explorer window where you can observe it is loading and summarizing the count of the number of folders. You can see the folder sort order is the same yet it takes long enough to refresh the main folder to show it in alphabetical order first then finally revert back to the Date modified order. I am also seeing a significant slow down when processing a directory listing in PHP script that is responsible for renaming folders from a VM running within UnRIAD 6.8.0. This VM is running CentOS 8.x and is mapping the SMB share via CIFS mount within the VM back into the file share of UnRAID. This script ran very quickly on 6.6.7 but on 6.8.0, I can see it is taking upwards of 20-30 seconds while the server is completely idle. Server itself is a SuperMicro 4U with X9DRI-LN4+ motherboard and dual Xeon E5-2670v2 CPUs.
  9. I am also seeing this issue on 6.8.0 from a Windows 10 Desktop browsing a "Media" share with 5000+ directories with each directory having one or two media files at most. It literally takes 5-6 seconds for the directory to refresh while navigating from the sub-folder back to the media share again. I have a mirror of all of this media running in a Synology 1815+ which the same Desktop can navigate in and out of directories instantly. So this tells me it is an UnRAID problem and not something with my Desktop configuration. I did not experience this issue on UnRAID v6.6.7.
  10. So I am relatively new to Unraid but not new to Linux. I am frequently using SSH to do things that I find more efficient on command-line. Today I had a power failure and the server rebooted. After the reboot, or at least by the time the array was restarted, all my configurations were wiped, including command "history". So this tells me that root login is on tmpfs? How can I setup some preferences to survive either a reboot or shutdown/startup of the array?