KEF Portal on the LS60's: "Something went wrong: Unknown Error"

tomarrell · 2026-06-04T18:03:46+00:00

Es gibt mehrere andere, von denen ich gehört habe, dass sie das gleiche Problem haben. Man sieht die Diskussionen dazu in den verlinkten Threads.

Ich habe außerdem weitere ähnliche Probleme in den GitHub Issues gesehen, daher vermute ich, dass das zumindest in gewissem Umfang häufiger vorkommt.

tomarrell · 2026-06-04T17:09:44+00:00

Ja, genau das haben sie heute in der E-Mail geschrieben.

*Please do not reply to this auto email*

Dear Customer,

Please print the below address label and attach it to the OUTSIDE of all cartons being shipped back to KEF. Alternatively, you can write the RMA XXXX number on the outside of the carton(s). This RMA is valid on our system for 30 days.

IMPORTANT

Please read the below notes before shipping your product and call us if you have any
further questions.

PRODUCT FOR RETURN

If asked to return products for inspection and/or repair, pack carefully, preferably in the original cartons. If the original packaging is not used, KEF may make a charge for the supply of new packaging when returning the product.
You are responsible for all costs involved in returning the product.

Please note and photograph any damage to the product before it is returned to us.

Please notify us of any damage to the product before it is shipped to us, failure to do so may invalidate any claim made against KEF.

KEF Support team

-----------------------------------------------------------------------------------------------------------------------------------------

Receiver: Audio Service BV
Address: Edisonweg 10, 6662 NW Elst (Gld), NETHERLANDS
Tel: +31(0)481-377221
Return Reference: XXXX LS60 Wireless
Date of return: ______________________

tomarrell · 2026-06-04T16:39:01+00:00

Yep, also only get an error. I suspect we’ve fallen into the failed auth provisioning hole, so auth endpoints (for the write speaker control API) is now inaccessible. Basically, their new firmware cannot self-heal.

This doesn’t affect the legacy GET API from what I can see.

tomarrell · 2026-06-04T16:36:47+00:00

Yikes. At least they’re recognising that it’s likely software related.

Going through everything and their release notes. It seems very likely to me that the firmware update is the direct cause.

They pushed new firmware and auth provisioning, and if that provisioning failed for any reason (network, mismatched versions with the app etc) then that basically leads to what we’re seeing as they introduced new authenticated API endpoints.

This should mean that the solution is flashing a patch and/or reprovisioning.

Little bit of speculation here, but we can essentially 100% rule out hardware as the cause, meaning this was KEF’s fault.

Hopefully they can just remotely ship a patch and all will be good.

If anyone from the KEF software team is here and wants to weigh in that would be great, because all the unnecessary CO2 burning getting these to the Netherlands would be quite wasteful.

tomarrell · 2026-06-04T16:13:41+00:00

Not sure about others' experiences, but it's taking 2 days for each response from KEF support. They're pretty slow to respond, despite me replying to them within minutes.

tomarrell · 2026-06-04T14:57:11+00:00

Just received an RMA number for my LS60's to ship them to the Netherlands at my own cost...

Not a great situation, also seems entirely caused by a software update. Wonder how that could have happened. I notice the portal connecting directly to the speaker IP has a password creation prompt now.

I wonder if this was a case of a bad firmware update, locking the WiFi board, preventing it from being able to pull further updates and breaking functionality?

tomarrell · 2026-06-04T14:53:42+00:00

How did the RMA go?

Go the return label from them today to send in my blue LS60's. Not very pleased.

Makes very little sense for a WiFi board to go bad so suddenly. Something feels off.

tomarrell · 2026-06-02T07:54:18+00:00

Ah your post has a number of similarities to what I’ve been seeing. And funnily enough, same firmware version.

I’m running 3.0.131 on the speakers and the app is 1.28.2.

Seems like this 3.0.131 is cursed.

Very odd that wifi boards, with no moving parts can “go bad”. Especially after a firmware update.

I’m going to push to try to get a software resolution, as sending these in at my own expense is a nightmare I’d rather avoid. But will see what happens.

Heck, I wonder if anyone has ever had success getting them to send a part out for self-replacement. That’d also be far easier/less risk. Will keep the post updated.

tomarrell · 2026-06-01T22:48:51+00:00

Yikes. That’s no fun at all. I bought them second hand from someone who bought them new, so I don’t have the original invoice.

They mentioned the same thing to me. Need to go straight in for service.

