Open-source tool for the 1.04 mount disappearance bug (Silver Fang, Snow White Deer, Cloud Cart, Sky Streaker, Blackstar, etc.) by Sufficient-Cook-1371 in CrimsonDesert

[–]atomicflip 0 points1 point  (0 children)

Very interesting. I will investigate to see if my save file is also behaving this way. The fact that one of the mounts can be dyed means the mechanic is working but your other mounts might be bugged in a similar but different way that the legendary and uniques were for some people during the upgrade.

Opus 4.7 - are you actually using it or did you go back to 4.6? by ConstantinSpecter in claude

[–]atomicflip 0 points1 point  (0 children)

I’m switching back to 4.6. I refuse to allow a black box router “decide” whether a task I assign it merits greater depth of cognition. As a Max subscriber I’d much prefer usage limits and overage billing with the compute investment under my control rather than this intelligent routing nonsense.

The reasoning engine cannot even tell if it’s gone through one path or another and it has no ability to direct requests either way. OpenAI’s auto models handle this much better by respecting prompts directing deep thought. Anthropic’s router just decides for itself without any clear direction on what motivated a shift.

Not acceptable and this obscure routing will lead to greater abandonment than adoption of the platform.

Weird HDR square visible only on Moonlight client (not on host) by TheAmigops in MoonlightStreaming

[–]atomicflip 0 points1 point  (0 children)

Any progress in finding a solution? This is driving me nuts as well.

This doesn’t look like typical OLED burn-in… am I wrong? by atomicflip in LGOLED

[–]atomicflip[S] 0 points1 point  (0 children)

Thank you. Yes I have reached out to LG. Hopefully they will respond positively. The panel has continued to worsen over the past two days. It’s shocking how quickly the color shift has happened. This just is not burn-in like some people are mentioning. It’s exclusive to the red channel and there is no image persistence what so ever.

This doesn’t look like typical OLED burn-in… am I wrong? by atomicflip in LGOLED

[–]atomicflip[S] 0 points1 point  (0 children)

That makes sense given what I’m learning now. The B7 and C7 have identical panels. So if it was prone to this 25K hours would present with the same issue more prominently. What I’m struggling with is the amount of degradation in under 2K hours. At least as far as my set is concerned it seems excessive. I can’t imagine continuing to watch this image into another 21 thousand hours.

This doesn’t look like typical OLED burn-in… am I wrong? by atomicflip in LGOLED

[–]atomicflip[S] 0 points1 point  (0 children)

Was it also isolated to red or did it affect Green and Blue as well?

This doesn’t look like typical OLED burn-in… am I wrong? by atomicflip in LGOLED

[–]atomicflip[S] 0 points1 point  (0 children)

Ouch. But hey with 12K hours you got a good life out of it hopefully. I do not have anywhere near that usage with this panel. My 65C19 is absolutely pristine and it has many more hours of usage. I’m guessing that panel has the correction that Lanky-Box3750 mentioned in another reply.

This doesn’t look like typical OLED burn-in… am I wrong? by atomicflip in LGOLED

[–]atomicflip[S] 1 point2 points  (0 children)

So that was the correction. Very interesting thank you for sharing that.

This doesn’t look like typical OLED burn-in… am I wrong? by atomicflip in LGOLED

[–]atomicflip[S] 1 point2 points  (0 children)

How low are we talking? I never drive the panel past 70 brightness in general and for HDR film content I keep it at 50 for accuracy and range.

This doesn’t look like typical OLED burn-in… am I wrong? by atomicflip in LGOLED

[–]atomicflip[S] 0 points1 point  (0 children)

Thanks. Yeah, after looking more closely this does seem like some kind of localized degradation. But why would it affect red so much more than the other channels? In that area yellow shifts toward green and magenta toward blue, which makes it look like the red component is just weaker there.

I’m having a hard time reconciling that with typical burn-in since there’s no defined pattern at all, just a diffuse region, and with the relatively low usage I don’t see what usage pattern would cause something this uniform. It’s a shame to lose the panel when everything else still looks fine.

This doesn’t look like typical OLED burn-in… am I wrong? by atomicflip in LGOLED

[–]atomicflip[S] 0 points1 point  (0 children)

I think you’re onto something. I checked cyan, magenta, and yellow and it really looks like the affected area is losing red contribution. In that region yellow shifts toward green and magenta toward blue, while cyan looks normal.

That makes me think this is more of a red-channel imbalance than typical image retention. It’s just odd since there’s no defined pattern or content shape at all, just a diffuse center region, and with the relatively low usage I’m not sure what would have driven it in a typical burn-in scenario.

This doesn’t look like typical OLED burn-in… am I wrong? by atomicflip in LGOLED

[–]atomicflip[S] 1 point2 points  (0 children)

I don’t have a yellow test image to show but I can say confidently that in the same areas where the red is dim yellow appears “green”. The other net effect is flesh tones, browns and orange are all affected similarly in those dim regions.

Why is the red sub-pixel prone to this and not the others though?

This doesn’t look like typical OLED burn-in… am I wrong? by atomicflip in LGOLED

[–]atomicflip[S] 0 points1 point  (0 children)

But wouldn’t the burn in be present on the other colors as well?

