savoirfairelinux issueshttps://git.jami.net/groups/savoirfairelinux/-/issues2020-09-16T15:58:30Zhttps://git.jami.net/savoirfairelinux/jami-client-qt/-/issues/59WIzardview refinement2020-09-16T15:58:30ZMing Rui ZhangWIzardview refinement- margins
- avatar should be smaller
- top right "X" should be top left "< Back" except when it actually means close(in that case, it should not appear at all), also it should
not overlay with other items
- Fix logic issues - margins
- avatar should be smaller
- top right "X" should be top left "< Back" except when it actually means close(in that case, it should not appear at all), also it should
not overlay with other items
- Fix logic issues Itération 21Ming Rui ZhangMing Rui Zhanghttps://git.jami.net/savoirfairelinux/jami-client-qt/-/issues/58Crash when accessing message web view source code2021-02-04T13:56:25ZAlbert Babí OllerCrash when accessing message web view source code![bug_view_source](/uploads/1eb232e38ed91e104cf94795585cd013/bug_view_source.png)
- Right click on the conversation and select "View page source" causes crash (tried on Ubuntu, need to check on Windows)
- Same problem in other qt demo ex...![bug_view_source](/uploads/1eb232e38ed91e104cf94795585cd013/bug_view_source.png)
- Right click on the conversation and select "View page source" causes crash (tried on Ubuntu, need to check on Windows)
- Same problem in other qt demo examplesMing Rui ZhangMing Rui Zhanghttps://git.jami.net/savoirfairelinux/jami-nameservice/-/issues/3Duplicate username for different user IDs2023-05-21T23:19:00Zanarchist IvanovDuplicate username for different user IDsHello!
Several years ago I created a Jami account with username and then I lost password or something else. I don't remember why I didn't use it.
Maybe a year ago I created another Jami account. I've used it on my Linux desktop and o...Hello!
Several years ago I created a Jami account with username and then I lost password or something else. I don't remember why I didn't use it.
Maybe a year ago I created another Jami account. I've used it on my Linux desktop and on android phone. When I copied this account to the phone app, I tried to add same username as in my first account and I got it. Same name was applied for this account on the desktop app.
Today I found a backup of my first account in `.local/share/jami` directory and restored it on the desktop app. But username also was restored and now I've got two accounts with the same username.
![duplicate-names-jami](/uploads/3b1287365376af5a85d0e6a264944936/duplicate-names-jami.png)
Then I made a backup of my first account again and deleted it from my desktop app.
But now when I search my account in a desktop app I get two accounts in the search results.
![duplicate-names-jami-2](/uploads/dafaf7944358c511634d5507d8380fea/duplicate-names-jami-2.png)
I would like to understand what's happening and how to delete username from one of my accounts.
Thank you.https://git.jami.net/savoirfairelinux/jami-client-gnome/-/issues/1195if you type a message and receive a call at the same time, text is erased2021-07-09T21:00:00ZGuillaume Hellerif you type a message and receive a call at the same time, text is erasedalso occurs if you receive a call, start typing a message then peer hangs up
--> text is erasedalso occurs if you receive a call, start typing a message then peer hangs up
--> text is erasedhttps://git.jami.net/savoirfairelinux/jami-jams/-/issues/53Add endpoint to retreive a user trough his username2021-08-19T20:38:10ZLarbi GharibAdd endpoint to retreive a user trough his usernameTo retrieve a user profile at the moment we have to use the /api/auth/directory/search which make the query slower because the endpoint is processing a search query while we already provided the username which is unique.
Also the endpoin...To retrieve a user profile at the moment we have to use the /api/auth/directory/search which make the query slower because the endpoint is processing a search query while we already provided the username which is unique.
Also the endpoint should return one profile object not an array of profiles.Félix SidokhineFélix Sidokhinehttps://git.jami.net/savoirfairelinux/jami-jams/-/issues/52Password should not be stored in the database2020-12-21T15:43:41ZLarbi GharibPassword should not be stored in the databaseThis is a security issue.
The password should be hashed and salted before storing it in the database.
Maybe we should also the reset password from @WebServlet("/api/admin/user") endpoint on the GET request.
Admin should only be allow...This is a security issue.
The password should be hashed and salted before storing it in the database.
Maybe we should also the reset password from @WebServlet("/api/admin/user") endpoint on the GET request.
Admin should only be allowed to submit a new password like already implemented in the PUT request.Félix SidokhineFélix Sidokhinehttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/695Connectivity: be more resilient if a TURN server is not available2022-11-26T22:42:09ZSébastien BlinConnectivity: be more resilient if a TURN server is not available# Reproduce steps
+ In the settings change the turn address to something that will not work but resolvable (ex: enconn.fr)
+ Try to do a call
# Expected results
+ The call should work as soon as possible with the TURN ignored
# Curre...# Reproduce steps
+ In the settings change the turn address to something that will not work but resolvable (ex: enconn.fr)
+ Try to do a call
# Expected results
+ The call should work as soon as possible with the TURN ignored
# Current result
+ The client try to connect to the TURN server for each ICE and result with a timeout of several seconds (jami-daemon~20 on linux) for each ICE negotiations making the call just unusable
# Why?
When making a call, the first step is to gather all candidates and send this message through the DHT (or direct p2p connection if available). But to gather the TURN candidate, pjsip needs to connect to it and ask for a new session. For TCP connections, the connect() will take a lot of time to timeout (depending on /proc/sys/net/ipv4/tcp_syn_retries), for UDP I didn't dig enough to fully understand what pjsip is waiting, but I think it's something related to that candidate allocation.
# Solutions
Several solutions can be created:
1. (pjsip specific) A new timer for TURN candidate creation can be created inside pjsip, to be able to ignore TURN candidates if it's taking too long. Because Jami is a real time communication app, if the allocation is taking more than 3 seconds, this means that we are taking too much time and it's not acceptable.
2. (system + pjsip specific) Manually set the connection timeout on the sockets. For TCP, we need to do a setsockopt on TCP_SYNCNT. 2 SYN retries is acceptable imho (that's about 3 seconds. First packet + 1 retry). A solution need to be created for platforms not supporting this op. For UDP as I didn't dig enough, I don't really know what's really blocking so this will need further investigation
3. (best solution imho) Support the RFC for Trickle ICE. I don't really like 1 or 2 because sometimes TURN can work and we will ignore that fact if it's taking too long. Trickle ICE will allow us to send candidates as soon as it's gathered. This means we will be able to send separately host candidates, UPnP, relays like TURN. This is clearly the solution that will take the more time to implement, but the best solution imho.
Note for 3: the drawback I see is that, because we will send candidates separately, this will generate multiple values on the DHT instead of one. Which is a bit bad.https://git.jami.net/savoirfairelinux/jami-product-backlog/-/issues/38Connectivity: be more resilient if a TURN server is not available2022-02-03T18:29:22ZSébastien BlinConnectivity: be more resilient if a TURN server is not available# Reproduce steps
+ In the settings change the turn address to something that will not work but resolvable (ex: enconn.fr)
+ Try to do a call
# Expected results
+ The call should work as soon as possible with the TURN ignored
# Curre...# Reproduce steps
+ In the settings change the turn address to something that will not work but resolvable (ex: enconn.fr)
+ Try to do a call
# Expected results
+ The call should work as soon as possible with the TURN ignored
# Current result
+ The client try to connect to the TURN server for each ICE and result with a timeout of several seconds (jami-daemon~20 on linux) for each ICE negotiations making the call just unusable
# Why?
When making a call, the first step is to gather all candidates and send this message through the DHT (or direct p2p connection if available). But to gather the TURN candidate, pjsip needs to connect to it and ask for a new session. For TCP connections, the connect() will take a lot of time to timeout (depending on /proc/sys/net/ipv4/tcp_syn_retries), for UDP I didn't dig enough to fully understand what pjsip is waiting, but I think it's something related to that candidate allocation.
# Solutions
Several solutions can be created:
1. (pjsip specific) A new timer for TURN candidate creation can be created inside pjsip, to be able to ignore TURN candidates if it's taking too long. Because Jami is a real time communication app, if the allocation is taking more than 3 seconds, this means that we are taking too much time and it's not acceptable.
2. (system + pjsip specific) Manually set the connection timeout on the sockets. For TCP, we need to do a setsockopt on TCP_SYNCNT. 2 SYN retries is acceptable imho (that's about 3 seconds. First packet + 1 retry). A solution need to be created for platforms not supporting this op. For UDP as I didn't dig enough, I don't really know what's really blocking so this will need further investigation
3. (best solution imho) Support the RFC for Trickle ICE. I don't really like 1 or 2 because sometimes TURN can work and we will ignore that fact if it's taking too long. Trickle ICE will allow us to send candidates as soon as it's gathered. This means we will be able to send separately host candidates, UPnP, relays like TURN. This is clearly the solution that will take the more time to implement, but the best solution imho.
Note for 3: the drawback I see is that, because we will send candidates separately, this will generate multiple values on the DHT instead of one. Which is a bit bad.Backloghttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/288Connectivity: be more resilient if a TURN server is not available2021-12-29T21:18:42ZSébastien BlinConnectivity: be more resilient if a TURN server is not available# Reproduce steps
+ In the settings change the turn address to something that will not work but resolvable (ex: enconn.fr)
+ Try to do a call
# Expected results
+ The call should work as soon as possible with the TURN ignored
# Curre...# Reproduce steps
+ In the settings change the turn address to something that will not work but resolvable (ex: enconn.fr)
+ Try to do a call
# Expected results
+ The call should work as soon as possible with the TURN ignored
# Current result
+ The client try to connect to the TURN server for each ICE and result with a timeout of several seconds (~20 on linux) for each ICE negotiations making the call just unusable
# Why?
When making a call, the first step is to gather all candidates and send this message through the DHT (or direct p2p connection if available). But to gather the TURN candidate, pjsip needs to connect to it and ask for a new session. For TCP connections, the connect() will take a lot of time to timeout (depending on /proc/sys/net/ipv4/tcp_syn_retries), for UDP I didn't dig enough to fully understand what pjsip is waiting, but I think it's something related to that candidate allocation.
# Solutions
Several solutions can be created:
1. (pjsip specific) A new timer for TURN candidate creation can be created inside pjsip, to be able to ignore TURN candidates if it's taking too long. Because Jami is a real time communication app, if the allocation is taking more than 3 seconds, this means that we are taking too much time and it's not acceptable.
2. (system + pjsip specific) Manually set the connection timeout on the sockets. For TCP, we need to do a setsockopt on TCP_SYNCNT. 2 SYN retries is acceptable imho (that's about 3 seconds. First packet + 1 retry). A solution need to be created for platforms not supporting this op. For UDP as I didn't dig enough, I don't really know what's really blocking so this will need further investigation
3. (best solution imho) Support the RFC for Trickle ICE. I don't really like 1 or 2 because sometimes TURN can work and we will ignore that fact if it's taking too long. Trickle ICE will allow us to send candidates as soon as it's gathered. This means we will be able to send separately host candidates, UPnP, relays like TURN. This is clearly the solution that will take the more time to implement, but the best solution imho.
Note for 3: the drawback I see is that, because we will send candidates separately, this will generate multiple values on the DHT instead of one. Which is a bit bad.Backloghttps://git.jami.net/savoirfairelinux/jami-client-android/-/issues/792"Can't open camera" message when trying to take a picture on Android TV2020-09-11T03:16:06Z"Can't open camera" message when trying to take a picture on Android TVAndroid TV Device: Ematic Jetstream
OS version: 9
Jami version: 20200828-01
I had a previous 720p webcam where the "take a picture" option was working but I have now a 1080p webcam and the message "Can't open camera" appears instead, ...Android TV Device: Ematic Jetstream
OS version: 9
Jami version: 20200828-01
I had a previous 720p webcam where the "take a picture" option was working but I have now a 1080p webcam and the message "Can't open camera" appears instead, as you can see in this screenshot:
![Can_t_open_camera](/uploads/389fcca17475fce281377d33c35aa787/Can_t_open_camera.png)https://git.jami.net/savoirfairelinux/jami-client-android/-/issues/790Images are sometimes cropped.2021-08-19T20:32:49ZMarinus SavoritiasImages are sometimes cropped.Sometimes when images are sent the image appears cropped. I checked on the phone of the sender and the image appears normally on theirs. Its messed up somehow by jami's proccessing.
![Screenshot_20200902-121058_Jami_1](/uploads/f989fb92c...Sometimes when images are sent the image appears cropped. I checked on the phone of the sender and the image appears normally on theirs. Its messed up somehow by jami's proccessing.
![Screenshot_20200902-121058_Jami_1](/uploads/f989fb92c363bb47b3f3283900bb26bc/Screenshot_20200902-121058_Jami_1.png)
- Ring version: 20200810
- Device model: Fairphone 3
- Android version: 9.0 /e/OS with Microg
- What build you are using: F-Droidhttps://git.jami.net/savoirfairelinux/jami-client-android/-/issues/7891080p outgoing video resolution drops a lot of frames on Android TV2020-09-11T03:16:04Z1080p outgoing video resolution drops a lot of frames on Android TVAndroid TV Device: Ematic Jetstream
OS version: 9
Jami version: 20200828-01
Now that the aspect ratio problem is finally fixed (https://git.jami.net/savoirfairelinux/ring-client-android/issues/747), I recently bought a generic 1080p/2...Android TV Device: Ematic Jetstream
OS version: 9
Jami version: 20200828-01
Now that the aspect ratio problem is finally fixed (https://git.jami.net/savoirfairelinux/ring-client-android/issues/747), I recently bought a generic 1080p/25fps UVC webcam, when I select the 720p outgoing resolution in settings, the videocall is smooth, but if I select the 1080p option, the video drops a lot of frames, it's unbearable.
I wonder what could be the reason since I tested the webcam on my computer and I didn't noticed any dropped frames.
Please let me know if you need any logs or something.https://git.jami.net/savoirfairelinux/jami-client-gnome/-/issues/1194Multiple accounts: No notification / answer buttons in incoming calls2020-09-18T15:42:38ZHussein AbdallahMultiple accounts: No notification / answer buttons in incoming callsI have several Jami and SIP accounts enabled. All of them are registered and I can switch between accounts using the drop-down list. When I receive an incoming call on a SIP or a Jami account that is not currently selected in the drop-do...I have several Jami and SIP accounts enabled. All of them are registered and I can switch between accounts using the drop-down list. When I receive an incoming call on a SIP or a Jami account that is not currently selected in the drop-down list, I hear the ring tone, but I don't see any notifications and I don't see the buttons to answer (or reject) the call. I have to:
* switch to the account that is ringing
(I still don't see the answer/reject buttons at this point)
* select the Jami account or the phone number that is calling me in the left pane (contact lists) in order to see the answer/reject buttons
It is very confusing: When I hear the ring tone, I can't know which account is ringing when I have more than one account enabled (typically I have at least one SIP and one Jami account enabled all the time). Even if I find out which account is ringing, it can be difficult to find the contact who is calling me because it is not always the first contact in the list (it could be the 10th contact). Basically it means that there is a high risk that I will miss the call.
Expected behavior: see an incoming call notification no matter which account is selected in the drop-down list.
I don't have this issue when the account that is ringing is already selected in the drop-down list: I see both the incoming call notification and the screen with answer / reject buttons.Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-client-qt/-/issues/57Chatview: datatransfer is broken2020-09-03T18:24:48ZAndreas TraczykChatview: datatransfer is broken- incoming file message button tooltips are inverted
- the buttons don't seem to do anything
- incomplete transfer reports as finished for peer- incoming file message button tooltips are inverted
- the buttons don't seem to do anything
- incomplete transfer reports as finished for peerItération 21https://git.jami.net/savoirfairelinux/jami-client-qt/-/issues/56Settings: name registration is broken2020-09-17T22:00:48ZAndreas TraczykSettings: name registration is broken- connections aren't made sometimes
- registration button disappears after a timeout
- spinner icon has empty tooltip
- error icon should be replaced- connections aren't made sometimes
- registration button disappears after a timeout
- spinner icon has empty tooltip
- error icon should be replacedItération 21Ming Rui ZhangMing Rui Zhanghttps://git.jami.net/savoirfairelinux/jami-client-qt/-/issues/55Application wide binding loops cause crashes when resizing2020-09-17T22:01:22ZAndreas TraczykApplication wide binding loops cause crashes when resizingEventually, the client will crash during resize events.Eventually, the client will crash during resize events.Itération 21https://git.jami.net/savoirfairelinux/jami-client-qt/-/issues/54code smell: MaterialButton should not specify Layout.* fields2021-02-04T13:56:23ZSébastien Blincode smell: MaterialButton should not specify Layout.* fieldsBecause it can be used outside a layoutBecause it can be used outside a layoutAline Gondim SantosAline Gondim Santoshttps://git.jami.net/savoirfairelinux/jami-project/-/issues/1049sip: the user should be warned if port 5060 is already taken2022-11-03T02:42:36ZSébastien Blinsip: the user should be warned if port 5060 is already takenAll is in the titleAll is in the titlehttps://git.jami.net/savoirfairelinux/jami-client-android/-/issues/788Android Connectivity issues list.2021-08-19T20:38:06ZMarinus SavoritiasAndroid Connectivity issues list.This is my try to make a complete list of Jami connectivity issues on the Android Client as of the latest version on fdroid.
1. Jami needs a force stop every morning to get or send messages
2. Also There seems to be the image/file tr...This is my try to make a complete list of Jami connectivity issues on the Android Client as of the latest version on fdroid.
1. Jami needs a force stop every morning to get or send messages
2. Also There seems to be the image/file trasfer problems that are reported elsewhere.
* Mainly here: savoirfairelinux/ring-daemon#66
* and here: savoirfairelinux/ring-client-android#656
* and here: savoirfairelinux/ring-project#696
* this also applies on android: savoirfairelinux/ring-client-windows#582
3. It may sometimes get stuck in syncing data and it is not obvious to the user what to do. Or if it is even an issue.
* Like here: savoirfairelinux/ring-client-android#683
4. Sometimes the connectivity will fail without an obvious error. This leads to the user not knowing if the app failed. That can happen at anytime during the day. It happens between 4-5 Times a day.
5. There is also the offline indicator. The green buble. Which right now may or may not mean anything since it never gets refreshed.
* It is reported here: savoirfairelinux/ring-client-android#770
* Also: savoirfairelinux/ring-client-ios#84 although its for ios it still applies here
* And here savoirfairelinux/ring-client-android#654
**These issues are observed with:**
Ring version: 20200810
Device model: Fairphone 3
Android version: 9.0 /e/OS with Microg
What build you are using: F-Droidhttps://git.jami.net/savoirfairelinux/jami-project/-/issues/1094Python error during dependencies install for Windows2021-05-14T20:26:13ZjoelihnPython error during dependencies install for Windows
```
(elevated)C:\jami\ring-project>./make-ring.py --dependencies --qt
```
fails
```
(elevated)C:\jami\ring-project>./make-ring.py --dependencies --qt
```
fails