I have tried a two-way sync with alterations on both my Windows 10 Laptop and Android device with version 2.1.9.0. With 100 songs, it was very quick and worked beautifully in both directions!
(06-01-2018, 04:56 PM)Zuberman Wrote: I've uploaded new builds for Android and Windows 10. Use the same links I provided for the first releases. A log.txt file will be generated in the storage location for both versions. Users that are having issues should email me the log.txt files so I can try to figure out where the problems are. I may need users to help provide library backups that demonstrate some of the issues if I'm unable to find any problems in the log files. These new builds don't have the progress bars - I can work on adding those next.
Mike
Thanks, this version installs and runs on Windows 10 for me. Now for the testing...
Thanks for letting me know John. It seemed a number of testers have been encountering errors, so it's nice to hear that it's working correctly for you.
The synchronization relies heavily upon MobileSheetsPro running on both the server and client and logic that is executed by MobileSheetsPro on the data in the libraries. If you run a client on linux, you will have to read out the songs, files and audio files from the database at a bare minimum. The expectation is that the client has access to all of the files linked in the database. Is that how you have everything set up on your linux box (i.e. the storage location matches a folder that is also in used on your device)? Otherwise, I don't see this working. It might be best if you email me about this, or we start a separate thread.
06-03-2018, 05:42 AM (This post was last modified: 06-03-2018, 05:48 AM by sciurius.)
I tried to setup a sync.
System "asus" is server and has a full database with songs. Storage settings are default.
System "moto" is client and has an empty database. Storage settings are default.
Systems connect and sync starts, but stops after a short while with "Connection error encountered. Transfer has failed.". Data on "moto" is unchanged (still empty database).
Note that sync tries to update metadata on the server, it may fail on attempting to do so.
Zip log-1.zip with client and server logs attached.
System "note" is server and has a full datatbase. Storage settings are custom. Sync is set to update client.
Systems connect and sync starts, but stops after a short while with "Connection error encountered. Transfer has failed.". Data on "moto" is unchanged (still empty database).
I ran "logcat" on system "note" (it is rooted) but no messages appeared in the log.
Zip log-2.zip with client and server logs attached.
What worries me is that sync still updates metadata in the server, even though it was set to update the client only...?
System "note" is server and has a full datatbase. Storage settings are custom. Sync is set to update client.
System "asus" is client and has a full database with songs from an older backup. Storage settings are default.
Systems connect and sync starts, but stops after a short while with "Connection error encountered. Transfer has failed.".
Zip log-3.zip with client and server logs attached.
The new build seems to work a bit better for me. I'm still testing the Android build for now and tried to sync from my tablet (Sony Xperia Z4 with 7.1) to my mobile (Sony Xperia Z1 with 8.0).
My songfiles are identical on both devices with just the number of the SD card different in the path. Just a day before I "synced" my database manually by copying the db from my tablet to the mobile and corrected the path with your utility in the settings. There was just one difference (or should be) between both libraries and this is a new setlist.
I set up tablet as server and mobile as client and started a sync.
The transfer of the database worked (and was reported to be saved with temp extension in a cache directory).
Then it started to merge which seemed to kinda work too (it didn't stop at the 8th file this time). But as Sciurius I'm not sure what it is doing and merging.
I choose to ask the user for action and I got for each file the comparison table (for which I think an option to continue with one of the three choices without prompting is seriously needed).
But I don't know what it was actually doing. I don't know why it prompted because there should be no difference in the songs and the song data which needs to be merged (especially not with the sever data). I chose skip to continue.
Also the comparison table showed the exact same data for the prompted songs. Even the path was show as the same on both sides (the path of the directory on the server device actually)
(I don't think that's a remnant of my path correction of the client db).
I expected MSP to compare but to recognize there are no differences. Or does it try to adjust all the paths in the synced db anyway since it's from the other device? That's not clear from the messages and the comparison table.
Also, where do I find the log files, if you want to see them?
The logfiles are in the data location, usually Android/data/com.zubersoft.mobilesheetspro/files on your SDcard.
MSPro "Import Local File" should be able to show it.
When was the last time you downloaded the APK file Johan? I've been making updates periodically as issues are reported. I don't really have a great way to bump the version without potentially causing issues when it's time for a real release, so I'm trying to avoid that. I could start putting the version on the APK file itself, and then post the latest installer version here if that's easier. In previous versions of the beta, if a file needed to be transferred that didn't exist on one of the devices, it would cause the whole sync to fail. This has since been fixed, so I just want to make sure that isn't the reason your sync was failing.
Are you saying you want a "Skip All" or "use this action for all further conflicts" kind of thing in the merge dialog? I could certain add a skip all option, but then that's no different than using the option to only sync new songs and groups. If I add a "use this action for all further conflicts" kind of setting, I don't think people realize the impact of doing that. It could result in a lot of changes being lost because they would be modifying songs using potentially outdated data. That's why the default option is to use the last modified timestamp. Also if someone accidentally clicked the option to use the action for everything and then wanted to cancel, the merge might finish too quickly for them to cancel. If everyone agrees that they want this kind of option, then I will add it, but I want to hear more feedback first.
As far as there being no differences between songs, yet the merge dialog being shown, can you take a screenshot of that occurring? I wish I had the same library to test with, but I'll have to suffice with as much information as you can provide. If the conflict was for files, and not for song metadata, that could occur if the calculated file hash was different on each device, meaning the bytes of the files were different in some way (even if the size was identical). If a file was missing on one device, this would happen as well.
06-04-2018, 05:27 AM (This post was last modified: 06-04-2018, 05:29 AM by Zubersoft.)
Okay, thanks Johan. I'll have to see if I can reproduce the issue you are seeing with the server metadata actually being modified in a one-way sync. Did you actually verify the song was modified? It's possible that the merge message was printed, but my logic didn't actually make any modifications after that.
Looking at this log, it appears you have multiple songs both named "As I Roved Out". Is that true? I'm guessing there is something faulty in my logic when there are multiple songs in the library with the same title. The problem is that, I need to have a way of determining if a song from one tablet exists on the other tablet, and I can't rely on the database IDs, because those are most likely different (especially if users with different libraries are synchronizing to each other). So what I'm doing to try to find a matching song is I first look for a matching title, then I try to look for a matching file with the same name. If multiple songs with the same titles and files are found, my logic will look for a matching database id. If one is found, that song is used, otherwise the first match is used. If I can't find a song with a matching title, I look for a song with a matching database ID and creation date (in case the song was renamed). So I'm guessing something in there isn't working well if you have multiple songs with matching titles and files.
Thanks,
Mike
UPDATE:
I just looked through the logic, and I do print out the message that I'm updating the metadata on the server, but then I take no action if it's a one-way sync. I'm modifying this to only print out the message if action will be taken.
>Are you saying you want a "Skip All" or "use this action for all further conflicts" kind of thing in the merge dialog?
Yes. Because otherwise I'm stuck with choice for the whole sync even if decided after checking the first ones to skip the rest or just merge the server data and so on.
>I could certain add a skip all option, but then that's no different than using the option to only sync new songs and groups.
True. But again, if you have lots of data to merge and want just to check a few at first and decide after that how to go on ...
>If I add a "use this action for all further conflicts" kind of setting, I don't think people realize the impact of doing that. It could result in a lot of changes being lost >because they would be modifying songs using potentially outdated data. That's why the default option is to use the last modified timestamp. Also if someone >accidentally clicked the option to use the action for everything and then wanted to cancel, the merge might finish too quickly for them to cancel. If everyone >agrees that they want this kind of option, then I will add it, but I want to hear more feedback first.
Well, the same danger is there if you choose the wrong merge option from the beginning. Don't get too "Microsoft" here and trust your users to know and to check what they are doing. But I agree, on the safe side a warning "do you really want to ..." might be in order.
>As far as there being no differences between songs, yet the merge dialog being shown, can you take a screenshot of that occurring? I wish I had the same library >to test with, but I'll have to suffice with as much information as you can provide. If the conflict was for files, and not for song metadata, that could occur if the >calculated file hash was different on each device, meaning the bytes of the files were different in some way (even if the size was identical). If a file was missing on >one device, this would happen as well.
I will make screenshots the next time. I can upload my library again, too (and look for the logs in the dir Sciurius mentioned).
When I canceled the last sync I noticed that the new setlist from the server was now in the database in the client. Also all the paths of the server were in the client (though this could still be from a previous try of the beta). I adjusted the paths before trying to sync, so I'm not quite sure which steps the sync did.
My main use will be to sync from a master tablet to slave/clients and usually make all the changes on the master tablet (while keeping the sheets directories in sync with other appz). So it would be nice and a time saver if there would be an option to restrict the sync just to copying the database and fix the paths according to the folders in the setting?
Yes, in my setup it is quite common to have multiple songs with identical names. Usually they belong to different collections. For example, same song with a different arrangement, or different key.
(This is one of the reasons I'd like to have the 'separate database' feature.)
(I can also feel another feature request coming: to sync collections and setlists. But first things first.)
(As usual you can have an msb of my setup if that would be helpful.)
