Epson 1080UB: Lamp swap

Way, way back in 2008 I purchased the Epson 1080UB. While I wasn’t new to having a home theater setup, this was my first step into digital projectors. I run the projector in ‘low brightness mode’ as I’ve got a dedicated room that has complete light control. This lets me extend the lifetime of the lamp, as per the manual you should get 3000 hours.

Lamp life: 2500 hours (in high brightness mode, for select color modes) to 3000 hours (in low brightness mode, for select color modes), depending on usage

Around the 3000 hour mark, the 1080UB will start to show you a warning on screen shortly after you power it on. This warning thankfully goes away after a short time, but it returns every power on.

I’ve been living with the warning for some time (apparently years). As I understand it, the light output will drop over time. While human vision is quite adaptable, eventually you’ll get to a point where it’s obviously too dim. Honestly, this didn’t happen for me – my original bulb was still going strong. Still, this same one had been running since 2008, more than 15 years. It had also seriously exceeded the expected lifetime.

During the Black Friday sales, I grabbed a deal on a new lamp. The Araca lamp for the Epson 1080UB wasn’t the cheapest option, but it had good reviews and it was one of the options I’d been watching for a while.

6036 hours over 15 years is 251 days of display time. That’s an average of 16 days of viewing time every year. If I had exclusively watched movies that would be more than 2400. It is an impressive number no matter how you slice it up. While I’ve occasionally had the upgrade bug, there hasn’t been a good reason to retire the Epson 1080UB.

The new lamp arrived well boxed. It included a white cotton glove for handling it to help avoid transferring any oils from your skin to the lamp – any contaminants can cause early failure. The Epson 1080UB manual cover the replacement process (page 50). There was also a disposable Phillips screwdriver included, but I didn’t use it as it was terrible.

I took my projector down from the ceiling mount. Did a careful dusting, and cleaned out the filter. I then put on some nitrile gloves, then put on the (one) cotton glove on my dominant hand to handle the lamp.

Removing the lamp is straight-forward but after loosening the two screws I found the lamp was still fairly tightly connected to the projector. After a little fiddling around I discovered that it does take a pretty firm tug to lift the lamp out as it is seated in a power socket under the lamp.

I’ve indicated the approximate location circled in red. Make sure the screws are fully loosened, then it should come out with a firm pull straight up. It did take a few tries, and more force than I anticipated. Once it unseats from the connector, it will lift out easily.

There was a tiny bit of dust in the lamp compartment that I wiped out with a dry dusting cloth. Installing the new lamp was uneventful. It required a firm push to fully seat. The new lamp fit perfectly.

After re-installing the projector, the new lamp started up without any drama. This new lamp may take a slightly bit longer to warm up than the original. The first thing I did was to reset the hour counter on the 1080UB as per the manual.

For the first hour or two there was a strong ‘new electronics’ smell, I left it running to let that clear out and to ‘burn’ the new lamp in. During this time I made sure the projector was well aligned, and focused on my screen. I left it running while we had dinner to let the smell work itself out. After dinner I turned it off and let it cool down for an hour or so.

Later, we all sat down to watch a movie. Again the power on warm up phase feels a bit slower to me than the original. I do think the overall light output is a bit brighter once it has reached operating temperature, but it is hard to say. The viewing experience isn’t that different. The smell is either very faint, or gone completely at this point. I’ve kept the original as a backup in case this one fails.

 

 

Expanding a docker macvlan network

I’ve previously written about using macvlan networks with docker, this has proved to be a great way to make containers more like lightweight VMs as you can assign a unique IP on your network to them. Unfortunately when I did this I only allocated 4 IPs to the network, and 1 of those is used to provide a communication path from the host to the macvlan network.

Here is how I’ve used up those 4 IPs:

  1. wireguard – allows clients on wireguard to see other docker services on the host
  2. mqtt broker – used to bridge between my IoT network and the lan network without exposing all of my lan to the IoT network
  3. nginx – a local only webserver, useful for fronting Home Assistant and other web based apps I use
  4. shim – IP allocated to supporting routing from the host to the macvlan network.

If I had known how useful giving a container a unique IP on the network was, I would have allocated more up front. Unfortunately you can’t easily grow a docker network, you need to delete and recreate it.

As an overview here is what we need to do.

  • Stop any docker container that is attached to the macvlan network
  • Undo the shim routing
  • Delete the docker network
  • Recreate the docker network (expanded)
  • Redo the shim routing
  • Recreate the existing containers

This ends up not being too hard, and the only slightly non-obvious step is undoing the shim routing, which is the reverse of the setup.

The remainder of this post is a walk through of setting up a 4 IP network, then tearing it down and setting up a larger 8 IP network.

Continue reading “Expanding a docker macvlan network”

Docker system prune – not always what you expect

Containers have improved my ‘home lab’ significantly. I’ve run a server at home (exposed to the internet) for many years. Linux has made this both easy to do, and fairly secure.

However, in the old – “I’ll just install these packages on my linux box” – model, you’d end up with package A needing some dependency and package B needing the same one, then you’d have version conflicts. It was always something you could resolve, but with enough software you’d have a mess of dependencies to figure out.

Containers solves this by giving you a lightweight ‘virtualization’ isolating each of your packages from each other AND it also is a very convenient distribution mechanism. This allows you to easily get a complete functional application with all of it’s dependencies in a single bundle. I’ll point at linuxserver.io as a great place to get curated images from. Also, consider having an update policy to help you keep current, something like DUIN, or fully automate with watchtower.

Watchtower does have the ability to do some cleanup for you, but I’m not using watchtower (yet). I have included some image clean up into my makefiles because I was trying to fight filesystem bloat due to updates. While I don’t want to prematurely delete anything, I also don’t want a lot of old cruft using up my disk space.

I recently became aware of the large number of docker volumes on my system. I didn’t count, but it was well over 50 (the list filled my terminal window). This seemed odd, some of them had a creation date of 2019.

Let’s just remove them docker volume prune – yup, remove all volumes not used by at least one container. Hmm, no – I still have so many. Let’s investigate further.

What? If I sub in a volume id that I know is attached to a container, I do get the container shown to me. This feels like both docker system prune and docker volume prune are broken.

Thankfully the internet is helpful if you know what to search for. Stackoverflow helped me out. It in turn pointed me at a github issue. Here is what I understand from those.

Docker has both anonymous and named volumes. Unfortunately, many people were naming volumes and treating them like permanent objects. Running docker system prune was removing these named volumes if there wasn’t a container associated with it. Losing data sucks, so docker has changed to not remove named volumes as part of a prune operation.

In my case, I had some container images which had mount points that I wasn’t specifying as part of my setup. An example is a /var/log mount – so when I create the container, docker is creating a volume on my behalf – and it’s a named volume. When I recreate that image, I’m getting a new volume and ‘leaking’ a named volume which is no longer attached to a container. This explains why I had 50+ volumes hanging out.

You can easily fix this

Yup, now I have very few docker volumes on my system – the remaining ones are associated with either a running or a stopped container.