Skip to content
Snippets Groups Projects
Closed Chat History No Longer Visible
  • View options
  • Chat History No Longer Visible

  • View options
  • Closed Issue created by vindicatorr

    Bug report form

    Describe your environment

    Please specify the following:

    • OS: Arch linux
    • Jami version: 202112271445
    • What build you are using: [your own (daemon:02c5cecd363a1ee25a914d72e243d7903e44969b; lrc:48db64cbcd3a8d7a12cad940694ce9239b8db576; client-qt:83f68573]

    Steps to reproduce

    Note: Better the scenario is, better we will be able to reproduce and debug.

    • Can you reproduce the bug: [at will]
    • Steps:
      1. Send messages between clients
    • Actual result: Android device sees all messages while client-qt doesn't see any, including what client-qt sent, including emojis.
    • Expected result: Show the history

    Additional information

    This is a continuation of my testing and it began with chat history showing for the previous contacts I paired with.

    I deleted those old contact histories and removed the accounts, then paired the latest created android contact.

    I sent that android contact a message. The message was received and also showed in client-qt.

    Then I think I was about to send a message from android, but from the side of my eye, I noticed my qt history went blank.

    Heh, I see the messages DO exist in /home/username/.local/share/jami/<id>/conversations/<id>/.git/. Interesting way to go about it, but something I like if a contact edits or deletes their message, it will (ideally) still exist in the log.

    Screenshots/videos/logs/etc Screenshot_20211227_224126

    Sample from the conversation git log:

    commit <id>
    Author: <name> <<id>>
    Date:   Tue Dec 28 04:22:46 2021 +0000
    
        {"body":"Where did my message go?","type":"text/plain"}

    $ jami-qt -d:

    "notify server name: Plasma, vendor: KDE, version: 5.23.4, spec: 1.2"
    qt.webenginecontext: 
    
    GLImplementation: desktop
    Surface Type: OpenGL
    Surface Profile: NoProfile
    Surface Version: 3.0
    Using Default SG Backend: yes
    Using Software Dynamic GL: no
    Using Angle: no
    
    Init Parameters:
      *  application-name Jami 
      *  browser-subprocess-path /usr/lib/qt6/QtWebEngineProcess 
      *  d  
      *  disable-features DnsOverHttpsUpgrade,ConsolidatedMovementXY,InstalledApp,BackgroundFetch,WebOTP,WebPayments,WebUSB,PictureInPicture 
      *  disable-setuid-sandbox  
      *  disable-speech-api  
      *  disable-web-security  
      *  enable-features NetworkServiceInProcess,TracingServiceInProcess 
      *  enable-main-frame-before-activation  
      *  enable-threaded-compositing  
      *  gpu-preferences UAAAAAAAAAAoAAAQAAAAAAAAAAAAAAAAAABgAAAAAAAwAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAgAAAAAAAAACAAAAAAAAAAAAAAAAAAAAAIAAAAAAAAAAgAAAAAAAAACAAAAAAAAAA= 
      *  in-process-gpu  
      *  lang en 
      *  no-sandbox  
      *  num-raster-threads 2 
      *  single-process  
      *  use-gl desktop 
    
    No migration required
    Can't open file:  "/home/username/.local/share/jami/<id>/profile.vcf"
    Screen saver dbus interface:  "org.freedesktop.ScreenSaver"
    Syncing lrc accounts list with the daemon
    lookup name NOT FOUND: "" "<id>"
    NetworkManager client initialized, version:   , daemon running: no , networking enabled: no
    no primary network connection detected, check network settings
    NewAccountModel::getAccountInfo, can't find dummy ; Using default avatar
    NewAccountModel::getAccountInfo, can't find dummy ; Using default avatar
    qrc:/src/mainview/MainView.qml:372:5: QML WelcomePage: StackView has detected conflicting anchors. Transitions may not execute properly.

    The last line came about when I clicked on my contact.

    For retrieving logs, cf this page.

    EDIT0: Actually, while I'm here and mentioning the git conversations, why isn't all of that ~/.local stuff also encrypted? Is the password only used to encrypt the backup? If so, why is it even asked on account creation and not just at backup? I'd think the password would have everything encrypted in the respective ~/.local/... path.

    Edited by vindicatorr

    Linked items 0

  • Link items together to show that they're related or that one is blocking others.

    Activity

    • All activity
    • Comments only
    • History only
    • Newest first
    • Oldest first
    Loading Loading Loading Loading Loading Loading Loading Loading Loading Loading