u/111izanagi

Hi guys,

I'm having a really stubborn issue with an IKEA NYMÅNE Smart LED pendant (38 cm, anthracite, article 905.040.44) that I can't get into factory reset/pairing mode. I've tried pretty much every timing I can think of, but the lamp just turns on normally every time.

The lamp is a 2023 unit (batch 2333), rated at 220–240V, 50–60Hz, 22W. It uses Zigbee 3.0/Tradfri, and the Zigbee electronics and AC-DC driver are inside the metal lamp itself. The ceiling cup is basically just the mounting bracket and the L/N terminal block.

My setup is Zigbee2MQTT with a Sonoff Zigbee 3.0 USB Dongle Plus (EFR32MG24, EmberZNet 8.0.2), on channel 15 at 18 dBm. The Zigbee network itself is working fine. I already have two IKEA PILSKOTT pendant lamps, an IKEA STYRBAR remote and a Sonoff ZBM5 switch on the network.

The interesting part is that the NYMÅNE is wired in parallel with the two PILSKOTT lamps in router mode on the exact same wall switch circuit.

When I turn the switch on, the NYMÅNE immediately comes on at 100% brightness, with both the warm and cool LEDs on. It never flashes, pulses or dims, and I don't see it attempting to join or announce itself when permit_join is enabled in Zigbee2MQTT. It basically behaves as if it's either still paired to some old network or simply isn't recognising the reset sequence.

I've tried the usual 6-toggle reset several times, with different timings: roughly 0.5s on/0.5s off, 1s on/1s off, and even around 1.5s on/3s off to give the internal capacitors plenty of time to discharge. Nothing works. The lamp just comes back on normally. Interestingly, the two PILSKOTT lamps on the same circuit also didn't reset during these tests.

I also tried Touchlink from Zigbee2MQTT, but the scan/reset attempts timed out. I tried using the STYRBAR remote directly next to the lamp (2–5 cm away) and held the pairing button for more than 10 seconds, but the NYMÅNE didn't react at all. The STYRBAR is already joined to Zigbee2MQTT, so I assume its standalone Touchlink functionality is disabled anyway.

I've also opened the lamp up and checked the wiring. The 230V connection is solid at the ceiling terminal and at the connector on the LED plate. I couldn't find any obvious physical reset button, pinhole or similar.

So I'm wondering if anyone here has dealt specifically with this NYMÅNE model.

A few things I'm particularly curious about:

• Does the 6-toggle reset on this particular 22W NYMÅNE require a very specific timing? If you've successfully reset one, what timing did you use?
• Could having the three drivers (2x PILSKOTT + NYMÅNE) on the same switch be interfering with the reset because the voltage isn't dropping quickly enough? Would it be worth disconnecting the other two and testing the NYMÅNE completely on its own?
• Has anyone found a hidden reset button, pinhole, test pad or jumper inside the NYMÅNE, perhaps underneath/behind the 10078006 LED plate?
• Would something like a Philips Hue Dimmer or another dedicated Touchlink device actually be able to reset it through the metal shade?
• Is there another IKEA-specific reset procedure for this model that isn't the usual 6 power cycles?

At this point I'm mainly trying to figure out whether I'm missing something obvious or whether this particular unit might actually have a hardware/firmware issue.

Any advice from someone who's successfully reset one of these would be really appreciated. Thanks!

Edit: This is the European version bought in Portugal, in case there are any regional differences in the hardware, firmware or reset procedure.

TL;DR: NYMÅNE 38 cm (905.040.44) won't enter reset/pairing mode despite trying multiple 6-toggle timings, Touchlink and a STYRBAR. It's the European/Portuguese version.

Hi guys, noob with private trackers here.

I've been trying to fix a couple of issues with my *arr setup for the past few days and I'm starting to run out of ideas.

My setup is pretty straightforward: Overseerr/Jellyseerr sends requests to Sonarr and Radarr, which use Prowlarr for indexers. I use qBittorrent for public trackers and Deluge exclusively for private trackers. To keep everything separated, I created a tag and applied it to the privats indexer in Prowlarr, the matching indexers and download client in Sonarr/Radarr, and Deluge itself so that anything from private trackers is always sent there.

The first issue is that private trackers seems to work perfectly inside Prowlarr. If I search for a movie or TV show directly there, I get the expected results without any problems.

The strange part is that those same results never appear when I perform an Interactive Search in Sonarr or Radarr. I get no results at all from privates.