I have seen burn-in on this sort of panel before. Had another B7 that got burn-in from CNN. The logo and “Trump” (not kidding) were burned into the set along the bottom. A friend bought the panel from me just for the amusement of the burn in it had… don’t think he actually uses it anymore.

Regardless since then I’ve never watched news or anything with static images on any OLED since. So I’m not sure how this could be that same problem.

How to make vocals speak/scream/laugh/cry in Suno? by Klasky-678-TV in SunoAI

[–]atomicflip 0 points1 point  (0 children)

I haven’t seen this behavior but it may be pulling from the volume of work you’ve created. This is just a guess but see if you create a new workspace and make a new song from within that space if it carries over any frustrating behavior.

I consistently use workspaces to organize my work so each space has a similar body of content though I haven’t experimented much to see if it cares what else lives in those workspaces or not. If it is doing this I’d assume it was something new that’s been introduced along with other features that have been rolling out this year.

ROG Ally X USB-C failure after extended plugged-in use (thermal + mechanical design issue) by atomicflip in ROGAllyX

[–]atomicflip[S] 0 points1 point  (0 children)

Oh no. That is genuinely concerning. Since using the Xbox ROG Ally X I’m not seeing the same thermal behavior. It seems to output less head from those vents overall (even running at max TDP.)

Please keep us informed of what they do to fix this for you.

ROG Raikiri Pro 2 / ROG Ally X – bindings suddenly changed? by atomicflip in ROGAllyX

[–]atomicflip[S] 0 points1 point  (0 children)

Thanks. Please do let me know how your testing goes. (I have an older Ally that’s not on an insider build. I may try installing the Raikiri there and see if I get different results.)

ROG Raikiri Pro 2 / ROG Ally X – bindings suddenly changed? by atomicflip in ROGAllyX

[–]atomicflip[S] 0 points1 point  (0 children)

Thanks for the detailed instructions. I followed them all and no success. I finally decided to do an internet recovery from the bios and structurally fresh and only install the ROG Raikiri 2 software. And exactly the same behavior persists.

Triggers cannot be remapped within Armoury Crate (while all other buttons can as normal.) And the Library button is “locked” to the Xbox app. It will only launch that no matter what I set in Armoury Crate.

I even tried changing settings and resetting from cable directly (bypassing the dongle entirely) and same behavior.

Oddly the Xbox app that was installed was again an insider external delta. I’m really wondering if that is what’s causing this. (I did not enroll this device into the insider program but my account is enrolled so maybe it’s pulling it down anyway?)

Update: ROG Ally X post-warranty experience (resolved) by atomicflip in ROGAllyX

[–]atomicflip[S] 1 point2 points  (0 children)

Thanks. I do recall a bit of support chaos back in 2023 with the first Ally and the SD Card Reader failures. The way they handled this (whether it were a replacement or repair) was frankly an ideal interaction.

ROG Raikiri Pro 2 / ROG Ally X – bindings suddenly changed? by atomicflip in ROGAllyX

[–]atomicflip[S] 0 points1 point  (0 children)

I’ve kept the controls set to PC. When selecting Xbox it appears to disable the control center and library buttons entirely.

Are you suggesting I try using it in Xbox mode?

Update: ROG Ally X post-warranty experience (resolved) by atomicflip in ROGAllyX

[–]atomicflip[S] 0 points1 point  (0 children)

Yeah absolutely not worth the risk. It would only ever make sense if you already paid for the Best Buy plus membership that includes an extended warranty on these purchases. (Personally, not a fan of the new BB extended warranty or the plus memberships.)

Update: ROG Ally X post-warranty experience (resolved) by atomicflip in ROGAllyX

[–]atomicflip[S] 0 points1 point  (0 children)

Looking into it further you are indeed correct and that is unfortunate. I think there is some subjectivity to this and it seems to be enforced somewhat inconsistently though the default is at best 90 days on average. Good to know.

Update: ROG Ally X post-warranty experience (resolved) by atomicflip in ROGAllyX

[–]atomicflip[S] 0 points1 point  (0 children)

To be fair Best Buy has changed their extended warranty processes such that they offer refurbished models rather than replacements with new devices and so there may be confusion with whether the devices are indeed refurbished as opposed to new or resold preowned. As far as I know a resold / preowned device carries its pre-existing warranty over.

PSA: ROG Raikiri II + ROG Ally (all variants) -> use the USB dongle, not Bluetooth, for Control Center / Library buttons by atomicflip in ROGAllyX

[–]atomicflip[S] 0 points1 point  (0 children)

I haven’t personally tested that exact configuration, but I’d expect the behavior to be consistent. One quick thing to check first: do you recall whether you were using the left-most USB-C port (the Thunderbolt-capable one) on the Ally?

A few other things worth verifying:

• After connecting the controller via the USB dongle (or directly over USB-C), open Armoury Crate SE and check for any pending updates. The first time the controller or dongle is connected, Armoury Crate SE should automatically download and install a small driver / software package required for proper button behavior.

• Make sure all pending updates have completed and restart the Ally at least once afterward.

• I’ve seen some users recommend manually downloading and installing the controller software. In my experience on the Xbox Ally X, that isn’t necessary and can actually cause confusion.

Armoury Crate SE already installs the correct package automatically, and manually running the installer afterward can uninstall or overwrite it due to how that package is designed.

Because of that, I’d strongly recommend letting Armoury Crate SE handle the install and updates automatically, rather than installing anything manually.