Merging multiple databases with the same chat results in duplicated messages in chat history

[unilock]

Hi. I have a large amount of Skype database backups dating from 2017 to 2019 (22 to of them). I'd like to use Skyperious to merge all of these into one database and ultimately export a chat or two that has sentimental significance to a friend and I, but upon doing so (manually, one by one, merging right into an empty new database), there are duplicated messages in the chat: Note that the chats themselves are not duplicated, only the messages within the chats. It doesn't seem anyone has had this issue before, looking at the bugtracker. I was hoping for some assistance; maybe some Python / SQL command to run to remove all duplicates, so I don't have to manually merge each of the 22 backups again. If necessary, I can share some (or all) of the backups privately, if it would help resolve the issue. Also, a bit off topic, but would it be possible to merge multiple databases at once? In case I do end up having to do that again; that would make the job easier.

Thank you so much for making this program. These chats really do mean a lot to me, and especially the export function makes viewing and sharing these memories much easier.

[suurjaak]

I suppose it's possible to whip up an SQL command to remove those duplicates, but first I'd like to figure out why they appear in the first place.

Can you run this query in the SQL window of the merged database plus some of the original unmerged databases, export the result as Excel workbook, and send the files to my e-mail, erki@lap.ee? The query to run:

SELECT * FROM Messages WHERE body_xml LIKE "%so maybe getting an HTC phone is not a good idea%"

Also, a bit off topic, but would it be possible to merge multiple databases at once?

Not in the graphical interface, but yes, this can be done using the command-line interface.

[unilock]

Certainly. I've emailed you an archive of exports from running that command on every database that contains the message in question, as well as the merged database. It's good to know about the CLI having an option to merge databases, too. It'll be useful for the future, I imagine. Thanks much for taking a look.

[suurjaak]

Found the problem. It's to do with the different sign-in names, one from older Skype and the other the new live e-mail ID. When creating a blank database with the new live ID as username, secondary merges will consider the messages different because the author in the target database is different.

If you create a blank Skype database with your older skypename instead, and merge in the databases, the messages will not be duplicated. Or just use a copy of an older database as the target where to start merging into. Preferably the latest one, merging the others will take less time and it will have a more up-to-date schema.

---

I think I should add an option to change the live ID of a database, or to ask for both skypename and live ID on creating a blank database. And merging should check over all the sign-in IDs on either side when message author is database account.

[unilock]

OK, I've created a new merged database with the latest backup I have (2019-04-07) as the target, this time using Skyperious' merge argument. The messages no longer appear to be duplicated, but the database is about three times as large as the original merged database (2021-01-28), and there are problems with chat and participant duplication that were not present in the other merged database. I've uploaded the new merged database to the MEGA folder I shared with you over email, if you'd like to take a look at it. Should I try using the GUI to merge databases one by one again, using my latest backup instead of a blank database synced with my Microsoft account as the target? Also, contacts aren't merged when using the merge argument; would it be possible to implement that as well?

[suurjaak]

Chats being duplicated is a new one. Could you share that original 2019-04-07 database as well? Looks like there might something unexpected in the data there, and it would really help seeing it play out on my own system.

The extra size of the database must be because of the duplicated chats.

Contacts not getting merged cannot be due to using command-line merge, as the functionality behind there is the same as in the GUI. I'm guessing it is caused by the same issue that causes duplicate chats.

What happens if you start merging into a copy of the earliest backup instead, in database date order? Doesn't matter if using the GUI or the command-line.

[suurjaak]

Update: I did figure out that contacts not being merged is an actual bug. This will be fixed in the next release.

[unilock]

OK, I've added 2019-04-07.db to the MEGA folder. I've yet to try merging databases in reverse order (earliest last in CLI argument order); I'll try it later today.

[suurjaak]

Side note: file arguments get sorted alphabetically, so specifying a different order on the command-line will not yield a different result.

[unilock]

Sorry -- so the order of arguments (as in databases to merge) doesn't matter, save for the last argument (database) which acts as the target to merge onto?

[suurjaak]

Yes, the file argument order does not matter, and the last database in the sorted list is the one that is taken as the target base. I think I should drop that sorting altogether, it is unexpected behaviour.

Now, with that last 2019-04-07 database I could finally reproduce the duplicate chats issue, and found the problem - command-line merge doesn't refresh its data between the merges properly when merging more than two databases at once, so it blissfully inserts existing chats all over again.

This will be fixed in the next release.

[unilock]