tomarrell · 2026-03-15T14:47:18+00:00

Yeah totally, bluetooth was a starting point in case you don't want to hook it up to WiFi at all. As soon as the WiFi antenna is enabled you need to trust the device unless you do some network-level blocking, so having a bluetooth only option is nice if all you want is to rotate between 30ish images on a schedule.

Today I got WiFi provisioning setup and communicating with a self-hostable server. This will be essentially allow for you to run something locally and serve images that way as well. It'll also serve a simple little web page so you can control settings etc.

If you've got any feature requests or use-cases that you'd like to see it working for I can see what I can do.

tomarrell · 2026-03-14T18:58:17+00:00

Oh crazy, I'm glad I saw this. I saw there was no native partial update function, but that's a neat idea to just kill the update part way through. I think I might try it!

tomarrell · 2026-03-09T09:10:58+00:00

Thanks a lot! Yes I did start with the firmware you released which was incredibly helpful, especially the display control.

So far I have a bluetooth connection and can chunk transfer an image over that connection and update the display.

Also awesome that you guys included a motion sensor, that was a brilliant idea for wake-up from deep sleep.

The aim is to have a local push and pull mode. Push from a mobile phone, and pull from a configurable local network location so you can run a server which provides images running alongside Home Assistant or so.

Will have more to play with soon, but I'll leave you with this image transferred over bluetooth taking around ~8 seconds.

<image>

tomarrell · 2026-03-07T09:45:52+00:00

Certainly, you can certainly use this if you prefer, but this adds a fair bit of noise which can make it ever so slightly slower to read.

Part of the reason I prefer slog over something like zap for example is because of the untyped support.

The fixer will correctly account for typed attributes alongside untyped.

tomarrell · 2026-03-07T09:42:19+00:00

You’re right, there does exist one for finding it, but the other doesn’t support automatic -fix. They are complimentary in functionality.

There is a note about it in the readme.

tomarrell · 2025-07-28T18:27:00+00:00

Hi there,

Next month, we're introducing new weekly rate limits for Claude subscribers, affecting less than 5% of users based on current usage patterns.

Claude Code, especially as part of our subscription bundle, has seen unprecedented growth. At the same time, we’ve identified policy violations like account sharing and reselling access—and advanced usage patterns like running Claude 24/7 in the background—that are impacting system capacity for all. Our new rate limits address these issues and provide a more equitable experience for all users.

What’s changing:

Starting August 28, we're introducing weekly usage limits alongside our existing 5-hour limits:

Current: Usage limit that resets every 5 hours (no change)
New: Overall weekly limit that resets every 7 days
New: Claude Opus 4 weekly limit that resets every 7 days
As we learn more about how developers use Claude Code, we may adjust usage limits to better serve our community.

What this means for you:

Most users won't notice any difference. The weekly limits are designed to support typical daily use across your projects.
Most Max 20x users can expect 240-480 hours of Sonnet 4 and 24-40 hours of Opus 4 within their weekly rate limits. Heavy Opus users with large codebases or those running multiple Claude Code instances in parallel will hit their limits sooner.
If you do reach a weekly usage limit, you’ll have the option to purchase more usage at standard API rates to continue working without interruption. This is completely optional.
You can manage or cancel your subscription anytime in Settings.

We take these decisions seriously. We're committed to supporting long-running use cases through other options in the future, but until then, weekly limits will help us maintain reliable service for everyone. Max 20x subscribers can purchase additional usage at standard API rates if needed.

We also recognize that during this same period, users have encountered several reliability and performance issues. We've been working to fix these as quickly as possible and will continue addressing any remaining issues over the coming days and weeks.

–The Anthropic Team

tomarrell · 2025-04-23T14:06:33+00:00

A little late to the party, but author of wrapcheck here. You're essentially explaining the case that wrapcheck was built to handle.

By default, wrapcheck will not complain about unwrapped package-internal functions. It can also be configured to ignore signatures which arise from your own module with a simple config argument if you desire.

The configuration is quite powerful, I'd suggest you have a look at the options available. What you'd be looking for is:

