exoexo

Same here... as well as understanding what the effect will be if the autostart is out of order? Edit: Followed the instructions in this post to fix it: https://forums.unraid.net/topic/142782-plugin-folderview/?do=findComment&comment=1317005

Thanks for the response. It appears just to be with that one file, or a couple of similar files, and not widespread. I won't worry about it for now and will go back to trying to fix my original problem (Plex Music not finding files...). Thanks again.

Hi - checking my logs for the first time in a long time and I see the below repeating failure many times a second (17) while the client is streaming (locally). The weird thing is I have absolutely no problem streaming from this client and plex behaves normally from it. Is this normal behavior? Thanks Using the plexpass docker. Sep 28, 2023 21:53:54.839 [22448818817848] DEBUG - Failed to stream media, client probably disconnected after 7471104 bytes: 104 - Connection reset by peer Sep 28, 2023 21:53:54.839 [22448818817848] DEBUG - Completed after connection close: [192.168.2.133:33220] 206 GET /library/parts/266219/1695938485/file.mp4?autoAdjustQuality=0&hasMDE=1&location=lan&mediaBufferSize=74944 (6 live) #30769 TLS 127ms 7471104 bytes (pipelined: 1) (range: bytes=186750843-) Sep 28, 2023 21:53:54.890 [22448670272312] DEBUG - Request: [192.168.2.133:33222 (Allowed Network (Subnet))] GET /library/parts/266219/1695938485/file.mp4?autoAdjustQuality=0&hasMDE=1&location=lan&mediaBufferSize=74944 (6 live) #3076b TLS Signed-in Token (xxx) (FireTV 4K Max) (range: bytes=542961712-) Sep 28, 2023 21:53:54.891 [22448670272312] DEBUG - Content-Length of /media/tv/xxx - S08E08 - Episode 8 SDTV.mp4 is 138505255 (of total: 681466967). Sep 28, 2023 21:53:55.023 [22448820927288] DEBUG - Failed to stream media, client probably disconnected after 8110080 bytes: 104 - Connection reset by peer

A little extra information... Per the faq: I was not able to mount it using "mount -o rescue-all,ro /dev/sdd1 /tempxfs". I was able to mount the disk in a terminal using the command "mount /dev/sdd1 tempxfs". When it was mounted, I observed appdata, data, domains and system directories. EDIT: Solved this (maybe by accident). Mounted using the above, then used xfs repair again (with the same outcome as above). Started the array and the drive mounted with original files intact.

I ran xfs_repair with the following results: And then I tried the recovery process here: Attempting to mount the drive results in the error: mount: /temp: wrong fs type, bad option, bad superblock on /dev/sdd, missing codepage or helper program, or other error. dmesg(1) may have more information after failed mount system call. Would very much appreciate any help!

Hi - I searched and couldn't quite find the same issue... apologies in advance if this is duplicated somewhere. I am trying to replace a SSD cache drive with an NVMe cache drive. I followed the short instructions here: Once the array started with the new cache drive, the cache drive reports the error: "Unmountable: Wrong or no file system". I stopped the array and remounted the old SSD cache drive and now receive the same error. I have stopped the array. My filesystem is xfs.... which is why the above didn't work. Is there a way I can now reinstate my old SSD cache drive for now? Thanks

Hi, hoping someone can help. I am getting the error "ERR_CONNECTION_REFUSED" when I try to access Plex. I haven't encountered this before and Plex has been stable since I set up my server more than a week ago. A couple of things changed at the same time as this error, and I am not sure if they are related.... 1) changed from unraid free trial to unraid pro, 2) I physically moved my server to a different ethernet point (but same static IP on my router), 3) I created a couple of users in Plex, whereas previously I just had one (now requiring a password for the super user). On my dockers page, under "Port Mappings (App to Host)" there is nothing listed for binhex-plexpass, whereas all my other (working) dockers have the port mappings listed. EDIT: I now realize this is normal behaviour. Any help would be appreciated... EDIT: turned out the problem was being caused by a faulty powerline ethernet adapter. Some troubleshooting and switching out of the adapter led to Plex working normally again. The weird part was that other dockers worked normally throughout. For anyone else with a similar problem, I had tried: Ensuring ownership of directories was set correctly with chown. Reinstalling docker. Ensuring IPV4 network settings were correct.

binhex - thanks for the response. I had meant that I had simply ran a speed test while VPN'd to each of the PIA nodes I was connecting to - and I was experiencing speeds while VPN'd that were close to the maximum for my ISP, so I don't think it was an issue with the speed of PIA's nodes (which is always my first thought when VPN'd). In the end I gave up, and switched to your ruTorrent docker. This worked great out of the box for me with good speeds while VPN'd, using the same values I had entered for the Deluge docker. This leads me to believe the problem was something within the Deluge client itself, that was restricting my speed while VPN'd, rather than your docker. My testing was with a public Ubuntu distro, so it wasn't like the tracker was restricting me either, and like I said, Deluge was fine when not VPN'd - very weird...

Hi, I am hoping someone can help me figure out why I am getting limited speeds when VPN_ENABLED is set to "Yes". When I have VPN turned off I get 18,000kb/s download, which is what Deluge is set to cap at. When it is turned on my speed is seemingly capped at 1,100-1300kbs (flat, not spiking). I changed no other settings to experience this difference. Things I have tried: Read through most of this 140pg thread! Followed SpaceInvaderOne's youtube guide for initial set-up. Followed binhex's newbie VPN and docker set-up guide. I have tried multiple VPN endpoints (Sweden, France, Czech Republic), and while VPN'd into these I get close to my un-VPN'd speed when testing outside of Deluge. I have downloads going to my cache drive. Interestingly, my unRaid server's LAN IP is 192.168.2.1, and it does not seem to matter whether I have LAN_NETWORK set to 192.168.2.0/24 (which I understand to be correct), or to the default of 192.168.1.0/24. Not sure if this has any relevance. Another thing is that the docker will choose a random port (e.g. 39605) instead of the assigned port (58846). I understand this to be normal behavior. I am unsure which port and IP to check to be Open. I have been using the port specified in the log lines "Setting listen_ports to (39605, 39605).." and the IP specified in the log lines "[info] Successfully retrieved external IP address 185.216.35.68". These values are both specified in the attached log - however - they return as "closed" when checking on yougetsignal.com - why would this be? This is a new unRaid installation (my first) and so I am not very experienced, and I'm at a bit of a loss as to why the docker is behaving as it does with VPN enabled. Any help would be appreciated!!