[sciurius]

I have synched my library to a cloud (Drive) folder.
I've made some updates on the tablet.
I perform a library sync: Update server, all options checked, query user.

For the locally updated files, I get the mine/theirs dialog, and I choose "Mine".

When the synch finishes, the database is updated on the Drive folder, but no song files are transported. The hashcodes file is also untouched. Not surprisingly, a subsequent run of the library sync asks for the same files to be updated (and doesn't update them).

Analysis: There are 4 .cho files and 8 .pdf files involved.

The offending .pdf files are in the cloud folder with size zero (I don't know why, but that shouldn't matter), which is also reflected in the hashcodes files.
The mine/theirs dialog shows mine with the real size, and theirs with zero size. Even though I choose "mine" nothing happens -- no file is uploaded and its entry in the database and the hascodes files is not modified.

For the .cho files, the existing entry in the Files table is removed, and a new entry is made with exactly the same contents. So the only thing that actually changes in the (uploaded) database is the Id in the Files table.

HTH

[Zubersoft]

Is that with version 2.3.2? There were some fixes related to that one of the last updates (might have been v2.3.1) and it required reuploading your library to Google Drive in order for the hashcodes to be correctly calculated and uploaded.

[sciurius]

All tablets run 2.3.2.

Tablet A uploads to an empty cloud (GDrive) folder.

Tablet B syncs to this folder (update client). A number of songs/files need update.

I re-run the synch on tablet B, the same songs/files need update again, their values are still the old values.
Inspection of the Android/data/com.zubersoft.mobilesheetspro/files/ shows that these files are not updated, even though the synch process claims it did.

Update: Even though the synch is set to update the client only, sometimes the database on the cloud folder is modified. Worse: once the activity log showed that the tablet did upload the changes to the cloud folder, instead of the other way around.

I'm more puzzled than ever.

[sciurius]

New test round.

Create new Google Drive folder.
Sync tablet A to cloud folder: Initial upload, completes normally.
Apply several corrections.
Sync to cloud folder: Update server.
- file deletes are propagated to the server
- the other updates (merges) are not

Tablet B has an older copy of the library.
Sync tablet B to cloud folder: Update client. Do not search for new files.
Crash on NullPointerException comparing song XXX.
There was XXX.cho and XXX.jpg, and XXX.jpg was removed from the server.

EDIT: Some songs that were on tablet B and not on the server appeared on the server again, so the cloud folder was updated despite the "Update client" setting.

[Zubersoft]

Thanks for the details, I'll investigate the exception as well as the cloud folder being modified when it shouldn't. I believe I'm currently always uploading the database at the end (if that is what you are referring to).

Mike

[sciurius]

No, it is real song files that are uploaded to the server.

[Zubersoft]

Johan - I just realized that the wording in the dropdown may have confused you. When you sync to a cloud folder, the device is the server and the folder is the client. I'm changing that wording in the next update so that it reads "Update Device" and "Update Folder" so it's clearer which is which. That may explain what you were seeing. I will still try to track down that exception though.

Mike

EDIT:
Johan, how did you have a chord pro file with a jpg at the same time? That isn't supposed to be allowed.

[sciurius]

When you sync to a cloud folder, the device is the server and the folder is the client.

OOPS! That may, indeed, be the explanation of quite a few problems I experienced.

I'm changing that wording in the next update so that it reads "Update Device" and "Update Folder"

Great. That will surely prevent some confusion.

how did you have a chord pro file with a jpg at the same time? That isn't supposed to be allowed.

Two different songs with the same title. One that has the .cho and the other has the .jpg.
When comparing by song title this may have confused the algorithm?

Thanks for you on-going support!

[Zubersoft]

Figured out the exception, so thanks again.

Mike