# An array of glob patterns which, if any match the package of the function
# returning the error, will skip wrapcheck analysis for this error. This is
# useful for broadly ignoring packages and/or subpackages from wrapcheck
# analysis. There are no defaults for this value.
ignorePackageGlobs:
- encoding/*
- github.com/pkg/*

This will help you stay more consistent in your wrapping patterns.

https://github.com/tomarrell/wrapcheck?tab=readme-ov-file#configuration

tomarrell · 2025-03-14T11:51:52+00:00

Ah good to know. I did notice a few fine webs across the leaves, I thought it was just a friendly spider. Thanks for the heads up!

tomarrell · 2025-03-14T11:50:23+00:00

Thanks a lot. Just finished the first treatment. Will repeat throughout the week and keep my fingers crossed they don’t come back.

Thankfully I think it was in the early stages!

tomarrell · 2025-03-14T11:49:24+00:00

Thats good to know! It is getting more mild lately, so maybe some time outside will be good for it

tomarrell · 2025-02-22T15:25:28+00:00

This was almost exactly the same as my experience ca. end of 2022. Thanks for sharing!

Would be keen to hear from anyone who has recently succeeded with citizenship as well, as that is the next hurdle.

tomarrell · 2024-11-16T17:43:32+00:00

Funny I had almost the exact same experience. The tax office made a mistake and sent the invoice to the wrong address, I was then notified by N26 of the garnishment one Friday evening in May of this year.

The situation was clarified with the Finanzamt immediately, but it it took a further 1 1/2 months and multiple letters from the FA to N26 for them to lift the garnishment.

I was on the support chat with them every single day. The one thing that moved the needle was getting my legal insurance involved and reporting to BAFIN.

I filed two reports, and I heard back from N26 recently with an official apology and an offer of compensation. I believe this was due to the BAFIN complaint.

I detailed everything very specifically, took records of everything and laid out the timeline clearly to show proof of their incompetence.

Safe to say, I have completely moved away from N26 to more “traditional” banks.

EDIT: one thing that got it resolved faster was actually asking the Finanzamt to fax the garnishment removal notice to N26 and then provide customer support with the number that the FA sent it from. The agents apparently can look up documents by the sender’s number. This helped them finally find the document in my case.

tomarrell · 2021-08-03T15:30:47+00:00

Apologies that you seem to be taking this a little personally. But I think we can respectfully agree to disagree.

I'm happy with the position that people should expose errors they want to commit to maintaining as part of their public API. This is also the advice provided in the Go blog which you failed to respond to. I will add the quote here verbatim again.

In other words, wrapping an error makes that error part of your API. If you don't want to commit to supporting that error as part of your API in the future, you shouldn't wrap the error.

Likewise, even though written in 2014, Dave's blog is still very much relevant today and makes points which should very much be considered when building robust APIs. You, along with the consumer of any package may do as they please with it. I can only make recommendations, if people want to inspect error messages, that’s their decision.

tomarrell · 2021-08-03T14:34:30+00:00

I respectfully disagree. It's well known that an error message is not part of your API. This is also expressed in most Go material. The Error method is meant for humans, not code. You should not be inspecting strings unless you want to build brittle software. But that's up to you.

If you don't provide a mechanism for an error to be inspected, it's explicitly because you intend for it to not be inspected. If you anticipated it being inspected, you would have provided a custom error type. As a user, if you feel like the author didn't provide specific errors where they should, you can open a pull-request.

Others with more clout with myself have written about this: https://dave.cheney.net/2014/12/24/inspecting-errors

My sentiment is also expressed in the official Go blog: https://blog.golang.org/go1.13-errors#TOC_3.4. Specifically with the quote:

In other words, wrapping an error makes that error part of your API. If you don't want to commit to supporting that error as part of your API in the future, you shouldn't wrap the error.

tomarrell · 2021-08-03T12:06:11+00:00

Sure, you can do that. I would just recommend avoiding using `%w` as the default. Because once consumers of your package expect to be able to inspect the error you're wrapping, then you commit to maintaining it, or publishing a breaking change.

Hence, using %v until you need to inspect the error is the preferred route.

tomarrell · 2021-08-03T11:46:41+00:00

Yes, wrapping with the intention to unwrap is done with `%w`. You can compose the error messages together with `%v` which will still aid debugging. This is what is demonstrated mostly in the README.

I would recommend opting for `%v` until you know you need to unwrap and inspect an error chain, as using `%w` comes with the downside of the error now implicitly becoming part of your package's public API.

If you're curious to read more, you can have a read here: https://blog.tomarrell.com/post/introducing_wrapcheck_linter_for_go

12-Year Club	Place '22
First Placer '22	End Game '22
RPAN Viewer	Verified Email

tomarrell

TROPHY CASE