I've already removed old tags like flaresolverr in case they were interfering, confirmed that Interactive Search synchronization is enabled in the Prowlarr app settings, and verified that both the default categories (2000 and 5000) and the possible specific categories (1000xx) are configured. Since the searches work perfectly in Prowlarr itself, I'm wondering if Sonarr or Radarr is filtering those releases for some reason that I'm missing.

The second issue is with Deluge. Downloading from private trackers works exactly as expected, so I know the client is connecting and receiving data correctly.

The problem starts once the download finishes. The torrents stay at 0 KiB/s upload and never seem to seed when they are seeding, which is obviously becoming a problem for maintaining ratio on private trackers.

What's confusing is that qBittorrent has no issues seeding torrents from public trackers, so I'm not sure if this points to a Deluge configuration issue, connectability, or maybe something specific to how private trackers interact with Deluge.

If anyone has experienced either of these problems before, I'd really appreciate some guidance. Is there a particular log, setting, or common misconfiguration that I should be checking?

Thanks

Boas,

Qual acham que seria o valor de uma XFX Radeon RX 6600 Speedster SWFT 210 8GB?

A cex oferece 121 em dinheiro ou 149 euros em Voucher, não sei se no mercado de usados iria conseguir mais que isto ou se existe a procura para tal.

Hi guys,

I'm trying to solve something that I thought would be more common, but I haven't found a good solution yet.

I have several animated movies with the original European Portuguese (PT-PT) dub. Unfortunately, these releases are older and the video quality isn't great (DVD or lower-quality encodes).

I'd like to use a high-quality Blu-ray release and replace its audio with the PT-PT dub from my older copy.

The problem is that the audio doesn't line up perfectly. There are usually small differences in timing, different studio logos, slightly different cuts, frame rate changes, or other edits, so simply muxing the audio isn't enough. I've been looking for a tool that could automatically or semi-automatically synchronize the audio tracks. It doesn't necessarily have to use AI, but I'm wondering if there's anything that can do it in a easy way ?

Hi everyone,

With the release of Immich v3.0.0, I'm preparing to upgrade my instance, but I have a few doubts regarding the backend dependencies since I manage my updates manually via CasaOS.

Currently, my stack is running smoothly on:

• Immich Server & Machine Learning: v2.7.5 (CUDA)
• Postgres: 14-vectorchord0.3.0-pgvectors0.2.0
• Redis: 6.2.20-alpine

Regarding the breaking changes warning about dropping pgvecto.rs support, I noticed my current Postgres image tag already contains vectorchord.

My questions are:

1. Postgres: Since I am on a major version 14 (14-vectorchord...), can I safely upgrade the tag to 14-vectorchord0.5.3-pgvector0.8.1 directly in my Docker UI before making the jump to Immich v3.0.0? Or should I just let the v3 server upgrade happen first? (I want to avoid a major Postgres 14 to 16 migration failure for now if possible).
2. Redis: My Redis is quite old (6.2.20). Is it recommended to bump it straight to redis:8.0-alpine along with the v3.0.0 upgrade? Will it cause any issues with existing jobs or queues during the transition?

I always keep backups of my DB, but I'd love to hear the safest order of operations from anyone who has already done this manual jump.

Thanks!

Hi everyone,

I'm running a small home server/NAS with CasaOS on top of Ubuntu Server 24.04 LTS on an old laptop. Unfortunately, the RAM is soldered, so upgrading isn't an option.

The machine has an Intel Core i5-8250U (4C/8T), 8GB of DDR4 RAM, MX150 and a 256GB NVMe SSD for the OS and Docker configs, plus two 2TB external HDDs for media storage.

I run several Docker containers through CasaOS and recently noticed that the system was using swap quite heavily. The default 4GB swapfile was almost full, with around 3.7GB in use, while free was still reporting roughly 3.5GB of available RAM. That seemed a bit odd to me, and I was also concerned about unnecessary wear on the NVMe SSD.

To see if things would improve, I replaced the old swapfile with an 8GB one and lowered vm.swappiness from Ubuntu's default value of 60 to 10.

Since making those changes, the server feels noticeably more responsive. RAM usage now sits around 7.3GB most of the time (roughly 90–95% utilization), while swap usage has dropped to around 280MB. My assumption is that more of the containers are staying in physical RAM instead of having parts of their memory swapped out.

The only thing that still makes me a bit uneasy is seeing RAM usage constantly above 90%. The server definitely feels faster, but I'm wondering whether lowering swappiness to 10 is actually the right approach for a small 8GB machine running 24/7, or if Ubuntu's default of 60 would be a safer choice in the long run.

