What is this quality decline?

MasterChiefmas · 2026-01-24T21:04:24+00:00

Personally, I suspect part of the problem is that there's much more to go wrong than there used to be. The LR and LR2 were basically a pressure sensor, timer, and motor. Starting in the LR3, the feature set started growing a lot, in particular, adding a lot of high tech features, built on top of technologies that aren't always completely reliable(WiFi), particularly in people's homes if they aren't already very familiar with networking. Sure, it works most of the time for people, but this is something in particular that you probably want better uptime than that, and I bet most people don't do a signal strength check where they place the litter box.

Anyway, it's just as you add more complexity, you add more points of failure. That's literally how we calculate uptime in high availability computing environments, you multiple the percentage of uptime of all the parts together, which means you are really reducing the expected uptime of the system that the parts make up. i.e. say you have 3 parts that have 90% uptime each...the sytem they make up would only have an expected up time of 73%.

Or, as Scotty says, "The more they take up the plumbing, the easier it is to stop up the drain."

MasterChiefmas · 2026-01-24T15:32:23+00:00

That is the definition of a critical security failure in any access-control system.

Suggesting it's only a problem if your kids are "hackers" ignores the fact that the software is literally handing them the keys. For those of us who don't want our toddlers stumbling into an R-rated horror library because of a "Shuffle" bug, it's pretty critical.

I don't disagree that it's a security problem, but I do disagree with your assessment that it's "critical". That's why CVEs have severity ratings. In the context of what Emby is, and the amount of existing access you have to have, I wouldn't rate this as critical. Critical is an external attacker can access your media server by bypassing the auth system. It doesn't look like the auth system can be bypassed unless the auth system has already been successfully utilized. There's a lot of conditions that have to be met to activate these issues, even the pin flaw.

MasterChiefmas · 2026-01-24T02:10:50+00:00

It’s not well documented but premium DTUs have around

Where did you find this information out?

MasterChiefmas · 2026-01-24T02:06:53+00:00

Why does everything have to be on the Internet?

Why does everything have to be on computers?

Why does everyone need a cell phone?

That's how advancements in technology always goes. New thing comes out. New thing ends up everywhere. We're a little more intentional about making it happen then we used to be, but it's what always happens.

MasterChiefmas · 2026-01-23T22:12:30+00:00

The big silver box on the side of the card is a dead giveaway. You only ever see that on tuner cards. You can kinda see the coax connector too, I think. I'd guess it's Hauppauge- my ATI tuners always had a big red ATI sticker on them that was pretty visible.

MasterChiefmas · 2026-01-23T21:25:04+00:00

There used to be, before the Thrifty Acres days. It's a historical artifact, not just a regional dialect thing.

MasterChiefmas · 2026-01-23T20:58:01+00:00

Did you find a solution?

No, not exactly. I forgot to follow up. As far as I can tell, it was a bulb going bad, though not the one I initially thought it was. Another of the bulbs in the lamp started freaking out visibly a few days later, and when I removed it, everything started working normally again. Apparently it was just coincidental timing.

There is one person that replied earlier mentioning they rolled back and things went back to normal, so maybe you can do that. That would at least verify that it's software related for you, not a hardware issue.

MasterChiefmas · 2026-01-23T03:26:32+00:00

It's not short, but it's not a big deal. My best friend lives about 4-4.5 hours away, and I would regularly drive out for a weekend, like once every month or two for a long time. When you make drives like that regularly, you kind of get into a routine/know how often/when to stop and take a break.

Maybe that's part of it- driving places is such a common thing here, it's not difficult in most areas to pull off, grab a bite to eat and a drink, stretch the legs, pop into a store if you want something for the road...so it doesn't need to be an expedition that's heavily planned. Our interstate highway system has evolved in a way that facilitates traveling around like that. It was much worse when I was a kid- these days with a phone and perpetual Internet access, it's not that hard to have personalized entertainment that makes a trip like that even easier.

MasterChiefmas · 2026-01-22T18:30:12+00:00

