Question: systray as a module?

There is no fixed timeline. It is mainly tied to which features I want in it. In the 3.6 blog post I said that I wanted to have a fixed tray, new font renderer, and some config syntax improvements in 3.7. But it is starting to look like that will be take too much time for a single release (I really want to release more often than every 12 months).

So I think we should release 3.7 once the tray module is stable and I am finished with #2609. I do want to finish #2609 before 3.7 because it will result in some breaking tray changes (basically if you had the tray anywhere outside of the bar window, this will no longer work) and if people should migrate to the module anyway that won't be a big problem.

systray as a module
Systray is placed by var ``tray = right|left``

I think that it could be a nice thing to make it as a module. To be able to place it where we want, and to duplicate it (don't think it is possible, just wondering).

@Vlek Sorry for not replying to this earlier. We never issued bounties before. There is currently an effort by @raffael0 to make the current tray a module. Once that is finished, I'd be happy to coordinate a bounty payout between the two of you through our collective.

You would then make a one-time donation and @raffael0 would submit an expense for that amount that we then pay out.

Looking forward to this, the normal systray is buggy on fluxbox. using this module would likely solve my issues.

Run this as a startup script:

#!/bin/sh
sleep 10 &
killall xembedsniproxy

Happily running polybar under KDE with the systray

@Vlek Yes, this has now finally made into a stable release in version 3.7.0.

The tracking issue for the feature is #2689 and the initial modularization work was done in #2595.

@raffael0 Do you want to receive this bounty through the polybar collective? It seems to be really easy, they even auto-generate the invoice for you. Payouts can be made through direct bank transfer or paypal.

@Vlek Appreciate you paying out a bounty for this 😃. If Raffael accepts, you can make a one-time donation to the collective with the desired amount and I will coordinate this being paid out through the collective's expense system.

Wow. Yeah i'll gladly take the bounty in any way that is easiest for you.
Thank you! Just let me know what I have to do

That's great! Once @Vlek sends the money, I can create an invoice invitation for you and you simply have to fill out the payment details. Is your protonmail email ok?

@Vlek You can now make a "Custom Contribution" with the desired amount here: URL

@patrick96 @raffael0 sent. $100 for the bounty, $20 toward Polybar. Thank you both!

image

That's very generous, thank you very much!

@raffael0 I have sent you an invoice invitation, let me know if everything works out.

I just wanted to let you know that I received the money. Thank you @Vlek for the generous bounty and @patrick96 for being a great maintainer and organizing the payout!

Stabilize tray module
With #2595 being merged, there are a few steps to make the tray module stable.
The goal is to completely deprecate positioning the tray without a module (and all `tray-*` settings in the bar section).

* [x] Automatically hide/show the tray window depending on whether a tray position (`%{Pt}` tag) is set in the renderer. This is needed to deal with hiding modules.
* [x] Remove `tray-position = adaptive` again and just activate the tray when a tray module exists (or one of the other positions is set). The existence of a tray module should override any value for `tray-position`. In particular, if a tray module exists *and* `tray-position` is set, a warning or error should be printed.
* [x] Fix the tray window being pushed off the bar if there is too much stuff on the bar. The tray window should always be fully within the bar window.
* [x] Rework all tray settings in module (see below)
* [x] Write module documentation on RTD
 * [x] Write migration docs on RTD.
* [x] Emit deprecation warnings for `tray-position` and all other tray settings in the bar section. #3002

It's probably easiest to implement each of these in a separate PR to keep complexity low. The order shouldn't matter except that the last one should be done last.

If we don't make the tray stable before the 3.7 release, polybar should also emit a warning whenever the tray module is used so that people are aware that the tray module may break again in the future.

---

For those wanting to test it out right now, I'll also add a minimal example for how to add the tray module. All of this is experimental and any config options may change before the tray becomes stable.

dosini
[bar/example]
modules-left = tray

[module/tray]
type = internal/tray
format =

---

We could now also completely change the tray behavior if the module is used without it being a breaking change. In the `tray_manager` we could have a flag `in_module` that can be used to differentiate between behavior for the old tray or the module.
We should consider taking advantage of this, especially for formatting.

* [x] There should be `tray-spacing`, which determines the spacing between the icons (`tray-padding` kind of does this already but the padding is also added at the beginning and end of the tray window.
* [x] `tray-padding` should now be applied to the left and right of each individual icon (just as what happens for regular labels). Only supports points and pixels
* [x] `tray-maxsize` and `tray-scale` should be merged into a single option. They both affect `client_height`, while `tray-maxsize` also increases spacing. This can be made cleaner. There should probably be just a single `tray-size` option (percentage with offset relative to bar height, defaults to 66%) and the final icon height and width is `min(bar_heigh, tray-size)`.
* [x] Use of `tray-background` should be discouraged. Make it clear that it will only affect tha background of individual icons, not the spacing in between.

This would help fix #1207 I think.

The following tray settings will not have any equivalent setting in the module:

* `tray-detached`: Not really sure what the use-case for this ever was
* `tray-transparent`: Already deprecated and has no effect
* `tray-offset-x`: Can be achieved with format offsets and offset tags.
* `tray-offset-y`: Due to the tray being subwindows now, it cannot be moved outside of the bar area anyway. If people want to vertically position icons within the bar, we could introduce a `tray-alignmnent` setting.

---

The new tray module would also be a workaround for #651, as long as there is enough padding before or after the tray module.

---

**Linked Issues & PRs**

* #2723
* #2726
* #2727
* #2609
* #3002

Since we now have experimental support in the feature branch we should probably add some documentation on how to use it. I think adding a new module in the wiki sidebar would probably be the best solution with a big experimental warning on top.
Another approach would be to wait with the documentation until the feature is stable.
How would you like to handle this?

I don't think documentation is crucial at the moment. Especially since any settings inside the tray module may well change again. We should probably hold off writing documentation until at least the config settings are stable.

Could you still provide a short example of how to use it? I would like to try it.

I thought a bit about the remaining issues and I have some questions/comments.
1. Hiding the tray window. Was this already implemented? I'm not really sure which position you mean. The one we set in the context or the global position(left,center...)? When are the modules hidden?
2. `tray_postition = adaptive`: Is there a way to check in the tray_manager if the tray module was instantiated? I added `adaptive` because I didn't know how to figure out when no tray module was instantiated and therefor didn't know when not to set left, right, center.
3. pushed off bar: Has there been some prior work into something similar like this(Maybe with text)? Otherwise I imagine that this is going to be really difficult to implement since we never know in the renderer how much content will be added before or after the tray and how wide the tray is. I can't think of a way to approach this.
4. How do you want to manage the configs? I can think of two approaches. First would be to keep the config handling in the tray_manager and just read the config from the tray module instead of the bar. This is a bit messy. The other option would be to move the config handling to the tray module. This is a much cleaner solution but then it's quite hard to get the config settings to the tray_manager(Maybe with a signal?) since they are completely separate right now.

Right now a lot of logic is split between the tray_manager and the tray module with no way of them interacting(Besides signals). This complicates a lot but I can't think of a way to simplify this short of moving the tray_manager completely into the tray module. I'm unsure how "clean" we should implement these things since some(like the tray_position) will be removed later which cleans up a lot of code.

I didn't formulate that clearly, I meant whether the dispatch called `apply_tray_position` with a valid position. Tray hiding wasn't implemented before but since modules can be hidden, the tray should probably support it as well.
What currently happens, is that if the module is hidden, no `%{Pt}` tag is emitted, so the tray position isn't updated and the tray just stays wherever it was in the previous render cycle.

Modules can be hidden using module actions (for example using polybar-msg).

The tray can't really check this. But what we can do, is pass this information from the controller to `bar::start` which then passes it to `tray_manager::setup`. The controller can check this in the loop where it creates the modules.

For text that doesn't fit onto the bar, we render a fading out gradient at the end of the bar when the left, right, and center blocks are placed on the bar:

 URL

However, for the tray, my idea was to not have this logic in the renderer but in the tray itself.
The tray manager knows how wide the tray and the bar are, so when it receives the `tray_pos_change` signal, it can calculate whether the new position will place the tray window (partially) outside of the bar. And instead of hiding parts of the tray window when it goes outside of the bar, we keep it at the right end of the bar instead of letting it slide off. The calculation for the tray position would look something like this:

tray_pos = bar.x + max(0, min(tray_pos, bar.w - tray_width))

I think we should go with the first option, the tray manager should be responsible for loading its own configuration options. This could be achieved by passing the name of the tray module to `tray_manager::setup`.

---

If we didn't have to still support `tray-position = left|center|right`, we would create the tray manager instace inside the tray module and would not have any of these issues about communicating information between components. But even if it is going to be removed at some point, it will still be with us for some time, so we shouldn't just be sloppy here.

With the tray becoming a module, is it possible that true transparency could be added (as per URL

Not to impose more features on this issue, just curious as to the possibility/complexity as someone without much understanding of X/WMs.

I also barely know anything about X and window managers :sweat_smile: so I'm probably not really qualified to answer that.

The changes we added in these PRs are basically one big hack. As you might know the tray right now is a separate window overlayed over the bar window. Instead of removing this window and incorporating the tray into the bar, we decided to internally create blank module with the same size as the tray window. The tray window is then just moved over the blank window in the bar. Therefore, the tray now behaves like a normal module but is still a separate window.

I think that since we only change the window position the same problem still remains with true transparency although @patrick96 probably knows a lot more about it.

I hope this helps!

Sorry for the radio silence, I have been swamped the past few weeks. I appreciate your work on this :smiley:

I should have some time to start reviewing stuff again next week, but I will only be around sporadically for at least a month or two.

---

:+1:

True transparency remains as difficult as it has before, this "new" tray module didn't really change how the tray is rendered, just where it is placed on the bar. I am considering adding back true transparency in #2609, but no promises.

I don't think we will ever get away from doing it like this. Since each tray icon is a separate window, we have to somehow overlay them over the bar window.

I'll look over/reorganize my existing PRs till next week and try to finish the settings one.

Since the plan is to release this feature with 3.7. What's your timetable for that release?

@Quantenzitrone I have also noticed this and I think I no longer see this in #2609. However certain applications still have that issue (dropbox for me) and I have not yet found a way to make them behave (I am not even sure if a way exists).

I have also decided to not implement true transparency for the tray icons because we would have to do the compositing ourselves and couldn't use a compositor like picom and I don't have the time to do that.


Question: Add an installer option to not install the service?

It seems like it worked as expected, because that an internal windows installer behavior.

Windows Installer mostly does nothing on reinstaller. To restore an installation, you have to force a repair mode.

with

msiexec.exe /fa "windows_exporter-0.26.0-amd64.msi" /qn

the service is getting restored. I tested that on a windows server. Sadly, we are unable to change the windows installer behavior here.

Add an installer option to not install the service
Hello,

because of the issue with windows_exporter not starting on boot, discussed here:

 URL
 URL
 URL

the **only** reliable way to use this software is to wrap the service in a tool such as WinSW or the classic nssm.

That isn't ideal, but at least it works - however it poses a new problem: Because the windows_exporter MSI always forecfully installs the windows_exporter service my ansible role to deploy the windows_exporter now always has to do two consecutive changes and is not properly idempotent anymore:

After installing or updating windows_exporter (change 1), it has to replace the auto-created, non-functioning service from the installer with the winsw-wrapped version of the service again (change 2 - even though the winsw service and its configuration haven't changed, this task will now result in a change)

This service flip-flopping during a rollout could be avoided if the MSI installer exposed an argument that allows the service-creation to be suppressed during the install.

Thanks!

Right now the only difference between the MSI and EXE options provided by this project are the system service and the firewall rules (plus any intrinsic MSI behaviour).
Is the EXE not an option for your use case?

I have worked around the issue by giving the working (WinSW-wrapped) service a different name (such as `windows_exporter_winsw`). Now I only have to delete/disable the `windows_exporter` service after every update of windows_exporter, but an update is a change anyways so it doesn't matter that we tack on another required follow-up change.

Using the EXE would be very inconvenient for two reasons:

1. We use package managers like `chocolatey` or `winget` to provision and update software, and both only carry the MSI installer. To use the EXE installer we would have to create and maintain a custom software package.
2. The EXE download is not an installer, just a "portable" executable. This means it doesn't register its presence on the system with the MSI software database or the registry keys for ARP. This means it won't be tracked by software inventory systems. We have to verify that updates are being installed and are working as expected in case our deployment contains a (logic) error.

Software that's in the MSI database or at least the registry can easily be inventoried and tracked across thousands of systems by external tools.

To confirm, the request originated from a need to manage the `windows_exporter` service, due to the MSI-provided service failing to start?

Is that still the case now that #1047 (`window_exporter` >= `v0.20.0`) has been implemented?

When attempting to test v0.24.0 on some machines I ran into a follow-up problem: URL

Since I had removed the (formerly unreliable) `windows_exporter` service intentionally in favor of my own, now, when I perform a reinstall of windows_exporter to recreate the service and remove my own wrapper-service (`windows_exporter_winsw`) I am left with no windows_exporter running at all - because reinstalling the software did not recreate the missing service.

Exactly.

I checked across our systems where we deployed 0.24.0 without a WinSW wrapper to test it, and we haven't seen these issues with the service failing to start anymore. Thus this issue is resolved for me, thanks.

Reinstalling MSI does not create service
When the MSI installer is re-run to do an in-place reinstall or "repair", it does not recreate the windows_exporter service if missing.

Steps to reproduce:

powershell
# Perform initial install of the latest version
choco install prometheus-windows-exporter.install --version 0.24.0
# Confirm service is created and running
Get-Service -Name windows_exporter
# Stop and delete the service
sc.exe stop windows_exporter
sc.exe delete windows_exporter
# Oops! But no worries, perform a reinstall to fix it
choco install prometheus-windows-exporter.install --version 0.24.0 --force
# Check whether the service has been recreated - it will not be there!
Get-Service -Name windows_exporter

I have noticed that the service is recreated as expected when:

- Performing an upgrade install, such as when installing 0.23.1, then deleting the service, then installing 0.24.0
- Performing an explicit uninstall first, then an install again

Yep, I reproduced with 0.25.1 as well. Here's a copy-paste repro without chocolatey, just using onboard windows stuff:

powershell
# Download windows_exporter 0.25.1
curl.exe -LO " URL

# Install it
cmd.exe /D /C start "" /wait /b msiexec.exe /i "windows_exporter-0.25.1-amd64.msi" /qn

# Confirm windows_exporter service exists
sc.exe queryex windows_exporter

# Remove windows_exporter service
sc.exe stop windows_exporter
sc.exe delete windows_exporter

# Reinstall windows_exporter to repair
cmd.exe /D /C start "" /wait /b msiexec.exe /i "windows_exporter-0.25.1-amd64.msi" /qn

# Confirm windows_exporter service exists
sc.exe queryex windows_exporter

# IT'S NOT THERE

Only way to bring the service back is to completely uninstall windows_exporter, and then reinstall.


Question: processor network error on Send transaction?

There is no actually one conclusion (as it was checked with disabled both grove and proxy(, and the discussion moved there, but yeah, seems that the issue might be on both sides - grove and proxy.
Thanks for the comment. I'll bring this issue today on wallet sync, thank you

processor network error on Send transaction
# Bug Report

## Description

Erroe message: WPP-025 - status-proxy-O.error: insufficient funds for gas * price + value: add ress 0x3212fD7C2C7984DD6de153691D901445fC8AA07 have 2783037892
8767798 want 159078669589875316

## Steps to reproduce

Use an account that has enough funds to do a send transaction on Mainnet

1. Go to the Wallet
2. Click Send
3. When the modal opens, select a small amount of eth to sent
4. Notice that an error displays

#### Expected behavior
User to be able to perform a Send tx

#### Actual behavior
User unable to do a send tx, even though they have enough funds
Screenshot 2024-09-16 at 4 43 40 PM

### Additional Information
geth 2.log.zip
app_20240916_154447.log

- Status desktop version: 2.30 rc-1
- Operating System: Mac OS Sonoma

@virginiabalducci that error doesn't come from our side, it's from the network. Not sure what we can do there.

During the sending process if any network error occurs the transfer processor will display it as `WPP-025` error, but the description may differ, it reflects a real error.

Also I see that you got this error: `WPP-025 - status-proxy-O.error: insufficient funds for gas * price + value: address 0x3212fD7C2C7984DD6de153691D901445fC8AA07 have 27830378928767798 want 159078669589875316`
but no chain we support has a positive balance for the used address `0x3212fD7C2C7984DD6de153691D901445fC8AA07`
so the error is expected, not sure what's wrong?

@virginiabalducci to get a better understanding about router's logic, please have a look at this comment URL

I guess yes, that's what we're going to do with the new Send modal design.

I experience this error whenever I try to transfer funds, such as buying a Status ENS domain or trying wallet-to-wallet transaction. The origin Status Wallet has 21 USD, and I can't transfer any amount of money to the destination Wallet on the Ethereum mainnet. The error is always the same in both Simple and Advanced modes:

`WPP-028 - status-proxy-O.error: failed with 50130704 gas: insufficient f unds for gas * price + value: address 0×925Bd[...]2917E have 0 want 4025019521328142`

This is using my Status account on mainnet, not a test account on testnet (Status desktop 2.30.0).

I'm far from an expert here, but I don't think this error is expected, @saledjenic (CC/ @virginiabalducci )

I hope this helps!

Image

Hi @jorge-campo you're right it should not be like that when buying ens name. There are 2 potential reasons for that:
- you should confirm that your account (the one you're using for sending the tx) has enough ETH to pay for the tx execution besides having 10 SNT for the ens name (in the screenshot I see that the selected token is ETH and you're trying to send 10 ETH actually). So that's most likely the reason. If you want to buy an ens name, go to Settings/Ens usernames section
- we're still using grove provider and the error that you're experiencing is coming from it and it can be unreliable in some cases and should not be there after we switch to nodefleet, that supposed to be very soon, these days. But based on the screenshot, that's not the case there.

Thanks, @saledjenic !

The screenshot is unrelated to the ENS name purchase; it's a direct wallet-to-wallet transaction of ETH on Ethereum mainnet. I have 21 USD in my wallet, and I can't send 10, 5, or 2 USD with the "insufficient gas fee" error.

I am happy to hear that the switch to Nodefleet will happen soon! 👍

Closing this one as it has been concluded this is related to network issues and not from the app itself

Unable to send tokens which are available only on L1 network
Fro reproduction you can use SNT

**Steps:**

1. Restore the account which has SNT
2. Proceed with sending flow
3. See if the routes are built after entering valid amount

**Actual result:**

Status-debug-logs - 2024-09-19T171851.912.zip

On mobile I receive different errors, like
transfer amount exceeds balance
 or
not available for chain ID

photo_2024-09-19 17 04 50
photo_2024-09-19 17 04 55

Same on Desktop:

<img width="542" alt="Status Desktop 2024-09-19 17-09-01" src=" URL

cc @saledjenic @anastasiyaig
### Additional Information

- Status version: nightly
- Operating System: Android, iOS

[comment]: # (Please, add logs/notes if necessary)

i was able to send snt just 2 days ago. i dont have any context besides that. maybe something got broken recently

@virginiabalducci can you pls check?

thanks @virginiabalducci
@saledjenic @dlipicar do you know the root cause?

@virginiabalducci I was able to reproduce your case with `0x32e12fd7c2c7984dd6de153691d901445fc8aa07` address.

So let's analyze it:
- you want to send 1 SNT from the `0x32e12fd7c2c7984dd6de153691d901445fc8aa07` from any of the supported chains (mainnet, opt, arb) to the recipient address to any chain (mainnet, opt, arb)
- what are possible options (since you have a positive balance for SNT only on mainnet):
 1. mainnet -> mainnet (transfer)
 2. mainnet -> optimism (bridge)
 3. mainnet -> arbitrum (bridge)
- let's look now at how the router sees that request since all chains are available on both from and to sides:
 1. check transfer for mainnet -> mainnet -> this returns `insufficient funds for gas * price + value: address 0x32e12fD7C2C7984DD6de153691D901445fC8AA07 have 16773029697747188 want 235096461785385998`
 2. check transfer optimism -> optimism (transfer) -> `execution reverted: ERC20: transfer amount exceeds balance` cause you have 0 SNT on optimism
 3. check transfer arbitrum -> arbitrum (transfer) -> `execution reverted: ERC20: transfer amount exceeds balance` cause you have 0 SNT on arbitrum
 4. check bridge `mainnet` -> `optimism` -> `not available for chainID` means there is no contract for bridging SNT
 5. check bridge `mainnet` -> `arbitrum` -> `not available for chainID` means there is no contract for bridging SNT
 6. check bridge `optimism` -> `mainnet` -> `not available for chainID` means there is no contract for bridging SNT
 7. check bridge `optimism` -> `arbitrum` -> `not available for chainID` means there is no contract for bridging SNT
 8. check bridge `arbitrum` -> `mainnet` -> `not available for chainID` means there is no contract for bridging SNT
 9. check bridge `arbitrum` -> `optimism` -> `not available for chainID` means there is no contract for bridging SNT
- now looking at the previous point we confirmed that there is no route that can be made, which is correct, that's what the router says, but a question is about the error, which one of those is the most meaningful for you? You cannot choose one, but the right way would be to return all of them, right? Displaying all of them was rejected as an idea in one of my PRs and then we had to choose one to display. There is some logic for selecting the most meaningful error which is working quite well, but in case like this one where all chains are in play on the "from" and "to" side is hard to select one (especially when we have different processor orders among router runs) cause all are valid errors.

**To summarize and conclude, there is no error in the router logic.**
@virginiabalducci @anastasiyaig @pavloburykh @alwx

Thank you for the comment @saledjenic

I have couple of questions here:

1. Regarding insufficient funds error: we have an open issue URL Could you please leave a comment in that issue summarising your findings regrading this problem. I remember that recently there have been much discussions in different Discord channels, but unfortunately there is no summary in the ticket. Currently we are not able to perform L1-L1 transactions in Status app, at the same time I am able to perform same transaction with the same account using Metamask.

2. At which point do we understand that token is available only on L1 and thus there is no sense to try building any routes except L1-L1? Can we prevent from trying to perform
mainnet -> optimism (bridge)
,
mainnet -> arbitrum (bridge)
 etc steps if we know that only mainnet-mainnet is available? To be honest, this is very confusing that we are showing user the irrelevant errors like
transfer amount exceeds balance
 or
not available for chain ID
 while app UI shows that we are trying to build L1-L1 route and both errors have nothing to do with L1-L1 in this case. Why we are not showing
insufficient funds
 here which is related to L1-L1 route building?

I believe we can close URL in favour of URL and wait for new RPC provider integration 🤞

i would suggest to check proxy logic since the issue was not on the router side, but on proxy. So querying Infura directly was just fine. Replacing provider wont help in this specific case. There is an explanation in URL @churik


Question: Since the last update, Media Player seems to no longer be able to play very long files?

I have no clue what your issue is exactly, what are you trying to do and what does it do and what do you expect?

Since the last update, Media Player seems to no longer be able to play very long files?
### The problem

I have a 10 hour long track of white noise I play through HA when I sleep. Been using it for a long while, with no issue.

As of the last HA update, it seems to no longer play. The file can still be played on the computer, and the HA automation that turns it on/off will still play any "normal" length file when I run the automation, but it seems to refuse to play it to the speaker if it's the too long file.

### What version of Home Assistant Core has the issue?

core-2025.4.1

### What was the last working version of Home Assistant Core?

core-2024.3.X

### What type of installation are you running?

Home Assistant OS

### Integration causing the issue

Media Player

### Link to integration documentation on our website

 URL

### Diagnostics information

Let me know what would be useful, and I'll send it to you.

### Example YAML snippet

yaml
This is the automation I use to cue it up:

action: media_player.play_media
target:
 entity_id: media_player.office
data:
 media_content_id: >-
 media-source://media_source/local/White Noise Black Screen ¦ Sleep, Study,
 Focus ¦ 10 Hours (128kbit_AAC).m4a
 media_content_type: audio/mp4
metadata:
 title: White Noise Black Screen ¦ Sleep, Study, Focus ¦ 10 Hours (128kbit_AAC).m4a
 thumbnail: null
 media_class: music
 children_media_class: null
 navigateIds:
 - {}
 - media_content_type: app
 media_content_id: media-source://media_source

### Anything in the logs that might be useful for us?

txt

### Additional information

_No response_

did you play file directly ? or use TTS to play?
my issue is URL
HA->TTS->DLNA issue.
belongs to media_player or Core?

@Obioban does it also fail to play when you do it trough the Media browser, or only on the automation?

Are there any errors or warnings on the logs?
Also, what is the integration for the media player/speaker?

When I play it in the browser, on the computer, it plays fine through the computer speakers.

When I try to set the source to the speakers, that's when it failed.

Integration is sonos-- playing to an ethernet wired sonos amp.

When I try to play the file, the log records the following 3 items:
Office changed to Paused triggered by action Media player: Play media
Office changed to Playing
Office changed to Idle

All 3 occur in the same second, per the log.

Since you asked about the speaker integration, as I diagnostic I just tried to send it to an Apple TV instead-- same result. I don't think the problem is on the speaker side.

- Are you using a reverse proxy of some sort?
- Have you correctly configured (or configured) an internal/external URLs in the core Home Assistant configuration/settings?
-
../Frenck

downgrade from 2025.4.1 to 2025.3.4 then edge-TTS->xiaodu spk ->works well
### The problem

downgrade from 2025.4.1 to 2025.3.4 then edge-TTS->xiaodu spk ->works well
after upgrade to 2025.4.0 same problem xiaodu spk fail to be TTS message to speaker
then upgrade to 2025.4.1 same issue. xiaodu spk fail
but xiaoya spk can work normally
but because i have >25 xiaodu spks so i have to downgrade from 2025.4.1 to 2025.3.4

### What version of Home Assistant Core has the issue?

2025.4.1

### What was the last working version of Home Assistant Core?

_No response_

### What type of installation are you running?

Home Assistant OS

### Integration causing the issue

_No response_

### Link to integration documentation on our website

_No response_

### Diagnostics information

_No response_

### Example YAML snippet

yaml

### Anything in the logs that might be useful for us?

txt

### Additional information

_No response_

after upgrade from 2025.3.4 to 2025.4.0 . automation can't tts message to xiaodu spk.
the whole message will be stuck in some word or repeat some words again and again ,will never stop reading
but on the same time xiaoya speaker will not happen such issue. it work normally
only xiaodu spk (A1) will not work
after downgrade to 2025.3.4 no matter xiaodu or xiaoya speakers work both well

i have upgrade to 2025.4.1 for a few days .
at frist I did not think the XiaoDu speaker issue was caused by the upgrade.
I thought it is my wifi 2.4G setting that caused it.
because XiaoYa speaker has no such issue.
until yesterday. i realized that it maybe the upgrade of the home asssistant ,those new version codes made this error
 and after i downgrade to version 2025.3.4 it fixed the XiaoDu speaker issue.
but i got above errors.
if i uparde to 2025.4.1 it will fix below error but XiaoDu speaker can't be TTS out message
The following integrations and platforms could not be set up:

recorder (Show logs)
history (Show logs)
logbook (Show logs)
energy (Show logs)
default_config (Show logs)
Please check your config and logs.
if i downgrade to 2025.3.4 will not have above history and record error but XiaoDu speaker can't work normally

Hi
`edge-TTS` is a custom component, which is not maintained by the HA core project. Please report your issue to the maintainer or in the source repository of this custom component.
Thx 👍

no matter edge-tts or google tts they both not work with xiaodu speaker
i did not upgrade edge-tts or google tts pluging (addon)
when I upgrade from 2025.3.4 to newer version. the xiaodu speaker will fail to read out message.
I do not think it is only edge-TTS plug's issue.
and no matter 2025.3.4 or 2024.4.4 their edge-tts plugin (addon) seems to be the same version

if you want use HA to TTS out a message . for example " abcdefghijklmnopqrstuvwxyz"
the xiaodu speaker will speak out h , h h h ... or stuck no message out .
repeat and repeat
over and over
will not come to end . unlesss you reboot HA


Question: docker image (mac/aarch64) failing?

Thanks a lot. Can you check if it's working without the existing `sirix-data` folder? I've just committed a fix, hopefully: URL

docker image (mac/aarch64) failing
Hi Keegan,

Do you know if it's an issue with my docker image or maybe with the Gradle docker image or something else regarding:

 URL

The Dockerfile is here: URL

kind regards, and have a nice week :-)
Johannes

Sorry, I can't tell from what's posted there what the error might be. I'm going to need some more information to be able to help. It is still the case that Alpine images don't support ARM yet, if that helps.

I believe this was resolved in sirixdb/sirix#681. If this isn't the case, let me know and we can re-open this issue.

Cannot build docker-compose on arm64/aarch64
The current docker-compose build script does not function on my M1 mac:

 % docker compose build
[+] Building 3.2s (5/5) FINISHED docker:desktop-linux
 => [server internal] load build definition from Dockerfile 0.0s
 => => transferring dockerfile: 1.83kB 0.0s
 => [server internal] load .dockerignore 0.0s
 => => transferring context: 2B 0.0s
 => ERROR [server internal] load metadata for docker.io/library/gradle:jdk21-alpine 3.2s
 => ERROR [server internal] load metadata for docker.io/library/gradle:8.4-jdk21-graal 3.2s
 => [server auth] library/gradle:pull token for registry-1.docker.io 0.0s
------

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

------
failed to solve: gradle:jdk21-alpine: no match for platform in manifest sha256:039614406f658505c65357c71056442e65b30b3f19400199d96265c88261ecc6: not found

Not sure how to solve the above.

Same as #682, I think?

Thanks for letting me know :+1: hope we'll be able to fix it

hi @JohannesLichtenberger can confirm the latest changes now work successfully for me. Awesome!

Let me add one more comment. This line in the docker-compose file:

 volumes:
 - /opt/sirix/sirix-data:/opt/sirix/sirix-data

Causes the launch to fail unless the folder is specifically created and mapped in Docker. I was able to make it boot by creating a test folder in my user dir and making it available in Docker desktop app:

` - /Users/james/sirix-data:/opt/sirix/sirix-data`


Question: 'touch' detection is invalid?

Thanks for the detailed report. You're totally right about where that new behavior is coming from.

Unfortunately, the behavior you're seeing is intended. To quote the docs:

If you're seeing the links in your browser on Windows 10, that means your browser supports touch events (more specifically, `window.TouchEvent`). That might mean your desktop/laptop has support for touch interface (many windows computers, like surface books, do), or that the browser would support a touch interface if it were installed on such a device.

The change that you saw in the newer AnchorJS version comes from a similar Modernizr update, which was intended to make touch event detection more accurate. You can see details on that here: URL

Ultimately, I'm comfortable leaving this feature as-is, focused on detecting touch-events, which only approximates touchscreen detection. The alternative is to remove the feature altogether (which is what Modernizr eventually did).

If you prefer the former behavior, I'd say feel free to continue using v4.2.2.

'touch' detection is invalid
Using this on a laptop computer, and I have set

js
 anchors.options = {
 visible: 'touch'
 }

However, it is detecting that a laptop is a touch device. When I look at the source code and try some in the browser console, `!!window.TouchEvent` is returning true, which is here in the source code — URL

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

example in use: URL

Thanks for the issue and PR. I hope to be able to take a closer look at this next week. 👍

For such an excellent plugin, I would like to share my demo, my touch can be used well! There are also hover prompts and one-click copy (he can jump to the anchor by clicking on it).

Hey, @nichoth, thanks for reporting the issue.

This issue has come up before and been discussed in detail here: URL

In short, your fix addresses some common device use-cases but breaks others because there's no reliable way to detect a touchscreen. 😞

Ultimately, this touch feature is misleading and I plan to remove it entirely in a future version of AnchorJS.

My recommendation is that if you want the older behavior of this, you can use version 4.2.2 as described here.

Ok thanks for checking it out. I am using my fork currently, and that has been working for me.

Anchor icon is always visible on Windows when visible=touch after promoted to v4.3.0
**Issue description**

We identified a behavior change after promoted Anchorjs from v4.2.2 to v4.3.0.

 We are using `visible: touch` as anchor options. For `v4.2.2`, the anchor image is `hover` on page of `Windows10`, after promoted to `v4.3.0`, the anchor image is `always` there instead of `hover`.

Here are sample pages to help understand the issue:
_v4.2.2 page(hover)_: URL
_v4.3.0 page(always)_: URL

**Operating System**: Windows

**AnchorJs version**: 4.3.0

**Expected Behavior**:
AnchorJS links only become visible when hovering over the headings like before for Windows when visible is touch.

**Actual Behavior**:
AnchorJS links are always visible for Windows when visible is touch.

**Note:**
This behavior change seems related to the newly added condition `window.TouchEvent` in function `isTouchDevice()` with this commit

this.isTouchDevice=function(){return Boolean("ontouchstart"in window||**window.TouchEvent**||window.DocumentTouch&&document instanceof DocumentTouch)}

,this.isTouchDevice=function(){return!!("ontouchstart"in window||window.DocumentTouch&&document instanceof DocumentTouch)}

`Boolean('ontouchstart' in window || window.TouchEvent || window.DocumentTouch && document instanceof DocumentTouch)` returns true in the current Chrome (Version 105.0.5195.125) on my old MacBook Pro, which doesn't have a touch screen. The new behavior is unacceptable to me, so I will have to stay on v4.2.2. 😕


Question: Cleanup CSI Snapshots post Polling of VSC times out in CSI Plugin.

There are two issues being discussed here:
1. Object has been modified issue:

I1111 12:01:13.229378 1 snapshot_controller.go:167] updating VolumeSnapshotContent[snapcontent-c5a12581-b9c7-430e-9c61-9bcb576a60d4] error status failed Operation cannot be fulfilled on volumesnapshotcontents.snapshot.storage.k8s.io "snapcontent-c5a12581-b9c7-430e-9c61-9bcb576a60d4": the object has been modified; please apply your changes to the latest version and try again

This has been fixed for all common cases in snapshotter master, which will be in v5.0.0. The version v4.2.1 will not have this fix.

2. #533 - this issue is unrelated to the above error. I've reproduced it in master without the `object has been modified error`. The object are constantly being re-queued without backoff, even though backoff is configured. I'm still looking into why that is the case.

I've been busy the past few weeks, but I'm hoping to continue looking into this one again soon.

Cleanup CSI Snapshots post Polling of VSC times out in CSI Plugin.
**What steps did you take and what happened:**

As of today the CSI plugin waits for the VSC to get reconciled for default 10minutes.
After that CSI leaves the VS in the cluster.
This leads to accumulation of useless VS in the cluster which ends up throttling the CSI drivers installed in the cluster. Because the CSI driver keeps on retrying endlessly.

**What did you expect to happen:**
Cleanup the VS if tracking has failed in the CSI plugin.

**The following information will help us better understand what's going on**:

_If you are using velero v1.7.0+:_
Please use `velero debug --backup --restore ` to generate the support bundle, and attach to this issue, more options please refer to `velero debug --help`

_If you are using earlier versions:_
Please provide the output of the following commands (Pasting long output into a GitHub gist or other pastebin is fine.)
- `kubectl logs deployment/velero -n velero`
- `velero backup describe ` or `kubectl get backup/ -n velero -o yaml`
- `velero backup logs `
- `velero restore describe ` or `kubectl get restore/ -n velero -o yaml`
- `velero restore logs `

**Anything else you would like to add:**

Related issue #6209 and also in similar code path as #6165

**Environment:**

- Velero version (use `velero version`):
- Velero features (use `velero client config get features`):
- Kubernetes version (use `kubectl version`):
- Kubernetes installer & version:
- Cloud provider or hardware configuration:
- OS (e.g. from `/etc/os-release`):

**Vote on this issue!**

This is an invitation to the Velero community to vote on issues, you can see the project's top voted issues listed here.
Use the "reaction smiley face" up to the right of this comment to vote.

- :+1: for "I would like to see this bug fixed as soon as possible"
- :-1: for "There are more important bugs to focus on right now"

Could you give more background about CSI drivers reaching their throttle when there is enough legacy VS left?
Although VSs are accumulated, they should end with `ReadyToUse` state, do CSI drivers still poll on those VSs?

URL
 URL

The polling is controlled by the external snapshotter. That will relentlessly try. Have verified from logs.
Earlier even exponential backoff was broken in external snapshotter, it is fixed now (AFAIK), but still the expectation is that "checkSnapshotANdUpdate" there is a function like this which is periodically called and if a VS/VSC is not ready, it will attempt to fix it.

Do you mean this function `checkandUpdateContentStatusOperation`?
If we are talking about this function, checking the not-ready VolumeSnapshotContent or VolumeSnapshot seems inevitable, and that only happens for the not-yet-ready VolumeSnapshotContents. The accumulated VolumeSnapshotContents should have no impact on this.

I can check back on the exact functionality on code pointers(will take me some time to look back at the code), but I am confident on the behavior of external snapshotter retrying endlessly. We have verified multiple times from ext snapshotter logs.

Keeping that investigation aside do you see any merit otherwise in leaving the orphan VS in the cluster?
Irrespective we should still cleanup the VS which are not being used/wont be GCed from the cluster.

Those VolumeSnapshots are kept for backup deletion. They are kept for deleting the snapshot resources from cloud providers.
I agree with you that this is not an ideal way, and they should be cleaned.
With the current design, if we delete those VolumeSnapshots, the VolumeSnapshots should be restored before deleting the backup to prevent snapshots left on providers forever, and I didn't find a fitting place to do that.

Those VS are not even tracked as part of the backup
on failure, the BIA returns nil

So during GC these VS is not cleaned up.
They are just orphan VS.

If we are talking about the error case, I agree those VSs should be cleaned in this place.

external-snapshotter constantly retrying CreateSnapshot calls on error w/o backoff
Creating a snapshot from a non-existing volume will repro this. @jsafrane discovered this, opening this issue for tracking.

Ran into this as well. If further info can be helpful let me know.

@travisghansen did you repro this by creating a snapshot from a non-existing volume? Want to make sure it's the same cause.

In my case the api call to the backing storage system had some invalid options in the payload resulting in a failure. I would effectively pass the failed api response back up to the grpc client (this repo?) and observe that over and over at a rapid pace.

Hi, ran into this issue while there was a permissions issue and create snapshot call has failed. Attached logs (enabled verbose logging in snapshotter) if they might help.

snapshotter_logs.txt

I see an `enqueued "snapcontent-c5a12581-b9c7-430e-9c61-9bcb576a60d4" for sync ` everytime as part of `setAnnVolumeSnapshotBeingCreated` method - Not sure if this is expected.

As there is a create snapshot call almost every 150ms, the underlying API is getting throttled. Also there are too many mutations to the snapshot object. As the API throttling is generally at a customer tenant level this might impact other customer scenarios as well. Any update on the issue/fix ?

+1
The controller seems to be in a bad state, and can bring the cluster health by throttling the vendor APIs

@ggriffiths any update on this fix?

Yes, that is the same issue @shrac. I'm looking into the root cause of this issue, no update yet.

Does this still happen with the latest code in the master branch?

@anshulahuja98 The following error should not occur any more with the code in the master branch.

I1111 12:01:13.229378 1 snapshot_controller.go:167] updating VolumeSnapshotContent[snapcontent-c5a12581-b9c7-430e-9c61-9bcb576a60d4] error status failed Operation cannot be fulfilled on volumesnapshotcontents.snapshot.storage.k8s.io "snapcontent-c5a12581-b9c7-430e-9c61-9bcb576a60d4": the object has been modified; please apply your changes to the latest version and try again

@ggriffiths This should be fixed with the "patch" fix?

Can you point me to the PR that fixed it? I am not very clear as to what fixed it.
And when can we expect the new release with the required fix.
Current version is 4.2.1 from August

@anshulahuja98 This following PR changes "update" to "patch". That reduces the error "the object has been modified".
 URL

@ggriffiths How to set the backoff to the snapshot-controller?

@xing-yang @ggriffiths Maybe ecause of the URL to update the snapshotcontent.

After the snapshot was created failed, it will to remove the "snapshot.storage.kubernetes.io/volumesnapshot-being-created" and update the snapshotcontent.

image
If we don't remove the annotion "snapshot.storage.kubernetes.io/volumesnapshot-being-created" and not update the snapshotcontent, the retry interal is 1s. 2s, 4s, 8s,16s,32s,64s,128s,256s, 5min.

I see. So it is not really a normal requeue due to the failure but it is a new update that triggers the requeue. If we don't remove the annotation "snapshot.storage.kubernetes.io/volumesnapshot-being-created" and don't update the snapshotcontent, how does the snapshotter know the creation has failed? If the annotation is not removed, the snapshotter will think the storage system is still working on the snapshot creation. CreateSnapshot will be called to query the snapshot status. One thing to explore is to see if we can use ListSnapshots instead of CreateSnapshot (if ListSnapshots is supported by CSI driver) to check snapshot status.

Another idea to explore is to compare the old obj vs the new obj when update is triggered. If the annotation "snapshot.storage.kubernetes.io/volumesnapshot-being-created" is the only thing being removed, maybe we don't need to go through CreateSnapshot again.

If we can only compare the annotations of the snapshotcontent, if they are different, we don't re-queue.

I think we need to check if the annotation "snapshot.storage.kubernetes.io/volumesnapshot-being-created" is the only thing being removed and if that's the only change. If there are other changes, we still need to process it.


Question: Fix bugs on Korean MSX Conversion To SMS games On SG-1000 Mode Emulation?

I already answered these issues report:
- those games do NOT work on stock SG-1000 hardware because they need more RAM than the SG-1000 has (afaik, MSX has more RAM than SG-1000)
- the colors look wrong but that is how they look on Master System hardware

The solution to your problem is to run these games on SG-1000 hardware with RAM extension cartridge, which is not possible yet in this emulator but you are free to use another emulator if it works for you... just stop spamming the issue report.

Fix bugs on Korean MSX Conversion To SMS games On SG-1000 Mode Emulation
Bug:
168426478-19e640b6-d2c5-4bb4-b307-1c736fc22aaa
168426489-68094b63-dd8a-43fa-bba7-8ce8b76f53b7
168426499-11534212-7e93-4128-a7c9-23d97efa1a3a

Fixed:
168426558-d89354ff-b41b-470a-8076-a6583ab8abbf
168426585-5842bd13-4c39-42fa-8679-186101233835
168426617-aba13656-ac8f-49e8-b58a-c2198fffe84f

You must add Feature of RAM

SG-1000/SG-1000 II RAM:

Master System/Mark III/Master System II RAM:

Game Gear RAM:

Genesis / Mega Drive / CD RAM:

Reported. Don't you get tired of this? If you want support for a corner case, fork the code and do it yourself.
If the main developer abandons this great project, it will be because of you. You're boring stones.

I am considering closing the issue reports for good, too bad for other people but this constant trolling (or maybe it is just some foem of autism, I don't know... and don't care) is too annoying.

He has been reported at least twice to github but still comes back after a while. He is also apparently doing the same in other emulators repisitory, looking at the user history.

@ekeeke for the record, I am autistic. But, I would never go out of my way to harass someone like this individual has done. Usually, when someone bullies someone online, from a psychological standpoint, it is because they are trying to fill the gap over something they have no control over in life, be it divorce, problems with friends or family, etc.

There are certainly better things to do with one's free time. Just don't let this stuff get you down.
I have dealt with my own share of bullies when working on various online projects. But, you just gotta keep strong in mind at all times. And, you will prevail.

When I first got into working with the Mini Classics, another team decided to try to push me out of the scene with various tactics. In the end, me just being me, being nice to everyone, had way more people supporting my unorthodox and creative solutions and workarounds, emulation wise, and I am satisfied with the current state of things.

If you like movies or tv shows, find something you've been meaning to watch! Just know, people like me will always have your back and appreciate what efforts you put forth in anything and all you do, whether or not they are autistic:)

@MrKrabs07 Stop spamming the same request.

The spam links:

#432
#430
#425
#422
#420
#419
#417
#416
#415
#414
#413

Those are Master System games (with .sms file extension) They don't work on SG-1000 Hardware because SG-1000 has 1KB or 2KB RAM but they need 8KB Before. Master System & Game Gear mode with TMS9918 mode is Incorrect by SMS Plus. Including SMS Plus GX, Kega Fusion, MEKA, Gearsystem Always uses TMS9918. Gearsystem, Kega Fusion, MEKA, SMS Plus's SG-1000 Uses 16KB RAM.

The color look wrong on TMS9918 Content on Master System & Game Gear Hardware. Black Screen On Genesis/Mega Drive Hardware. Genesis/Mega Drive Has No TMS9918-Compatible. Master System Has 256-Colors (Z80 CPU). Like CRT TV CPUs Uses Z80.

**RULES:**

1. No spamming

2. No Not Safe For Work Content

3. No Copyrighted Content

@ekeeke Please lock this conversation and delete issue #432 #425 #422 #420 #419 #417 #416 #415 #414 #413

@SquidwardKrabs we all know it's just you under another account. It is so very nice to see you are such an upstanding individual that you spend all of your free time playing mental games. You realize, if you keep this up, you will only make it so ekeeke and others no longer have interest in bettering these emulators for the thousands upon thousands of people that use them. There are far better things you can do with your free time than bullying others online.

Also note, what you are doing is actually a crime, which can land you in jail if you keep it up.

@ekeeke Sorry to see you have to go through this nonsense due to an obviously mentally unstable individual who truly needs to get help.

Genesis Plus GX 1.7.6 Request: Fix Bug On Some MSX Conversation Games On SG-1000.
It's Not Correct When Some MSX Conversation Games Bug On SG-1000 Emulation. I Know That MSX Conversation Games Works On SG-1000 Hardware. Also Works On Gearsystem Core. Try To Use Gearsystem Core And Update SG-1000's Emulation To Gearsystem Core's SG-1000 Emulation. I'm NOT Spamming. Do NOT Dislike That Issue.
 URL
156840091-ae84839e-089f-474c-a453-f24df0ba0239
156840105-b869a04f-74a2-4486-a377-ed362dc25dd3
156840122-647f9344-1a5c-4852-b25b-75d8b2ce365e
156840129-4a87bf25-63b8-4a0f-8b05-fe7f59d46cd1
156840133-ec7822c4-e0f4-4c82-b3a3-33396583dcd3
156840140-560f34d4-bcb1-46e3-aadf-395b2e4400d9

It sure looks like you are spamming to me. And you have fired up 3 different accounts apparently. No means no buddy.

image

I'm Using MD.emu For Android. I Need To Get Support For SG-1000 With Gearsystem Core, Game Gear With Genesis Plus GX Core. Master System, Genesis, Sega CD To Be Updated Core To Genesis Plus GX. Got It.

I Need 8GB RAM Phones Running On Android 11 To Download More Emulators. Google Pixel 5.

@HaroldSlikk You Must Stop Spamming. You Have To Read Community Guidelines. You're Not Allowed To Spam. It's Illegal. Also About Community Guidelines Strike, Copyright Strike