I'm also curious about the risk of the OOM killer. With an 8GB swapfile now available, is there still a realistic chance of containers getting killed if a few of them suddenly spike their memory usage, or does the extra swap provide enough breathing room?

How you guys running lower-memory self-hosted setups handle swap and swappiness, and whether you've found a sweet spot that works well in practice?

Thanks in advance!

Hi everyone,

I'm running a small home server/NAS with CasaOS on top of Ubuntu Server 24.04 LTS on an old laptop. Unfortunately, the RAM is soldered, so upgrading isn't an option.

The machine has an Intel Core i5-8250U (4C/8T), 8GB of DDR4 RAM, MX150 and a 256GB NVMe SSD for the OS and Docker configs, plus two 2TB external HDDs for media storage.

I run several Docker containers through CasaOS and recently noticed that the system was using swap quite heavily. The default 4GB swapfile was almost full, with around 3.7GB in use, while free was still reporting roughly 3.5GB of available RAM. That seemed a bit odd to me, and I was also concerned about unnecessary wear on the NVMe SSD.

To see if things would improve, I replaced the old swapfile with an 8GB one and lowered vm.swappiness from Ubuntu's default value of 60 to 10.

Since making those changes, the server feels noticeably more responsive. RAM usage now sits around 7.3GB most of the time (roughly 90–95% utilization), while swap usage has dropped to around 280MB. My assumption is that more of the containers are staying in physical RAM instead of having parts of their memory swapped out.

The only thing that still makes me a bit uneasy is seeing RAM usage constantly above 90%. The server definitely feels faster, but I'm wondering whether lowering swappiness to 10 is actually the right approach for a small 8GB machine running 24/7, or if Ubuntu's default of 60 would be a safer choice in the long run.

I'm also curious about the risk of the OOM killer. With an 8GB swapfile now available, is there still a realistic chance of containers getting killed if a few of them suddenly spike their memory usage, or does the extra swap provide enough breathing room?

How you guys running lower-memory self-hosted setups handle swap and swappiness, and whether you've found a sweet spot that works well in practice?

Thanks in advance!

I'm running Seer in a multi-user setup and I'd like to restrict some users so they can only request/download content using the 1080p profile.

Is there a built-in way to enforce profile restrictions per user, or would this require custom permissions or something like that?

How are you guys handling this use case?

Thank you

Hi everyone,

I’m refining my self-hosted music setup and want to move beyond simple media hosting into a fully library ecosystem. My goal is a Spotify-like UX where I can browse a massive library of metadata, but the actual audio files are only pulled/downloaded just-in-time or based on active playlists.

The Workflow I’m aiming for:

• The UI: Spotify-like experience (IOS/Linux/androidtv) connected to a Navidrome/Jellyfin backend.
• The "Hydration" Strategy: I want to keep the metadata for thousands of tracks/albums visible at all times, but only trigger the download/storage of the FLAC/MP3 files when a track is added to a specific "Active" playlist or when I hit play.
• Automated Discovery & Download: A pipeline that pulls recommendations (via ListenBrainz or Last.fm), creates a "Discovery Playlist" and triggers Lidarr + spotDL to download those tracks gradually.
• Lifecycle Management: An automated pruning script to delete any tracks that haven’t been played in >365 days to keep the storage footprint lean.

Questions:

1. Hydration Flow: Has anyone implemented a "download on-demand" bridge? I’m looking to avoid keeping 2TB of music on the server if I only listen to 10% of it.
2. Playlist-Driven Downloading: Instead of downloading whole albums, is there a tool that monitors a playlist (e.g., from a smart-link) and feeds those specific URLs to Lidarr/spotDL?
3. Pruning: Is there a robust way to automate library pruning based on last_played timestamps without breaking the database references?

Any advice on the stack to glue this together would be amazing!

Hi everyone, I'm facing a really weird issue trying to connect Bazarr to Sonarr and Radarr on my home server running CasaOS. No matter what I try, the "Test" button in the Bazarr UI always fails, giving an API call error or timeout. However, network connectivity and API keys seem to be 100% fine.

My setup is Docker-based through CasaOS, with Bazarr currently running in bridge network mode (though I tested host mode with the same result). Sonarr and Radarr are both on v4, with the Base URL completely empty on all apps, and SSL disabled in the Bazarr settings.

