06-30-2019, 04:03 PM (This post was last modified: 06-30-2019, 04:03 PM by Zubersoft.)
I will look into ignoring the case when one song has the default values for those fields and the other song has no values at all (which is the same as the default values).
As far as the second screenshot, it looks like you may have two separate keys called "E". Please enable the keys tab or check the keys dropdown to see if E shows up multiple times on each tablet. If so, then that merge is due to MS not knowing which "E" key to add the song to as each tablet is using a different "E".
That will definitely make it more difficult to determine what the cause of the problem is. I'll try importing a .cho file and assigning it to E on two devices, then sync them and see if I see that same behavior.
07-03-2019, 12:42 PM (This post was last modified: 07-03-2019, 12:44 PM by Zubersoft.)
Looks like the second issue is because the songs are transposed to the same key, but their original key is different. It would be great if you can verify that, as that is the only explanation that makes sense. I have a fix in place for the first issue as well. My plan with the second issue is to show the original key and the transposed key such as "C -> E". Hopefully that makes sense. That avoids having to add any translation entries.
The ChordPro file has {key: Em}. The metadata says "Em". In the title string, %KEY evaluates to "Em".
When I call up the Transpose dialog, it says that the key is "E" (or "C#m"). The "Set Starting Key" button shows "G".
Table KeySongs associates this song to KeyId 14 (which is "Em").
Table TextDisplaySettings for this song has Key = 22 ("Gm"???), TransposeKey = 6.
Synching is to a cloud folder, in the cloud the values are the same except for TransposeKey, which is -1 .
I must have changed something -- the merge dialog now displays MINE = "G", THEIRS = "E". Still strange.
With the current logic, the TransposeKey being different between the two would trigger the prompt. The TransposeKey is used to figure out whether sharps or flats should be used, so if they are different you could see a difference with the transposed chords. I'm curious how -1 was stored on the cloud, as that shouldn't have happened. Would it be easy for you to run a query on the database in the cloud to see if -1 is stored for the TransposeKey for any other songs? I can also take care of this if you send me the database (don't want to give you any extra work).
Results for the current database (on device as well as in the cloud):
sqlite> select count(*) from Songs;
1607
sqlite> select count(*) from Songs,TextDisplaySettings where Songs.id = TextDisplaySettings.SongId and TransposeKey < 0;
554
It seems that all songs that were added but never involved in a transpose have TransposeKey = -1. Isn't this just the default value?
But I also noticed that I have 373 entries in TextDisplaySettings for existing songs that refer to non-existent files. Sometimes even multiple, e.g.
(File 1930 exists, but 14410 does not.)
Must I be afraid I have a serious database corruption, or has there been a time where removing files did not remove the corresponding TextDisplaySettings entry?
I have manually added foreign keys to the tables and enabled foreign key checking, and it only seems to be so for the TextDisplaySettings. All other tables check ok.
Yes, you are correct, -1 is the default. So the question is how did one of your songs get a different value for that than what is in the cloud? There must be an explanation for that, but I'm not sure how to reproduce it at the moment.
There was a bug in previous versions where text display settings were not correctly deleted from the database under certain circumstances. I am going to run some tests today to verify that they are correctly deleted from the database in the latest version.
Create a new song, "Test", key Em. Transposekey is now -1. Synch to cloud.
Transpose one up; transpose one down. Transposekey is now 0. Synch to cloud.
Merge dialog asks to choose between Em and Em.
That will do it. I will add logic to account for that and ignore it.
I have also discovered a few ways to reproduce the problem with TextDisplaySettings being left in the database. If you edit a song using a chord pro file, remove the file and replace it with a blank page or PDF, the text display settings will be left in the database. Likewise, if you use the swap file feature to replace a text or chord pro file with an image or PDF, the text display settings will be left behind. I am going to work on fixing all of these scenarios that result in entries being left in the database. I haven't thought of any other scenarios yet, but I probably should test with the companion application as well to verify no entries are left behind when using that.
Great. I assume it is no problem removing these? I have a database checking program that signals this (and many other potential problems) in the database. It can make it optionally fix things like stale entries in the TextDisplaySettings table.
I came across another funny thing using a variant of the above scenario.
Create a new (empty) library (for the sake of fast synching).
Create a new ChordPro song, and fill it with {title}, {key} and some lines of lyrics, all ASCII. Save.
Synch to a new cloud folder, creating the folder.
Transpose one up; transpose one down.
Synch to a new cloud folder, updating folder.
The merge dialog shows the same key Em on both sides, but a different encoding.
07-06-2019, 04:45 PM (This post was last modified: 07-06-2019, 04:45 PM by Zubersoft.)
There is no problem at all with removing the entries. I encountered the encoding difference as well when synchronizing between two devices. I'll try to get to the bottom of it.
.