teams-for-linux
teams-for-linux copied to clipboard
appIdleTimeout not respected?
Describe the bug
Hi,
I am using Teams-for-Linux on NixOS and with Hyprland, I have set the following config in .config/teams-for-linux/config.json:
{
"appActiveCheckInterval": 6000,
"appIdleTimeout": 6000,
"appIdleTimeoutCheckInterval": 6000,
"awayOnSystemIdle": false,
"optInTeamsV2": true
}
With the following settings, I would expect the status not to go idle before 6000s (1.6h) but the app goes to idle after 300s.
If I launch the app via the terminal with the following command:
teams-for-linux --appLogLevels debug --enableDesktopNotificationsHack --enable-features=UseOzonePlatform --ozone-platform=wayland
The terminal output:
[DEBUG] GetSystemIdleState => IdleTimeout: 6000s, IdleTimeoutPollInterval: 6000s, ActiveCheckPollInterval: 6000s, IdleTime: 0s, IdleState: 'active'
However, teams go to idle after 300s (the default value). I check with a stopwatch, and regardless of my activity on my pc, as long as I leave the mouse cursor out of the teams app, my status will turn from available to idle after 300ms.
I tested by setting appIdleTimeout to 100s either in the config.json or via passing as an argument when launching teams via the terminal. Teams only go idle after 300s thus not respecting the 100s.
Expected behavior Teams should go idle after the appIdleTimeout value, so in my case 6000s.
Desktop (please complete the following information):
- OS: Nixos
- Installation package Nix packages
- Version 1.4.27
It looks like you are using a fairly old version. We did solve the problem of the appIdleTimeout with teams V2 but I don't recall what version.
Just released 1.7.4 and I would recommend if you update to it and check again.
On Wed, 26 Jun 2024, 15:47 Julien76, @.***> wrote:
Describe the bug
Hi,
I am using Teams-for-Linux on NixOS and with Hyprland, I have set the following config in .config/teams-for-linux/config.json:
{ "appActiveCheckInterval": 6000, "appIdleTimeout": 6000, "appIdleTimeoutCheckInterval": 6000, "awayOnSystemIdle": false, "optInTeamsV2": true }
With the following settings, I would expect the status not to go idle before 6000s (1.6h) but the app goes to idle after 300s.
If I launch the app via the terminal with the following command:
teams-for-linux --appLogLevels debug --enableDesktopNotificationsHack --enable-features=UseOzonePlatform --ozone-platform=wayland
The terminal output:
[DEBUG] GetSystemIdleState => IdleTimeout: 6000s, IdleTimeoutPollInterval: 6000s, ActiveCheckPollInterval: 6000s, IdleTime: 0s, IdleState: 'active'
However, teams go to idle after 300s (the default value). I check with a stopwatch, and regardless of my activity on my pc, as long as I leave the mouse cursor out of the teams app, my status will turn from available to idle after 300ms.
I tested by setting appIdleTimeout to 100s either in the config.json or via passing as an argument when launching teams via the terminal. Teams only go idle after 300s thus not respecting the 100s.
Expected behavior Teams should go idle after the appIdleTimeout value, so in my case 6000s.
Desktop (please complete the following information):
- OS: Nixos
- Installation package Nix packages
- Version 1.4.27
— Reply to this email directly, view it on GitHub https://github.com/IsmaelMartinez/teams-for-linux/issues/1320, or unsubscribe https://github.com/notifications/unsubscribe-auth/AADJHEHSHA4WQZXDGOFOXNTZJLIAFAVCNFSM6AAAAABJ6B64QOVHI2DSMVQWIX3LMV43ASLTON2WKOZSGM3TKNJWG4ZTANA . You are receiving this because you are subscribed to this thread.Message ID: @.***>
Thanks for your answer. I have not realized that the nix version was so outdated... I see someone created an issue on the nixpkgs repo: https://github.com/NixOS/nixpkgs/issues/322636 I will close this issue as I won't have time to install and test the new version before my vacation. I will re-open this issue if the problem persists after testing the newer version.
Actually I am reopening the issue because I tested with version 1.7.4 on nixos, and the behavior is the same:
- AppIdleTimeout = 6000s -> goes idle after 300s
- AppIdleTimeout = 100s -> goes idle after 300s
I did more tests using a Gnome 46 session instead of Hyprland and the results are the same:
- AppIdleTimeout = 6000s -> goes idle after 300s
-
AppIdleTimeout = 100s -> goes idle after 300s
if you open the app with --webDebug (or right click on the menu and see debug option). Can you check if you get any of this logs?
setUserStatus teams2 status=${status}
'Failed to set teams2 User Status'
'Failed to set User Status'
And, if you can, put the logs in here (also console ones) but start with all the log levels, not only debug. Is not determining the logs hierarchically, but only printing the ones listed.
teams-for-linux -appLogLevels=error,info,warn,debug --enableDesktopNotificationsHack --enable-features=UseOzonePlatform --ozone-platform=wayland --webDebug
@IsmaelMartinez, I'm currently on vacation and I'll post the logs once I'm back (mid July ).
It can also be that the appIdleTimeoutCheckInterval and appActiveCheckInterval are far too high.
I would use the default values for those, otherwise the activityHub doesn't check often enough. I suspect is around that area otherwise there will be a lot of people complaining that this isn't working 😄
Enjoy your holidays!
I suspect @IsmaelMartinez is correct.
I have experienced this behavior and after some tinkering I found the settings below to work as expected.
{
"appIdleTimeout": 3600,
"appIdleTimeoutCheckInterval": 30,
"awayOnSystemIdle": false,
"closeAppOnCross": false,
"optInTeamsV2": true,
"useMutationTitleLogic": true
}
I think that it should work as well when leaving appIdleTimeoutCheckInterval with its default value (10 seconds) but I have not tried that.
On another note awayOnSystemIdle does not work when locking the screen on a (GNOME) session. Not sure if this flag is even conceived to prevent Teams showing the status as "Away" when the screen is locked (?).
The debug output when locking the screen:
[DEBUG] GetSystemIdleState => IdleTimeout: 3600s, IdleTimeoutPollInterval: 30s, ActiveCheckPollInterval: 2s, IdleTime: 0s, IdleState: 'active'
[DEBUG] GetSystemIdleState => IdleTimeout: 3600s, IdleTimeoutPollInterval: 30s, ActiveCheckPollInterval: 2s, IdleTime: 0s, IdleState: 'locked'
Which I have traced to:
- When the screen is locked, this will evaluate to
activityHub.setMachineState(2):
https://github.com/IsmaelMartinez/teams-for-linux/blob/9d2c1ddf4f447898db5a290b0fe608e98936ea51/app/browser/notifications/activityManager.js#L22
- Which in turn will transition to idle:
https://github.com/IsmaelMartinez/teams-for-linux/blob/9d2c1ddf4f447898db5a290b0fe608e98936ea51/app/browser/tools/activityHub.js#L45
I am not sure of the logic here so apologies if I am mistaken, but the outcome is that awayOnSystemIdle does not work when locking the screen.
Let me know if you need any further tests or if you prefer me to open a separate issue for this.
Cheers!
Desktop (please complete the following information):
- OS: Fedora 40 x86_64
- Installation package: RPM
- Version: 1.7.4
I don't know if it would be possible to handle the "lock" functionality. As I wasn't the developer that implemented that functionality, it might take me some time to find out. If you could open a separated ticket with that as an enhancement that would be great, as it is not related to this issue. Thanks!
actually @kindofblues , isn't this what you are asking for? https://github.com/IsmaelMartinez/teams-for-linux/issues/1081
actually @kindofblues , isn't this what you are asking for? #1081
@IsmaelMartinez, I saw that issue but what I am asking is quite the opposite: never show "Away", even when the screen is locked :smiley: I think awayOnSystemIdle does not handle the logic this way.
I don't know if it would be possible to handle the "lock" functionality. As I wasn't the developer that implemented that functionality, it might take me some time to find out. If you could open a separated ticket with that as an enhancement that would be great, as it is not related to this issue. Thanks!
Alright, just a suggestion, probably another flag can be added awayOnLockedScreen ? This will keep the logic of awayOnSystemIdle intact while adding the extra functionality to those that wish to be seen as truly always online.
open then a new ticket. Not sure how can be done to be honest so that might influence if there is a new flag or just use the same one. Probably best re-using the same flag as otherwise it can create conflicts.
Done, see https://github.com/IsmaelMartinez/teams-for-linux/issues/1329.
Cheers!
closing. Reopen if the solution doesn't work.