The mind-boggling part is what happens when I test the connection manually. Running a curl GET request from the host machine to Sonarr (http://192.168.31.169:8989/api/v3/system/status) with the X-Api-Key works perfectly and returns an HTTP 1.1 200 OK along with the system JSON. Even more surprising, if I run the exact same curl command from inside the Bazarr container using docker exec -it bazarr curl -H "X-Api-Key: MY_API_KEY" http://192.168.31.169:8989/api/v3/system/status, it also works perfectly and connects instantly. This proves the container can talk to Sonarr, the routing is fine, and the API key is correct. I also tried saving the settings without testing in the UI and forcing an "Update Sonarr list" task, but the sync task just fails.

While looking at the logs, I noticed two distinct errors that might be breaking the internal Python/Flask code before the test even reaches the network phase. First, the UI crashed at one point with a traceback showing PermissionError: [Errno 13] Permission denied: '/data/backups/' during an os.makedirs(backup_dir) call when attempting to handle settings or backups. Second, I saw startup errors stating Error trying to get announcements from jsdelivr.net, falling back to Github, followed by a failure to connect to GitHub, and the log just stalls at BAZARR trying to connect to Sonarr SignalR feed....

To troubleshoot, I have already regenerated the API keys, disabled "Certificate Validation" in Sonarr/Radarr, and even tried connecting via the Docker Gateway IP (172.17.0.1) instead of the LAN IP, but the result is exactly the same.

If the container can successfully curl the Sonarr API and get a 200 OK, why is the Bazarr application itself failing to connect or sync through the UI? Could the PermissionError on the backup directory be hard-crashing the save/test routine internally?

Any help or insight would be greatly appreciated!

APP310 Rear Drive Unit — The VW MEB Bearing Disaster
We have analyzed the APP310 in the ID.3, ID.4, and Enyaq several times. Forum users complained when we drew our conclusion after the first teardown - and once again, every subsequent unit confirms the same pattern. We are not deviating.
The latest case: motor completely seized at 214,000 km. The owner had clearly been driving with audible buzzing for a long time and ignored the sound.
Our conclusion was a design problem, not a quality problem. All bearing part numbers are unavailable in the supply chain. Of these, 4 bearings do not exist as serviceable parts at all. The motor had only 200 ml of oil left, burnt off by 180,000 km, and we are now seeing the exact same pattern repeating: the motor runs with insufficient oil, which is the primary cause of failure, and you can see black “carbon” residue coating the internals. The motor has no oil drain plug and was never designed for an oil change.
So in summary:
oil cannot be changed — it burns off — problem
bearings are not available in the supply chain — problem
the motor is repairable if you are not too late — problem
we developed our own repair kit — excellent
the motor is well-built but it leaks — problem
there is no official service interval — problem
Our recommendation: do not ignore buzzing or humming noises, and change the oil in both differentials every 100,000 km.

Affected — APP310 Rear Drive Unit
Volkswagen ID.3 (2020 – present, Pro / Pro S trims still use APP310)
Volkswagen ID.4 (2021 – Q4 2023; Pure base trim ongoing)
Volkswagen ID.5 (2022 – Q4 2023)
Volkswagen ID. Buzz (2022 – 2024, base variants)
Škoda Enyaq iV / Coupé iV (2021 – present, 50 / 60 trims still use APP310)
Škoda Elroq (2024 – present, 50 / 60 trims)
Audi Q4 e-tron / Q4 Sportback e-tron (2021 – 2024, RWD trims)
Cupra Born (2022 – present, base trims still use APP310)
OEM Part Numbers — APP310
1EA900100
1EA900100A
1EA900100B
1EA900100C
1EA900100E
1EA900100G
0CW301103
0CW301103A

Not Affected — APP550 Rear Drive Unit (redesigned)
Volkswagen ID.3 GTX (2024 – present)
Volkswagen ID.4 Pro / Pro 4Motion / GTX (Q4 2023 – present)
Volkswagen ID.5 Pro / GTX (Q4 2023 – present)
Volkswagen ID.7 / ID.7 Tourer (all variants, 2023 – present)
Volkswagen ID. Buzz 77 kWh variants (2024 – present)
Škoda Enyaq 85 / RS (2024 – present)
Škoda Elroq 85 / RS (2024 – present)
Audi Q4 e-tron AWD / Q4 Sportback e-tron AWD (2024 – present)
Cupra Born VZ (2024 – present)
Cupra Tavascan (all variants, 2024 – present)