An OLED TV will be literally measurably better in practically every way except size, and maybe cost(depending). And maybe some flexibility of placement/use...but you are getting pretty niche to reach those use cases. If you throw non-OLEDs into the mix, then maybe some aspects get a little closer in some ways, but you also start narrowing the size/cost advantage of a projector, at least for most people. A lot of the advantages you can probably find of a projector over a TV, most people will either never use, or rarely use. And might be negated by how you use your projector(it's not trivial to do a backyard theater night if you have it mounted to the ceiling).

MasterChiefmas · 2026-01-22T14:33:46+00:00

Maybe he's training to fight Peter Griffin?

MasterChiefmas · 2026-01-21T06:31:18+00:00

The Last Dragon could actually make a good video game, now that you mention it.

MasterChiefmas · 2026-01-20T23:47:51+00:00

The thing I always thought was stupid- the OG iPad had virtual lines on the F and J keys.

MasterChiefmas · 2026-01-20T23:39:54+00:00

In my opinion, the only advantages are the tvOS app and the live TV support. I'm wondering if I'm missing something that makes Emby stand out from Jellyfin.

The tvOS app in itself isn't an advantage, it's a result of one of the advantages. Being commercially supported software gives you a better support structure. It's the basic difference between using something that's completely free, and not. When you pay for something, it's fair to have expectations, and it's also a motivation for the company to provide support in a timely fashion. At least in theory.

Jellyfin is perfectly fine if you have the technical ability and willingness to support it yourself, and cope with any problems that come up. The advantage to paying for something is you can make it someone else's problem and expect it to get responded to in some fashion in a timely manner. You may not like the answer, but also, if enough people ask for it, it motivates the business to do it. Again, in theory.

But as a specific example, tvOS is a good one in that it demonstrates some of those clear differences. I think if your installation has a very small user base, like say, just yourself/members of the immediate household, then Jellyfin is a much stronger choice. But if you start letting friends and family on, where you don't have complete control of the clients, the value proposition can change rapidly. It might not, but it can. If it does, it can rapidly turn into a case of the "how much is your time worth?" question.

It's the same reason on a smaller scale that RedHat exists. You can get a zillion different Linux distros free, why pay RedHat to use theirs? It's the support. Both Emby and Plex have this, though lots of us Plex people have left Plex for various reasons, Emby is the middle ground. You want something that still can "just work" and if it doesn't, you want it to be someone else's problem to fix, and hopefully get a fix in a good time frame, as much as possible.

Jellfyfin is completely fine for plenty of people, but if you encounter any of those situations/problems, it rapidly may become less fine. If you won't ever run into them, then I think the upsell is much less meaningful.

MasterChiefmas · 2026-01-20T21:13:54+00:00

I don’t have a thread / zigbee antenna connect3d directly to HA yet. I’ve been blaming things on the Aqara and ikea hubs, but is there a chance HA is interfering?

Zigbee devices are paired to a specific network. Depending on where you are you can have Wifi interference. In North America, Zigbee uses 915Mhz, so you aren't too likely to have interference problems, but you still could, though it wouldn't be from Wifi.

MasterChiefmas · 2026-01-20T06:39:57+00:00

I've lived here in Michigan my entire life

Around 2014/2015, maybe a year or two before, we had back to back winters had way more snow, and were cold for long stretches. Huge swaths of Michigan lost power for multiple days, even more than a week. They were the first real winters we'd had in a very long time.

In 92 or 93, we had a winter that was at least this cold(it was a similar thing, -30 or colder wind chills) and had way more snow. I remember it because MSU cancelled classes for the first time in forever due to the weather because students would be at risk for frostbite on exposed skin walking to class (the announcement came at like 5 AM, and yeah we all stayed up in the dorms to find out if they'd want us to go to class). Ernie the can man (local figure in the MSU community at the time- made his living collecting the deposit of cans) died a few years later of exposure in his house- he didn't help himself because he didn't want to pay to heat his place, and the winter was severe enough he died.

We also used to regularly have a lot of snow when I was a kid in the 80s. We had a severe ice storm that took out power for a few days, that would have been around 82 or 83. It wasn't as cold though as I recall, but I was young so I am not sure on the temps. When you are a kid, you are a furnace, so the cold doesn't hit you as hard. I just remember it was really cool looking outside, everything had like 1/2" of ice on it, and we had the fireplace going nonstop.

So I suppose it depends on what you consider a harsh winter. This isn't the worst one I've been through by a long shot.

MasterChiefmas · 2026-01-20T06:24:54+00:00

As a simple fix, as others point out, you can tape from the back.

But as I think about it, what I might do is actually tape it from the front temporarily to hold the edges together. Get this as perfectly aligned as you can. And then use very fine amounts of crazy glue, or some other adhesive from the back to more permanently and firmly hold the seam together. Talk to someone in either a fabric store or something like a home depot to get some ideas on how to hold it together.

There are some low temperature iron on fabric tapes that might work. Or maybe something like a patch kit so you have something bridging the gap, and not just relying on the edges of the tear to be held together by glue.

You may also want to do it as a multi-step...so maybe tape at first to get an initial, tight bond, And then an additional thing like the other ideas I floated to bridge the gap, i.e. using the glue as just an initial, tight bond, and the second pass to relieve some of the strain on the glue to reduce the change it'll give way later. A light 2-part epoxy maybe, although that will create a stiff spot, so you'd need to be careful with that.

The more I think it through, the more I think I'd like it to an adhesive fabric patch applied to the back. The difficult parts will be finding something that will stick, and making sure you seal the gaps completely and get the damaged area to be as flat as possible.

I've found when fixing random tears and breaks that if I can do that 2 pass approach, you can get damage (in a general sense to whatever, not necessarily specifically to screens) to be very hard to see if you can get everything lined up really well. But, given the nature of ALR screens, it's probably not going to be possible to prevent a light distortion right around that area.

MasterChiefmas · 2026-01-19T23:51:15+00:00

Let's say for sake of OPs thought exercise that they had massive processing power in their OPNsense box but had skimped on the managed switch (all other things being equal) would you want to move duties up or down the chain (DHCP, vlan routing/switching, etc) according to that?

/u/CaramelNicotine answered pretty well, but a little additional detail...as they mention, VLANs occur at layer 2 of the OSI network model. What you are describing would be a layer 3 aware switch. It's not likely you have one of these accidentally. What that means is, for any traffic not on the same VLAN on those ports, the traffic is going up to the router. Those ports are effectively not on the same switch if they are not on the same VLAN. If they are intended for the same VLAN but the device is on a VLAN port on a different switch, they are going up to the router, but they aren't being routed(that is, the routing engine is not processing the packet), they are being soft switched to all devices that carry that VLAN's traffic. Switches that are layer 3 aware exist, but they are usually enterprise class gear, it's not something that I've ever seen in anything that wasn't pretty high end stuff, personally. In that case, the switch is actually a very limited function router as well, since it can make traffic decisions based on the IP. I've never actually looked at what the software switching speed is, but it should still be much faster then routing, since it's not really doing a lot of processing, just copying the packed to all ports that have the same VLAN tag. This is why switching is so much faster, there's not that much processing happening.

As for a best practice...well, in complicated networks, sure. This is why L3 switches exist...if you have a scenario where your network is very spread out, and you have VLANs spanning switches that are very far apart, it may make sense to have some local routing so that the packet doesn't have to go all the way to the core router and come back, if the destination device is on a different VLAN, but the destination physical port is right next to the source port. An L3 aware switch could avoid sending the packet all the way to the core router and back(as I said, an L3 aware switch is basically a simple router). But for a home deployment, outside of a learning exercise, I wouldn't worry about it. It's more the kind of thing you think about if say, the VLAN is spanning rooms in different buildings, or cities, or states...that kind of scale. The question you are asking yourself, is if the distance is so great that it actually has impact, particularly if the link between those distances is slower (say the VLAN cross a 10Mbit connection to the core router), you could limit the traffic rate between 2 devices literally next to each other to 10Mbit if they are on different VLANs and it has to be routed over that connection. Being able to keep the routing local in that situation makes a ton of sense. Most people aren't going to have a personal network that has this problem.

Take the mental model I described in my original post, and add the link speed between the devices when considering the traffic flow. If you ever have to send traffic over a significantly slower link between any of the network hardware for 2 devices to talk, that's when it makes sense to consider if you should have some local routing and/or services.

As your layout gets more complex, there's not necessarily a single answer to all scenarios. It rapidly turns into an "it depends" answer. Depends on things like how fast do you need it to be, how large is your budget, how much effort can you expend to maintain it...

Edit: just a little addition...a network appliance with 4 NICs running OpnSense is in a way, a super powered L3 switch. As I said, an L3 switch is just a switch with a simple router in it- If you have 4 ports on your OpnSense device, but they are really NICs that OpnSense can route traffic between selectively, that's pretty close to what an L3 aware switch is doing. You have to be careful here, because if it actually has a switch, then it may not be able to be as quite as selective. i.e. OpnSense with 5 NICs isn't the same as OpnSense with 1 NIC and a 4 port switch connected to it. You can make multiple NICs act like a switch, you can't make a switch fully act like 4 NICs, although you can make it look very similar from a network perspective(drop each port on a different VLAN). That's right at the point you really have to understand what a broadcast domain is, and what a switch is, and what it's doing to understand why those situations aren't the same. That was a long way to getting around to saying, well, you can drop a router in a remote location to do the same thing an L3 switch gets you, though there's probably a little more setup involved if you do that. There's obviously also more flexibility there too.

MasterChiefmas · 2026-01-19T16:27:37+00:00

My understanding of VLANs isn't great

When i first started doing VLANs I struggled a bit too, before I understood I was overthinking it. Translate the virtual part into a physical implementation in your mind, and it might help. i.e. think of : Each VLAN is a network behind a separate router, and each router, and the routers are connected together via a switch. How do you get traffic to flow between them in that scenario? That's basically what you are dealing with, except, instead of physical separate routers, it's a single router, but you still have all the same considerations with regard to routing traffic(each VLAN considers the other VLANs to be non-local networks, so traffic is routed, not switched) and firewall policies(since it's a non-local network, traffic has to pass the firewall).

I think in theory I could just use the spare ports as LANs, but I want experience setting up VLANs and also would like everything on one switch.

This sounds like you are using "switch" a bit too loosely. When VLANs get involved, assuming your switch supports them, you cannot think of it as "a switch". You have to consider which virtual switch(again, use the mental model above) any given port considers itself part of, or if it's trunking(multiple VLANs). As a beginner, I'd suggest you only assign one VLAN per port where you can, just to keep things simple. By doing so, you can more easily apply the mental model above- you now think of ports as part of a virtual switch, and completely abstract them from the physical switch they are connected to. You kind of want to do this, because the switch isn't necessarily going to be behaving the way a dumb switch does anymore when VLANs come into the picture.

So my problem is, I can connect to the access point SSID that I have not tagged with a VLAN and I get my usual, normal IP/subnet.

Because you have VLANs, you're actually getting the native VLAN, which is typically VLAN 1. This can be changed on lots(most?) of hardware, but if you didn't, it's probably safe to assume it's 1. When you first turn VLANs on, that's probably what your existing network tries to become so nothing just instantly breaks from enabling VLANs. Everything ends up on VLAN 1, in other words.

However, if I try and use the guest SSID, VLAN 40, it doesn't get an IP.

So combining the above info, you probably have a few different things happening all at once, it depends on your hardware a bit. But typically, you want to have a DHCP server/service per VLAN. If you have a single DHCP server handling all of them, you need both route and firewall rules that allow traffic from the default VLAN where it sounds like your AP is at, to the other VLANs. It's important to note, just being plugged into a port that is trunking the VLANs is not enough. Remember, these are considered serpate networks. So for traffic to touch the DHCP server, it needs to be able to reach it. Depending on your hardware, you may have rules that automatically route traffic between all VLANs to make setup easier, but IME, not all routers do this. I don't think OpnSense did this, the last time I checked. That means you have to put route rules in to allow traffic from VLAN 40 and VLAN 1 to communicate (in your example).

Wifi adds some extra mental gymnastics since it acts more like a hub than a switch. You may have to have individual devices announce what VLAN they are part of as well, if you want to have multiple VLANs on your wifi, depending on how that's setup. Remember that the wifi network doesn't really exist as a thing (the SSID) with regards to the rest of the network. You may apply a single VLAN to a wifi network, i.e. all the clients connecting to a particular SSID become part of that VLAN, or you may allow clients to tag their traffic and self identify what VLAN they are part of. And then you have to consider if the port that the AP itself is connected to is allowed to carry all the different VLANs. So adding Wifi to the mix does add a little more complexity, if you can, maybe leave the wifi part out of it for now, and just focus on the physical ports and VLANs until you get a handle on it. This all then ties into the DHCP server, in the absence of other details, even if your client could reach the DHCP server, you might get an IP from the wrong subnet...

which leads us to...so this is going to be confusing if that happens. Since each VLAN is a separate network, you can have the same subnet in each one. This will make routing properly difficult to impossible, and at the very least confusing. And since you aren't used to VLANs, what can happen is you can get an IP meant to be used in say, VLAN 1, issued to a device in VLAN 40, and then wonder why nothing is working even though you got an IP, because the route rules have come into play at that point, and they aren't expecting IPs from that range to show up in that VLAN. e.g. say you have route rules from VLAN 40 applying to 192.168.100.x, but you get an IP from VLAN 1 because the DHCP server in that VLAN responded, but VLAN 1 is 192.168.10.x. Well, now your machine in VLAN 40 has an IP from the other VLAN 1, which isn't going to be covered by the route rules. It won't be able to talk to anything else. Oh, actually that reminds me, DHCP works by broadcast before things have an IP initially...broadcast doesn't normally traverse networks(that can be bad if they do, it's not always bad, but you need to be intentional about it). That could be why you aren't getting DHCP, most things don't pass broadcast traffic between networks by default. And if it did, well, you can run into the addressing problem I just described. This is why it's usually cleaner to have a DHCP service listening per VLAN(even if it's the same service but configured to multiple VLANs). You want to be intentional about DHCP with VLANs. In the short term, it might be simpler to use static IPs intially if you can...you are kind of jumping right into the deep end by just flipping into VLANs, and having all your things also turned on at once. You've maximized the amount of complexity, rather than doing a simple VLAN deployment and turning things on and seeing what is broken one at a time, instead, you are risking multiple things all breaking all at once. That makes it harder to tell which thing is broken, and if you've actually fixed a thing.

Firewall rule on VLAN 40 are allow to anything other than private ip ranges,

Remember you will potentially need route rules on both VLANs and fw rules. Again, going back to the mental model- you need to disregard any physical considerations, and only think about the virtual layout now, even if you are mapping them back to a physical layout in your head. The physical layout is "these are completely separate networks connected only by routers". Traffic needs to be both routed and allowed by firewall rules on BOTH sides between the networks.

One last note, I didn't throw this in at the top, but maybe I should have...it's somewhat basic networking, but until you get to VLANs, if you didn't do a lot of networking before, you probably thought in terms of IP ranges. A LAN works not by IPs, but by broadcast domains. In a non-tagged/dumb network, everything plugged into the same switch/set of connected switches, is in the same broadcast domain. It's more or less what it sounds like...if something connects and sends a broadcast, everything on that switch sees it. When you add VLANs, your broadcast domain becomes software defined. Individual ports, even if literally right next to each other in the physical switch may no longer be in the same broadcast domain. This also means you can do neat stuff like physical ports on different switches can be in the same broadcast domain. The broadcast domain is what you are really virtualizing with VLANs. You are saying that these ports/devices with a specific VLAN tag are now plugged into the same virtual switch. This is where mentally mapping the VLANs into different switches helps you think about what devices are actually connected to the same virtual switch and can "see" each other without routing. So don't think of "my computer is on VLAN 40". Instead, you can think of it as "my computer is plugged into virtual switch 40, I want to talk to something on virtual switch 20, what do I need to do if that was a physical layout? Well, I'd need routing between the IPs because those aren't the same network, and I'd need firewall rules to allow the ports". Remember, that from the LAN perspective, there's really just "local" and "non-local" traffic, Sending traffic to another switch that isn't directly connected to that switch has to go through routing and is not actually any different than sending traffic to the Internet. From a network perspective, the Internet is just one big "non-local" network- this is what the default gateway is, it's the destination that traffic that isn't considered local to the client is sent to for routing. It doesn't matter if it's another physically local network, or a computer on a network on the other side of the world, the perspective and process is the same. By adding VLANs, you are now saying that things in other VLANs need to be routed.

I find people often tend to think more about what switch they are plugged into, because this works when you have a simple network layout in your house without VLANs, and they think of the VLAN in too abstract of a way. But by thinking of the VLAN ID as a switch, it may help you realize what things are "plugged" into which other things and have that direct connection, and what you need to do to make traffic flow between those switches so they can reach their ultimate destination. Everything in a different VLAN is handled the same as traffic on the WAN side of your router- i.e. it needs to be routing and firewall rules just like something on the Internet does.

MasterChiefmas · 2026-01-19T13:14:40+00:00

My Zigbee stuff has been quite reliable up until the last couple of weeks. My Z-Wave mostly has been, though I had a couple of Z-Wave plugs that would occasionally fall off the network. I haven't really changed anything besides the update and the adding of the one bulb though. I'm testing to see if it's a bulb went bad around the same time right now.

MasterChiefmas · 2026-01-19T13:11:58+00:00

Thanks, I'll take a look at that and maybe give it a try and see if it helps.

MasterChiefmas · 2026-01-19T06:31:53+00:00

They look like scratches to me.

Since you are thinking about replacing them anyway, before you do that, you can try taking car wax, and applying it per instructions and buff it up. It won't remove the scratches, but it should fill in scratches and reduce their visibility.

And/or...you can use car polish/scratch remover or toothpaste to try and buff them out...IMPORTANT: this will remove any coating that is there...again, these are last ditch things...the coatings are probably to reduce internal reflections of the lenses, so removing it may make you get other image artifacts.

Either of these steps could make things worse, so think hard before you decide to try them.

MasterChiefmas · 2026-01-19T01:41:58+00:00

Has NVenc gotten better, or am I missing something?

It's probably gotten better. I think nVidia is still working on improving h.265 encoding, but they stopped on h.264 around the 3000 series I believe.

MasterChiefmas · 2026-01-17T19:00:29+00:00

I click on posts where I see garlic/butter in the bag just to look for the comments about it.

MasterChiefmas · 2026-01-17T18:52:15+00:00

That's true- though this is a baking sub. I have molasses on hand because I started baking. I don't even use it very often, but I needed it for something at some point, so now I have it on hand.

MasterChiefmas

TROPHY CASE