jami-daemon issueshttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues2020-12-18T19:26:47Zhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/260A client should be able to answer a call multiple times without weird results2020-12-18T19:26:47ZSébastien BlinA client should be able to answer a call multiple times without weird results# Reproduce steps
+ Launch 2 clients with auto answer (client-gnome + python) for example or (daemon with --auto-answer + client gnome)
+ Receive a call
+ Both clients are answering => Video not ok sometimes, or no hangup available, etc...# Reproduce steps
+ Launch 2 clients with auto answer (client-gnome + python) for example or (daemon with --auto-answer + client gnome)
+ Receive a call
+ Both clients are answering => Video not ok sometimes, or no hangup available, etc
# Expected result
+ The daemon should ignore answer request if already answered, video should work and hangup toohttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/255Do not test libcuda on non compatible hardware2020-12-18T19:58:07ZJürgen LütersDo not test libcuda on non compatible hardwareHi all.
During a video connection between jami android and jami-gnome the file /var/log/user.log gets flooded with messages:
Jul 2 13:08:23 nuc dring: -- Init encoding for cuda with device 1.
Jul 2 13:08:23 nuc cx.ring.Ring[4352]: ...Hi all.
During a video connection between jami android and jami-gnome the file /var/log/user.log gets flooded with messages:
Jul 2 13:08:23 nuc dring: -- Init encoding for cuda with device 1.
Jul 2 13:08:23 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc74a18000] Cannot load libcuda.so.1
Jul 2 13:08:23 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc74a18000] Could not dynamically load CUDA
Jul 2 13:08:23 nuc dring: -- Init encoding for cuda with device 2.
Jul 2 13:08:23 nuc dring: Failed to set preset 'veryfast'
Jul 2 13:08:23 nuc dring: Failed to set tune 'zerolatency'
Jul 2 13:08:23 nuc dring: -- Starting encoding init for vaapi with default device.
Jul 2 13:08:23 nuc dring: Using hardware encoding for h264 with vaapi.
Jul 2 13:08:23 nuc cx.ring.Ring[4352]: Output #0, rtp, to 'rtp://80.134.238.234:63854':
Jul 2 13:08:23 nuc cx.ring.Ring[4352]: Metadata:
Jul 2 13:08:23 nuc cx.ring.Ring[4352]: encoder : Lavf58.29.100
Jul 2 13:08:23 nuc cx.ring.Ring[4352]: Stream #0:0: Video: h264 (Constrained Baseline), vaapi_vld, 320x240, q=
Jul 2 13:08:24 nuc cx.ring.Ring[4352]: [sdp @ 0x7fdc6c000900] max delay reached. need to consume packet
Jul 2 13:08:24 nuc cx.ring.Ring[4352]: [sdp @ 0x7fdc6c000900] RTP: missed 1 packets
Jul 2 13:08:25 nuc dring: Restarting video sender
Jul 2 13:08:25 nuc dring: -- Starting encoding init for cuda with default device.
Jul 2 13:08:25 nuc dring: -- Init encoding for cuda with device 0.
Jul 2 13:08:25 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc74040400] Cannot load libcuda.so.1
cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc74040400] Could not dynamically load CUDA
Jul 2 13:08:25 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc74a18000] Cannot load libcuda.so.1
Jul 2 13:08:25 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc74a18000] Could not dynamically load CUDA
Jul 2 13:08:25 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc744d0a00] Cannot load libcuda.so.1
Jul 2 13:08:25 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc744d0a00] Could not dynamically load CUDA
Jul 2 13:08:25 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc74003a40] Cannot load libcuda.so.1
Jul 2 13:08:25 nuc cx.ring.Ring[4352]: [AVHWDeviceContext @ 0x7fdc74003a40] Could not dynamically load CUDA
Andoid jami 20200623-01
Jami Gnome 2020-06-30 20:45:35 UTC (debian/Gnu Linux Testing )
If i am not totally mistaken cuda is for nvidia devices only. But there is none nvidia graphic card.
Shouldn't it be suffice to scan the hardware once ?
My Hardware according to lspci
00:00.0 Host bridge: Intel Corporation 8th Gen Core Processor Host Bridge/DRAM Registers (rev 08)
00:02.0 VGA compatible controller: Intel Corporation Iris Plus Graphics 655 (rev 01)
00:08.0 System peripheral: Intel Corporation Xeon E3-1200 v5/v6 / E3-1500 v5 / 6th/7th/8th Gen Core Processor Gaussian Mixture Model
00:12.0 Signal processing controller: Intel Corporation Cannon Point-LP Thermal Controller (rev 30)
00:14.0 USB controller: Intel Corporation Cannon Point-LP USB 3.1 xHCI Controller (rev 30)
00:14.2 RAM memory: Intel Corporation Cannon Point-LP Shared SRAM (rev 30)
00:14.3 Network controller: Intel Corporation Cannon Point-LP CNVi [Wireless-AC] (rev 30)
00:16.0 Communication controller: Intel Corporation Cannon Point-LP MEI Controller #1 (rev 30)
00:17.0 SATA controller: Intel Corporation Cannon Point-LP SATA Controller [AHCI Mode] (rev 30)
00:1c.0 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #1 (rev f0)
00:1c.4 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #5 (rev f0)
00:1d.0 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #9 (rev f0)
00:1d.6 PCI bridge: Intel Corporation Cannon Point-LP PCI Express Root Port #15 (rev f0)
00:1f.0 ISA bridge: Intel Corporation Cannon Point-LP LPC Controller (rev 30)
00:1f.3 Audio device: Intel Corporation Cannon Point-LP High Definition Audio Controller (rev 30)
00:1f.4 SMBus: Intel Corporation Cannon Point-LP SMBus Controller (rev 30)
00:1f.5 Serial bus controller [0c80]: Intel Corporation Cannon Point-LP SPI Controller (rev 30)
00:1f.6 Ethernet controller: Intel Corporation Ethernet Connection (6) I219-V (rev 30)
02:00.0 PCI bridge: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] (rev 02)
03:00.0 PCI bridge: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] (rev 02)
03:01.0 PCI bridge: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] (rev 02)
03:02.0 PCI bridge: Intel Corporation JHL6340 Thunderbolt 3 Bridge (C step) [Alpine Ridge 2C 2016] (rev 02)
04:00.0 System peripheral: Intel Corporation JHL6340 Thunderbolt 3 NHI (C step) [Alpine Ridge 2C 2016] (rev 02)
05:00.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
06:00.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
06:01.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
06:02.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
06:03.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
06:04.0 PCI bridge: Intel Corporation JHL6540 Thunderbolt 3 Bridge (C step) [Alpine Ridge 4C 2016] (rev 02)
07:00.0 USB controller: Fresco Logic FL1100 USB 3.0 Host Controller (rev 10)
09:00.0 USB controller: Fresco Logic FL1100 USB 3.0 Host Controller (rev 10)
0b:00.0 USB controller: Intel Corporation JHL6540 Thunderbolt 3 USB Controller (C step) [Alpine Ridge 4C 2016] (rev 02)
6c:00.0 USB controller: Intel Corporation JHL6340 Thunderbolt 3 USB 3.1 Controller (C step) [Alpine Ridge 2C 2016] (rev 02)
6e:00.0 Unassigned class [ff00]: Realtek Semiconductor Co., Ltd. RTS522A PCI Express Card Reader (rev 01)https://git.jami.net/savoirfairelinux/jami-daemon/-/issues/248Stuck in Connecting/Searching: timeout duration2020-07-02T20:06:29ZSébastien BlinStuck in Connecting/Searching: timeout durationRelated to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227
Actually ICE_NEGOTIATION_TIMEOUT is 60 seconds. This is pretty long and the user will close the window before thisRelated to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227
Actually ICE_NEGOTIATION_TIMEOUT is 60 seconds. This is pretty long and the user will close the window before thisIteration 19Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/246Stuck in Searching/Connecting: Improve logs2020-07-07T17:49:52ZSébastien BlinStuck in Searching/Connecting: Improve logsEverything is in the title. The negotiation of a call can be quite complex to understand and logs should be understandable, moreover if the call fails.
Related to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227Everything is in the title. The negotiation of a call can be quite complex to understand and logs should be understandable, moreover if the call fails.
Related to https://git.jami.net/savoirfairelinux/ring-daemon/issues/227Iteration 19Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/242Video encoding - Dynamically change the resolution of the encoded frames2022-01-18T22:20:21ZMohamed ChibaniVideo encoding - Dynamically change the resolution of the encoded framesBacklogMohamed ChibaniMohamed Chibanihttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/237Use acceleration for recording2023-12-27T18:07:03ZPierre LespagnolUse acceleration for recordinghttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/228File transfer: multiple improvements2020-06-29T15:07:19ZSébastien BlinFile transfer: multiple improvements+ [ ] Remove eventloop from PeerConnection
+ [ ] Fix potential resources deadlocks
+ [ ] Fix mutex usage
+ [ ] Channeled File Transfer to avoid ICE negotiation when possible.+ [ ] Remove eventloop from PeerConnection
+ [ ] Fix potential resources deadlocks
+ [ ] Fix mutex usage
+ [ ] Channeled File Transfer to avoid ICE negotiation when possible.Iteration 18Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/190Redo TLSSession (again, in space)2020-03-11T14:18:27ZSébastien BlinRedo TLSSession (again, in space)Since https://review.jami.net/c/ring-daemon/+/8392 TlsSession is a bit better. However, the class takes a `SocketType& transport_;` and this makes the class hard to use!
There is no reason to not have a unique_ptr for the transport_. On...Since https://review.jami.net/c/ring-daemon/+/8392 TlsSession is a bit better. However, the class takes a `SocketType& transport_;` and this makes the class hard to use!
There is no reason to not have a unique_ptr for the transport_. Only that session should be able to use the transport.Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/187TLSSession + ICETransport make the API async2020-11-10T21:44:34ZSébastien BlinTLSSession + ICETransport make the API asyncReplace all waitxxx in the API by something asyncReplace all waitxxx in the API by something asynchttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/176Contact not added indirectly2020-03-15T12:12:15ZovariContact not added indirectly1. Accept contact request using Android smartphone
2. Turn on GNU/Linux computer #1 and open Jami Gnome → contact is added
3. Turn off Wi-Fi and turn off Mobile data on Android smartphone
4. Turn on GNU/Linux computer #2 and open Jami Gn...1. Accept contact request using Android smartphone
2. Turn on GNU/Linux computer #1 and open Jami Gnome → contact is added
3. Turn off Wi-Fi and turn off Mobile data on Android smartphone
4. Turn on GNU/Linux computer #2 and open Jami Gnome → `contact is not added (this is a bug)`
5. Turn on Mobile data on Android smartphone → contact is now added to GNU/Linux computer #2 with Jami Gnome
The contact was online when all these steps were done; however, step 4 should also work if the added contact was offline. What do you think?
@sblin is this a bug with the Gnome client or otherwise?
Are you able to reproduce and fix?
Thank you
Android smartphone<br>
Nokia 1 Plus<br>
Android 9 Pie<br>
Jami Live Free or Die - 20191031-01
GNU/Linux computer #1<br>
Linux Mint 19.2 Cinnamon 64-bit<br>
Jami built on 2019-11-09 02:50:12 UTC
GNU/Linux computer #2<br>
Linux Mint 19.2 Cinnamon 64-bit<br>
Jami built on 2019-11-09 02:50:12 UTChttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/161Remove currentCall and holding management in daemon2019-10-07T18:40:08ZSébastien BlinRemove currentCall and holding management in daemonIteration 17 (Video conferences stabilization)Andreas TraczykAndreas Traczykhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/159Clean logs from jams + split account2019-10-07T17:43:14ZSébastien BlinClean logs from jams + split accountIteration 16 (POC prep)https://git.jami.net/savoirfairelinux/jami-daemon/-/issues/145API: add playMedia/pause/stop2021-02-04T13:55:59ZSébastien BlinAPI: add playMedia/pause/stopTo play ringtones without breaking calls from the client and recorded messages.To play ringtones without breaking calls from the client and recorded messages.Pierre LespagnolPierre Lespagnolhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/142file transfer: partial file remains on pc after cancel2020-10-08T17:51:44ZPhilippe Gorleyfile transfer: partial file remains on pc after cancelCancelling a file transfer (on the receiving side) should remove the partial file.Cancelling a file transfer (on the receiving side) should remove the partial file.Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/136[API ready]Swarm: support request for resending a file transfer2021-06-12T11:37:55ZSébastien Blin[API ready]Swarm: support request for resending a file transfer+ The daemon should store a link or the file in private datas to retrieve it
+ A peer in a conversation is able to re-ask for a file transfer
+ when downloaded sha3sum must be checked.+ The daemon should store a link or the file in private datas to retrieve it
+ A peer in a conversation is able to re-ask for a file transfer
+ when downloaded sha3sum must be checked.Swarm-chatSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/119Resend failed files when peer is online2020-12-24T21:22:33ZSébastien BlinResend failed files when peer is onlineLike messagesLike messagesSébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/116ICE: Lot of unneeded buffers2021-08-19T18:15:16ZSébastien BlinICE: Lot of unneeded buffersThe ICE negotiation uses a lot of different buffers. A lot of copy can be replaced by `std::move`
Also lot of unnecessary `comp_id-1`.The ICE negotiation uses a lot of different buffers. A lot of copy can be replaced by `std::move`
Also lot of unnecessary `comp_id-1`.Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/115Socket_pair: Buffer should be resizable2019-05-24T14:44:18ZSébastien BlinSocket_pair: Buffer should be resizableFor now, SRTPProtoContext have the attribute `encryptbuf` limited to `RTP_MAX_PACKET_LENGTH = 2048;`. This is good for UDP, but not TCP compliant.For now, SRTPProtoContext have the attribute `encryptbuf` limited to `RTP_MAX_PACKET_LENGTH = 2048;`. This is good for UDP, but not TCP compliant.Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/114Remove MTU phase from tls_session (unused code)2021-08-03T13:32:54ZSébastien BlinRemove MTU phase from tls_session (unused code)This code is deactivated since a long time. Could be removed.
However, the MTU can be retrieven via pjsip (or should be)This code is deactivated since a long time. Could be removed.
However, the MTU can be retrieven via pjsip (or should be)Sébastien BlinSébastien Blinhttps://git.jami.net/savoirfairelinux/jami-daemon/-/issues/101Auto improve video quality2021-02-04T13:55:46ZSébastien BlinAuto improve video qualityThe algorithm is already in the daemon, but need to be improved and activated on mobile devices.The algorithm is already in the daemon, but need to be improved and activated on mobile devices.Pierre LespagnolPierre Lespagnol