Yes, the file argument order does not matter, and the last database in the sorted list is the one that is taken as the target base.

I see. So I should rename a given database something like "zzz_$NAME" if I want it to be interpreted as the target for merging?

Eagerly awaiting the next release.

[suurjaak]

So I should rename a given database something like "zzz_$NAME" if I want it to be interpreted as the target for merging?

Yep, that would work.

[suurjaak]

Just released a new version, v4.5, with fixes for contacts not getting merged, and for command-line merge producing duplicates.

And added an option to change the live ID of a database, and an option to delete chats from the database.

[unilock]

That's great!

Using v4.5, I'm trying to merge all of my databases again, the target being a new database created by downloading all messages on Microsoft's servers associated with my Skype email address (NOT my Skype username, as I've disabled the ability to log in using that). This database is called 2021-02-11.db. However, when attempting to merge the databases, it instead seems to sort them randomly (though it chooses the same database as a target each time), and refuses to merge with the above database as the target no matter its name (e.g. "zzz.db" does not work). Any ideas?

[suurjaak]

Found the problem. There was a bug in processing the command-line arguments - it did not actually retain their order.

I am loathe to issue an immediate official new release without confirming it works. Can you try this attached setup: skyperious_4.5.1_x64_setup.zip, and report how it fares?

[unilock]

That works! I was able to merge all of my databases using the latest one (2021-02-11) as the base/target.

However, there still seems to be some message duplication, particularly from the bot "Zo" (from a quick skim, I don't believe any other accounts had message duplication).

In terms of contacts, I'm still not sure if all are being merged via the command line, as the newest merged database (2021-02-11) only has 408 contacts, as opposed to the initial merged database (2021-01-28), which has 1834. Though this could be another issue of duplication. I've uploaded both databases to the MEGA folder, if you'd like to check them out.

Also, I'm not sure if this is a known issue, but grabbing images (even recent ones) doesn't work; every link returns a HTTP 401 error.

[suurjaak]

Re: images, are you talking about the links in chat history like https://api.asm.skype.com/v1/objects/... ? To see them in a browser, you would also have to be logged in to Skype online in that browser. If you export the chat as HTML, the images get downloaded and embedded into the export file, if they're still available online. Do they get downloaded if you export to HTML? Preferably with a newer chat, not sure how long Skype retains the pictures.

Regarding contacts - only those contacts are merged that have participated in chats with some activity. Because there can be a lot of cruft among the contacts - it used to be so that even just searching for people in Skype automatically added all those contact rows to the database.

---

Looking at those duplicate messages, seems that the issue is with bot account IDs, looks like they come in a somewhat different form, and so the messages are not recognized as duplicates.

Can you do the following:

• open a database and log in to Skype online
• open the Python console (menu Help -> Show Python console)
• in the console, execute db.live.skype.contacts.contact("dd02eb70-197a-4dbc-8591-e4e88a5093a0")
• and db.live.skype.contacts.contact("28:dd02eb70-197a-4dbc-8591-e4e88a5093a0")
• and db.live.skype.chats.chat("28:dd02eb70-197a-4dbc-8591-e4e88a5093a0")

What are the results?

[unilock]

Images: Ah, yep, logging in to Skype in the web browser allows me to view them properly. Exporting the chat as HTML downloads the images as well; at least the newer ones (post 2017). Note that images sent by bots (at least Zo) don't appear to have their format automatically detected; they're saved as files without extensions, but open fine in MS Paint. Out of curiosity, is there any way to import images from Skype's media caches? (located in [Skype data]/[username]/media_messaging/media_cache_v3)

Here are the results of running those Python commands on my most recent merged database:

>>> db.live.skype.contacts.contact("dd02eb70-197a-4dbc-8591-e4e88a5093a0")
SkypeContact(id=u'dd02eb70-197a-4dbc-8591-e4e88a5093a0', name=Name(), location=Location())
>>> db.live.skype.contacts.contact("28:dd02eb70-197a-4dbc-8591-e4e88a5093a0")
SkypeContact(id=u'dd02eb70-197a-4dbc-8591-e4e88a5093a0', name=Name(), location=Location())
>>> db.live.skype.chats.chat("28:dd02eb70-197a-4dbc-8591-e4e88a5093a0")
SkypeSingleChat(id=u'28:dd02eb70-197a-4dbc-8591-e4e88a5093a0', alerts=True, userId=u'dd02eb70-197a-4dbc-8591-e4e88a5093a0')

Also, it seems that not all messages available on web.skype.com are being downloaded to the database, even though they're from 2018-2019...

[suurjaak]

What is that popup error screenshot from?

Note that images sent by bots (at least Zo) don't appear to have their format automatically detected; they're saved as files without extensions, but open fine in MS Paint.

That is interesting. What format does Paint show it as? Could you share one such exported HTML with the image?

Out of curiosity, is there any way to import images from Skype's media caches?

Sorry, I know nothing about that.

SkypeSingleChat(id=u'28:dd02eb70-197a-4dbc-8591-e4e88a5093a0', alerts=True, userId=u'dd02eb70-197a-4dbc-8591-e4e88a5093a0')

Aha, here's the problem. In the old database files, that user ID also started with "28:", but from online they come without it, and thus the duplicate messages are considered to be from different contacts.

I will have to amend the online sync to import or interpret bot messages differently.

---

Also, it seems that not all messages available on web.skype.com are being downloaded to the database, even though they're from 2018-2019...

All messages of known type that Skyperious receives from the online API, it stores, until it reaches messages already present in the database.

If you have identified such a chat, perhaps you could the following:

• open the database and log in to Skype online
• open the chat on the Chats-page
• open the Python console and execute the following

  chat_id = live.identity_to_id(page.chat["identity"])
  chat = db.live.skype.chats.chat(chat_id)
  for msg in chat.getMsgs(): msg

Execute the last statement over and over until it stops returning messages (it returns message history going back in time). If by the end it hasn't reached those messages from 2018 you can see on web.skype.com, then there is nothing to be done.

[unilock]

What is that popup error screenshot from?

It appears after exporting (the latest part of) one of my largest group chats, "The (not) GME", from my newest merged database (for example, from 2018-06-21 to 2021-01-30).

That is interesting. What format does Paint show it as? Could you share one such exported HTML with the image?

Sure, I've added an archive to the MEGA folder of a short excerpt of the aforementioned group chat containing one of the improperly recognized images (or whatever they may be). In doing so, I noticed that Skyperious doesn't output any type of error when trying to export with images while not logged in to your Skype account; maybe there should be a warning or something? (Could've saved me a few minutes, haha.) Also, the relevant images appear properly embedded in the HTML, so maybe it's not such an issue after all. For what it's worth, the broken image in the archive I uploaded appears to be of PNG format (according to Notepad++; I can't find anything about that in MS Paint).

---

Execute the last statement over and over until it stops returning messages (it returns message history going back in time). If by the end it hasn't reached those messages from 2018 you can see on web.skype.com, then there is nothing to be done.

The problem is that I can't download / view some messages in certain chats newer than the latest messages I have for those chats in my local database, that I can view in the Skype web client. The image below should clarify the issue.

Regardless, the commands you sent don't appear to work...

>>> chat_id = live.identity_to_id(page.chat["identity"])
>>> chat = db.live.skype.chats.chat(chat_id)
Traceback (most recent call last):
  File "<input>", line 1, in <module>
AttributeError: 'NoneType' object has no attribute 'chats'
>>> for msg in chat.getMsgs(): msg
...
Traceback (most recent call last):
  File "<input>", line 1, in <module>
NameError: name 'chat' is not defined

[suurjaak]

It appears after exporting (the latest part of) one of my largest group chats, "The (not) GME", from my newest merged database (for example, from 2018-06-21 to 2021-01-30).

Can you do the export again, and then open the log window (menu Help -> Show log window) and copy-paste the more detailed error here?

Sure, I've added an archive to the MEGA folder of a short excerpt of the aforementioned group chat containing one of the improperly recognized images (or whatever they may be).

Aha, it's that the shared file originally did not have any extension. Will make it so that it adds an extension if file type is detected.

In doing so, I noticed that Skyperious doesn't output any type of error when trying to export with images while not logged in to your Skype account; maybe there should be a warning or something?

Good idea, will add a confirmation popup for that.

Regardless, the commands you sent don't appear to work... AttributeError: 'NoneType' object has no attribute 'chats'

I think you neglected to log in on the Online-page? That error occurs if there is no login yet.

[unilock]

Can you do the export again, and then open the log window (menu Help -> Show log window) and copy-paste the more detailed error here?

There doesn't appear to be a more detailed error, unfortunately.

2021-02-20 16:12:10.335 Started application.
2021-02-20 16:12:10.743 Opened \\192.168.1.250\unilock\Archives\Documents\Backups\Accounts (social)\SkypeBackups\FINAL\main.db (17.37 MB).
2021-02-20 16:12:11.225 Conversations and participants: retrieving all (\\192.168.1.250\unilock\Archives\Documents\Backups\Accounts (social)\SkypeBackups\FINAL\main.db).
2021-02-20 16:12:11.284 Conversations and participants retrieved (197 chats, 408 contacts, \\192.168.1.250\unilock\Archives\Documents\Backups\Accounts (social)\SkypeBackups\FINAL\main.db).
2021-02-20 16:12:11.705 Statistics collection starting (\\192.168.1.250\unilock\Archives\Documents\Backups\Accounts (social)\SkypeBackups\FINAL\main.db).
2021-02-20 16:12:11.742 Statistics collected (\\192.168.1.250\unilock\Archives\Documents\Backups\Accounts (social)\SkypeBackups\FINAL\main.db).
2021-02-20 16:12:23.815 Opening group chat "The (not) GME".
2021-02-20 16:13:25.904 Logging in to Skype online service as 'REDACTED'.
2021-02-20 16:13:48.407 Exporting 1 chat from \\192.168.1.250\unilock\Archives\Documents\Backups\Accounts (social)\SkypeBackups\FINAL\main.db as HTML to D:\Documents\gme.html.
2021-02-20 16:13:48.407 Exporting group chat "The (not) GME".
2021-02-20 16:14:18.334 Exported 1,500 messages to D:\Documents\gme.html.

I think you neglected to log in on the Online-page? That error occurs if there is no login yet.

Yep, that was it. I don't get any output from the first two commands now. The last command seems to get stuck on "...", though, even after more than 10 minutes.

[suurjaak]

The last command seems to get stuck on "...", though, even after more than 10 minutes.

Oh - you need to press Enter twice there.

[suurjaak]

Can you try this attached setup: skyperious_4.5.1.dev12_x64_setup.zip, and report how it fares?

It now syncs bot accounts from live using the same identities they had in older databases, so that if you merge previously unmerged databases, the result should be all proper. And it also should be able to handle merging content synced before the fix (but won't fix existing duplicates).

And now you can do command-line merge by skyperious merge *.db my-chosen-target.db - later file-arguments will override previous file-arguments, so you don't have to specify all database files individually.

Unfortunately I cannot test bot accounts myself, as Skype bots are simply not enabled for my country.

[unilock]

With that new version, bot messages no longer appear to be duplicated! Though usernames vary between the bot's username (e.g. "Zo") and what appears to be the bot's UUID (e.g. "dd02eb70-197a-4dbc-8591-e4e88a5093a0"; not too big of an issue.

Image file extensions now appear to be added properly, except for some that just show up as "*.binary", which I can't open in Paint either. Also, in the HTML export, images sent by bots (at least Zo) appear as the first image sent by the bot in the export, despite downloading the correct images in the "*_files" folder.

I'll add an archive of the export with all of the above problems to the MEGA folder. ("The (not) GME export 2.zip")

Regarding the missing messages from LIVE syncing, the messages in question show up in the Python terminal, so it's weird that they aren't synced to the relevant chat in Skyperious. Maybe it has something to do with them being of type "RichText" instead of "Text"...

The messages circled in red are the only messages visible on web.skype.com, and that circled in green is from a previous backup (not from LIVE syncing). It should also be noted that entire chats that are visible on web.skype.com are missing from Skyperious.

And now you can do command-line merge by skyperious merge *.db my-chosen-target.db - later file-arguments will override previous file-arguments, so you don't have to specify all database files individually.

This makes merging databases much easier, thank you.

On an unrelated note, would it be possible to sync nicknames as well as chats from LIVE? Many of my contacts in Skyperious have nicknames that I've since changed or deleted; it would be nice to be able to recogize them by name again.

[suurjaak]

Though usernames vary between the bot's username (e.g. "Zo") and what appears to be the bot's UUID (e.g. "dd02eb70-197a-4dbc-8591-e4e88a5093a0"; not too big of an issue.

Message author's name is taken from the contact's name on sync, and this bot does not appear to have a name set in its Live profile. You can rename the participant, then the displayed name will be what you set.

Image file extensions now appear to be added properly, except for some that just show up as "*.binary", which I can't open in Paint either.

In the shared export, the one .binary file was a video file, and there is no easy way to determine the format. I'll at least change it so that the extensions will be .video or .audio or .image if the precise type is unknown.

Also, in the HTML export, images sent by bots (at least Zo) appear as the first image sent by the bot in the export, despite downloading the correct images in the "*_files" folder.

Oops, that is a bug. Will be fixed.

Regarding the missing messages from LIVE syncing, the messages in question show up in the Python terminal, so it's weird that they aren't synced to the relevant chat in Skyperious.

A ha, I think I might see why. It could be a limitation of the Live API, as the sync operates on asking for recent chats, and continues as long as this provides anything. It could be that the "recent chats" just do not extend beyond a year or so.

I might have to amend it to also try out all other unsynced chats in the database.

What happens if you try to sync this chat only? Click "Synchronize selected chats" and select only this one chat.

On an unrelated note, would it be possible to sync nicknames as well as chats from LIVE? Many of my contacts in Skyperious have nicknames that I've since changed or deleted; it would be nice to be able to recogize them by name again.

The reason it doesn't sync names of existing contacts, is that this would override the current names in the database, which may be the opposite of what the user wants if they have renamed the contacts locally.

Although, maybe there could be a checkbox for that.. "Do not overwrite existing contact information" or the like.

[unilock]

What happens if you try to sync this chat only? Click "Synchronize selected chats" and select only this one chat.

It reports the synchronization as complete without downloading any new messages.

Also, I didn't realize you could use Skyperious to rename contacts/participants locally; that's helpful.

[suurjaak]

Can you try this attached setup: skyperious_4.5.1.dev20_x64_setup.zip?

It now updates existing contact information as well, and checks all older chats for any new messages to sync (with toggles to skip either).

And there's a fix for the issue with images in HTML export.

[rpodric]

So, in general for most situations, the fact that "Do not check older chats" is unchecked suggests that it should be unchecked?

I notice that the tooltip warns that it may take a while, but I assume that's in reference to NOT checking it (because then older ones would be checked)? I may be confused here by the negative phrasing.

Might it be better to put it positively, "Check older chats for messages to sync" and then (I guess) have it checked? Perhaps the same for the neighboring option.

[suurjaak]

The older-chats flag should be unchecked for the first sync, as there may be older messages available online that are not in the database yet. But there's little point in having it unchecked on later syncs, as there is nothing more to receive from those chats.

The contacts-flag should be unchecked for most situations, as I think in general users would prefer having existing contacts to have updated profile information in the database. However, there can be people who prefer existing contacts retain their current profile field values in the database (e.g. if they have changed them locally, or prefer the older profile pictures), so I made it a flag.

Checking for older chats may take a while, yes, since there may be many hundreds in the database, and each will take about a second or more. I have 600+ chats in my database, going through the older ones adds around 5-10 minutes to the sync.

I agree that the negative phrasing may be a tad confusing. I could reverse the logic, I suppose. And add more information to the tooltips.

[suurjaak]

@unilock FYI, since a show-stopping bug #94 appeared, I've issued a new release, v4.6, which incorporates all these syncing changes.

Can you confirm that the syncing is working all properly now?

[unilock]

Oh, I was in the process of creating a new database, synced from LIVE, with skyperious_4.5.1.dev20_x64_setup.zip. It synced the two chats it's usually able to sync (that is to say, NOT the ones that I can view via Python console but that don't sync normally - the "older chats"), then got stuck on "Querying recent chats..." for some time. Here's the log (after cancelling the sync):

2021-03-04 14:21:16.278 Started application.
2021-03-04 14:22:18.813 Logging in to Skype online service as 'REDACTED'.
2021-03-04 14:22:21.938 Creating new Skype database file \\192.168.1.250\unilock\Archives\Documents\Backups\Accounts (social)\SkypeBackups\2021-03-04 [FINAL3.5]\main.db from Skype online for user 'REDACTED'.
2021-03-04 14:22:22.908 Opened \\192.168.1.250\unilock\Archives\Documents\Backups\Accounts (social)\SkypeBackups\2021-03-04 [FINAL3.5]\main.db (0 bytes).
2021-03-04 14:22:23.160 Conversations and participants: retrieving all (\\192.168.1.250\unilock\Archives\Documents\Backups\Accounts (social)\SkypeBackups\2021-03-04 [FINAL3.5]\main.db).
2021-03-04 14:22:23.160 Conversations and participants retrieved (0 chats, 0 contacts, \\192.168.1.250\unilock\Archives\Documents\Backups\Accounts (social)\SkypeBackups\2021-03-04 [FINAL3.5]\main.db).
2021-03-04 14:22:23.238 Starting to sync '\\192.168.1.250\unilock\Archives\Documents\Backups\Accounts (social)\SkypeBackups\2021-03-04 [FINAL3.5]\main.db' from Skype online service as 'REDACTED'.
2021-03-04 14:23:23.949 Error saving message SkypeFileMsg(id=u'1554068562465', type=u'RichText/Media_GenericFile', time=datetime.datetime(2019, 3, 31, 21, 42, 42, 465000), clientId=u'12818021007830239831', userId=u'REDACTED', chatId=u'19:da825a3151454afabd8ce75b8ceb9b37@thread.skype', content=u'').

            Traceback (most recent call last):
              File "live.py", line 745, in populate_history
              File "live.py", line 203, in save
              File "live.py", line 581, in convert
            AttributeError: 'NoneType' object has no attribute 'size'

2021-03-04 14:23:23.952 Error saving message SkypeFileMsg(id=u'1554068552995', type=u'RichText/Media_GenericFile', time=datetime.datetime(2019, 3, 31, 21, 42, 31, 740000), clientId=u'12818021007830239831', userId=u'REDACTED', chatId=u'19:da825a3151454afabd8ce75b8ceb9b37@thread.skype', content=u'').

            Traceback (most recent call last):
              File "live.py", line 745, in populate_history
              File "live.py", line 203, in save
              File "live.py", line 581, in convert
            AttributeError: 'NoneType' object has no attribute 'size'

2021-03-04 14:27:26.734 Error calling <bound method SkypeSingleChat.getMsgs of SkypeSingleChat(id=u'8:REDACTED', alerts=True, userId=u'REDACTED')>.

            Traceback (most recent call last):
              File "live.py", line 183, in request
              File "site-packages\skpy\chat.py", line 71, in getMsgs
              File "site-packages\skpy\conn.py", line 261, in syncStateCall
              File "site-packages\skpy\conn.py", line 237, in __call__
            SkypeApiException: ('400 response from GET https://azwus1-client-s.gateway.messenger.live.com/v1/users/ME/conversations/8:REDACTED/messages', <Response [400]>)

2021-03-04 14:28:59.643 Error calling <bound method SkypeSingleChat.getMsgs of SkypeSingleChat(id=u'8:REDACTED', alerts=True, userId=u'REDACTED')>.

            Traceback (most recent call last):
              File "live.py", line 183, in request
              File "site-packages\skpy\chat.py", line 71, in getMsgs
              File "site-packages\skpy\conn.py", line 261, in syncStateCall
              File "site-packages\skpy\conn.py", line 237, in __call__
            SkypeApiException: ('400 response from GET https://azwus1-client-s.gateway.messenger.live.com/v1/users/ME/conversations/8:REDACTED/messages', <Response [400]>)

2021-03-04 14:38:04.562 Finished syncing '\\192.168.1.250\unilock\Archives\Documents\Backups\Accounts (social)\SkypeBackups\2021-03-04 [FINAL3.5]\main.db'.

I'll try the new version, v4.6, and report back. I was planning on doing a Live sync to a new database, then using that database as the target to merge all the older databases onto, and finally syncing from Live again in case the "older chats" aren't synced the first time.

[unilock]

v4.6 does the same; when initially syncing from Live, it syncs the non-"older chats", then gets stuck on "Querying recent chats..." This does not happen with "Check older chats for messages to sync" unchecked.

I'm in the process of merging the databases now. I'll report back on the behavior of "Check older chats for messages to sync" once the "older chats" are actually present in the local database.

[unilock]

With the merged database, "Check older chats for messages to sync" appears to work correctly -- I see "Querying older chats..." while syncing -- but I still don't see the expected messages in the local database. Also, it doesn't seem that contact names are being updated with "Update existing contact information" checked, either. I've uploaded the merged database along with the non-redacted log to the MEGA folder, if it's any help.

[suurjaak]

Getting stuck on "Querying": this looks to be yet another bug, that occurs when the database has no older chats, e.g. a new database created from sync. Will be fixed in the next release.

Do you mind if I add you on Skype for chatting? Would get to the bottom of these syncing problems much faster.

[unilock]

Feel free, though be warned that it's not my primary venue of communication anymore. I've reinstalled Skype Lite on my phone for the time being. Funny, some of the messages visible on web.skype.com don't show up in Skype Lite, either... (though others do!?)

[suurjaak]

Remaining syncing problems should all be fixed with the new v4.7 release.