Wispa

Did this ever happen again to you OP? Its been happening intermittently to me also, ill try and grab logs next time but its a pain in the ass to fix - cant SSH to cleanly reboot (but can still ping the server curiously) and almost always requires a hard reboot to resolve. Starting to think its my network controller, which is the Realtek 8111, and it seems to always happen while I'm direct playing from Plex to a browser. Another curiosity, if I have something like a Plex movie already streaming when it happens, the stream will stay connected and will still play but will be very slow (buffers, but doesnt disconnect). So it wont accept new connections, but the old ones stay active, which again points to mass packet loss via the network controller.

Okay did a reboot and finally 6.11.0 stable is showing as an optional update - before both stable and next releases were showing as "up to date" without an upgrade option - even when manually checking for updates.

Really at a loss here - any idea how to prevent this rather annoying message from showing - FYI I have never been out of date, it just started showing for no reason even though I'm on 6.11.X

I just found this also, here is the URL to join the BETA programme as the beta version fixes this issue. https://play.google.com/apps/testing/com.plexapp.android

I think you're on the right track though because I tested 3 films just now and noted their TrueHD bandwidth requirements: IT Chapter 2 (2160p, UHD REMUX DV HVEC TRUEHD+ATMOS) - TrueHD audio track = 3.4Mbps Spider-Man No Way Home (2160p, UHD REMUX DV HVEC TRUEHD+ATMOS) - TrueHD audio track = 4.1Mbps Moana (2160p, UHD REMUX HDR HVEC TRUEHD+ATMOS) - TrueHD audio track = 7.7Mbps Results are as you suggested: IT2 plays fine, struggles when navigating Spider-Man struggles, eventually plays, but buffers and you cannot navigate Moana won't start. If the docker container is limiting the transcode ability for direct play, (which doesn't make sense to me by the way, direct PLAY, not stream, mean no transcode?), then surely Plex forums won't have a solution... Since it's direct play, I'll look on Plex forums and see if it's an android Plex client issue

You've misread, I don't use the crappy TV apps....they're crappy and completely defeat the purpose of a lossless setup. I am using RAM transcoding, but don't recall ever setting a limit on it - when playing a 4k TrueHD film using direct PLAY it's using 38% RAM total, so don't see how it's capping out like you suggest?

Good shout and could well be the client, but very difficult to test since lossless requires such a specific setup; very few players that will support lossless output, even the PS5 and LG OLED GX plex apps wont support it and will only output lossy regardless of what bandwidth you give it - Only way we can test is if we have multiple clients on this forum. So with that in mind, im running a Nvidia Shield Pro; i've uninstalled/rebooted/reinstalled the Plex app (latest current version), and have found the client will play some movies reluctantly with TrueHD lossless direct play (no ability to pause/rewind/forward), and just flat out refuse and crash the app with other movies. All movies are 4k, DV, HVEC, Remux, MKV - video stream seems fine. If someone else that has this issue uses a different client please do post. Thousands of lines of this error being logged on server: Apr 11, 2022 14:37:27.898 [0x1519128aab38] ERROR - [Transcoder] Error while decoding stream #0:0: Invalid data found when processing input Apr 11, 2022 14:37:27.898 [0x151912aceb38] ERROR - [Transcoder] [aac_lc @ 0x14f36b3050c0] channel element 3.12 is not allocated

+1 on this issue, I too am now having issues when attempting to play lossless TrueHD MKV movies. I've tried force update, and re-downloading the Codex folder with no improvements. The issue presents and the picture (HDR or DV) loading, and then halting when attempting to play TrueHD audio. The movie plays when changing the audio track to the lossy DD+ track. Some movies will successfully start, but any kind of pause or rewind/progress function will trigger the buffer and will ultimately crash the Plex app. There are no bandwidth issues, and the server has plenty of resource available - this is definitely a new bug Edit: Did some more testing and found: - TrueHD plays when being transcoded, and only fails when attempting direct play - Lossless DTS doesnt seem to be affected

FYI latest update 4.4 does not solve pathing issues, i've had to roll back to 4.3.9-1-01 again

Worth noting that switching back to OpenVPN fixed the issue, somewhere within the Wireguard config its not enjoyed the local IP change.

So its definitely VPN related, PIA Wireguard wont connect since the local network change - is anyone aware of particular firewall rules required for WG PIA routing? I'd have thought just being internet facing was enough?

Sorry, typo 😅

Morning all, Just a quick one I hope! I've recently done a network re-structure and changed by Unraid IP from 192.168.1.10 to 192.168.150.10. All containers picked up the new IP automatically, and for the qbittorrent container I changed "LAN_NETWORK" from 192.168.1.0/24 to 192.168.150.0/24 However, it doesnt want to connect, what I thought was a simple change has left me baffled, any immediate ideas before we dive into logs?

+1 on this - not only does it not see containers that are routing via another (i.e. Jackett going via OpenVPN Client Container) - but it seems to stop working all together when a VPN container is active.

Afternoon lovely community! Firstly, thank you binhex for your hard work as usual, this is a fantastic docker and it works flawlessly for me. Just wondering is there is a way to, via the docker console, enable and disable the alternate download/upload speeds? Use case is that, when I find myself away and no-one is home I want to be able to jump on Unraid and crank up download/uploads. I dont really fancy setting up reverse proxies in order to access QBT directly, it would be useful if there was a command to do it right from Unraid. Is there a command that would achieve this? Cheers, Wispa.