FDM80

https://forums.plex.tv/t/pms-1-32-6-hw-transcoding-issues-and-corrections/853757 For anyone that cycles their container and is surprised by a downgrade, looks like Plex pulled the latest builds and you will have 1.32.5 installed by default which will restore the ability to transcode with HDR tone mapping turned on.

According to a Plex forum post, they are aware of the transcoding issue in the latest beta server release (1.32.6.7468). The solutions tossed around are 1) disable HDR tonemapping (which seems to fix it) 2) revert to the last stable release 3) wait for the fix in a future beta release

Copy and pasted from the pihole entry on dockerhub. As of 2022.04.01, setting CAP_NET_ADMIN is only required if you are using Pi-hole as your DHCP server. The container will only try to set caps that are explicitly granted (or natively available)

I was fiddling with my plex container the other day and noticed that the template did in fact change. The part of the template with the directions about switching to advanced view to add the extra parameter, etc is no longer present anymore. The NVIDIA_VISIBLE_DEVICES environment variable field now needs to be added manually.

Looks like they fixed HDR Tone mapping with v.1.29.1. Anyone who stayed on v1.28.0 to maintain that functionality can try and upgrade. https://forums.plex.tv/t/pms-1-29-1-hw-tonemapping-testing-questions-and-answers/812785

Posting to document my findings and possibly save other people time if they run into the same thing. Hardware transcoding (quicksync) doesn’t work in 1.27.2.5929 when HDR tone mapping is enabled. Hardware transcoding works when disabling HDR tone mapping. Reverting back to 1.27.1.5916 restores full functionality. Hardware transcoding works with HDR tone mapping enabled.

Current message I'm getting when attempting to update. "bad file MD5"

Yeah, I can confirm that the disk spinning up bug is back. You load the Main tab and the disks will spin up one by one.

Just a small side effect of temporarily removing the plugin. I noticed that I kept getting the log entry: flash_backup: adding task: /usr/local/emhttp/plugins/dynamix.my.servers/scripts/UpdateFlashBackup.php update while the plugin was uninstalled every minute. I had to make sure the flash backup was deactivated prior to uninstalling.

I've been experiencing the same issue the last few days, not realizing that it could be caused by that particular plugin. I noticed the array disks would spin up when logging into the server, the Main tab would load, then within seconds I would see the drives spin up despite not having done anything after logging in. My system logs seem to support this behavior. I had one disk spin up overnight (probably plex) and then a few hours later spun down. They were spun down for the duration of the day according to the log file. The log shows the drives were spun down for about 12 hours. As soon as I log into the server, they spin up. I deactivated the flash backup functionality, signed out of the plugin, then uninstalled the plugin and now the drives no longer unnecessarily spin up when loading the Main tab.

I had been having my array drives spin up when I logged in and the Main tab loaded for the last few days. Signing out of the plugin, then uninstalling it for the time being worked.

It is not a container, it is a plugin. That is the link to the thread.

It is just the browser cache that needs to be cleared. On mobile devices I had to clear my cache. On Windows 10 in Chrome, all I had to do was a "Ctrl+F5" to refresh and force a bypass of the cache.

https://github.com/pi-hole/docker-pi-hole/issues/469 We'll see what comes of this.

You should check out this website. Ad blocking, telemetry, malicious sites, etc. that you can add to your pihole. https://firebog.net/ For starters, I'd recommend the below list which is all the ones on the website with a check mark next to them. It is the list that is least likely to interfere with normal browsing habits (ie: not as aggressive as some of the other lists) https://v.firebog.net/hosts/lists.php?type=tick

We are waiting for the official docker container to be updated. Once that happens, we will have caught up with the rest of the group. https://hub.docker.com/r/pihole/pihole/ If you look at the Tags tab, you can see the one we normally use (latest) is 7 days old and there is a dev version that is 3 days old.

I think the --dns argument in combination with the network type set to Custom: br0 doesn't play nice together. Just in testing, when I set the network type to Host, start the container, and check the log, the DNS sets properly to 127.0.0.1. I didn't try Bridge mode because there is a conflict with port 80 and I don't feel like messing with those settings right now but that is something else to look into. I don't have enough knowledge of unraid and how the container networking works to offer a solution. All I can do is point to the behavior I notice and hope that someone with more experience can shed some light. I get those other messages in my log as well but I don't see what negative repercussions there are from that so I personally am not concerned about those. At the end of the day, the 127.0.0.1 issue results in the container failing to resolve DHCP hostnames so you just see IP addresses in the dashboard. Mainly a cosmetic issue.

This probably has something to do with the "nameserver 127.0.0.11" behavior. https://github.com/pi-hole/docker-pi-hole/issues/410

I've never tried to change the log storage length so I'm not an expert. I think you can edit the "pihole-FTL.conf" file in the appdata folder to set when things get flushed. See link below. You should look at the "MAXLOGAGE" setting and / or the "MAXDBDAYS" from the looks of things. https://discourse.pi-hole.net/t/how-to-set-a-limit-to-log-file-length-to-maximum-used-log-file-space/6482 My understanding is that the logs are short term storage (default 24 hours stored in the image) and the database is long term storage (default 365 days stored in the appdata folder outside the image). As for if you are concerned about the logs being stored inside the container image, you could maybe do the following to move the log storage out of the image.

Looks like Pi-hole v4 just came out. https://pi-hole.net/2018/08/06/pi-hole-v4-0-released-with-ftldns-improved-blocking-modes-regex-docker-and-more/ It looks like they have brought diginc into the fold and have turned his work into an official docker. I assume the unRaid template will be updated with any necessary changes.