Songs purchased through Music Store and placed in my Ubuntu One Storage are not being synced locally

[Jeff Lane ]

I recently purchased two albums on two different dates from the Ubuntu One Music Store via the Rhythmbox plugin.

The first album, HAARP by Muse was purchased, and only 10 of 14 tracks were transferred to my U1 storage space. After that, however, the sync process put the files in ~/.ubuntuone/Purchased From Ubuntu One/ and they appeared in Rhythmbox and ready to go.

The second album, Charlemagne by Christopher Lee, went differently. 12 of 14 tracks were transferred to my U1 storage, however NONE of those has been synced locally. I've tried rebooting and restarting the sync daemon a couple of times, and also messed around a bit with u1sdtool hoping to force a manual sync, but nothing I've tried so far has gotten that new album to sync.

I was able to add things to ~/Ubuntu One and those things were synced from my system to the U1 storage, so I know Sync IS working, it's just stuck for some reason on those songs I am still waiting to download.

[Jeff Lane  (bladernr)]

No love for this? I would really like it if Ubuntu One sync daemon actually performed a full sync and downloaded the full contents of my cloud space...

[Jeff Lane  (bladernr)]

This has gone since 4/12. As of UDS, all the songs purchased have made it over to the cloud from 7Digital. However, one FULL album has yet to be transferred to my local system. The ONLY thing I can do to get the songs is to manually download them via the clunky web UI and that's not fun.

Someone please look at this.

[papukaija (papukaija)]

Thank you for taking the time to report this bug and helping to make Ubuntu One better. We need some more information from you before we can start working on this bug. Can you do the following in order to provide us with important details that will help us determine the root cause of this issue?

   1. Open Applications->Accessories->Terminal and run: echo -e "[logging]\nlevel = DEBUG" > ~/.config/ubuntuone/logging.conf; u1sdtool -q; u1sdtool -c
   2. Copy files into your ~/Ubuntu One folder
   3. Attach ~/.cache/ubuntuone/log/syncdaemon.log and ~/.cache/ubuntuone/log/syncdaemon-exception.log to this bug report

Note that attaching syncdaemon.log will show filenames you are attempting to sync with Ubuntu One. If you do not want this to be public, please mark the bug as private and this bug report will only be available to you and the Ubuntu One team.

[Jeff Lane  (bladernr)]

I'm marking as confirmed for the following reason:

I met up with rye (Roman) at UDS and he was able to fix the issue and explain what the problem was. This is actually a duplicate of another bug, but I do not have the bug number to mark this appropriately. Roman may know what bug this is related to.

The root cause is apparently in the way u1sdtool hashes the directories before syncing. Apparently, what happens in some cases is that the hash is made of the cloud source directory and if the sync fails for whatever reason, it's never started again, until something changes that causes the hash to change. Even trying to force u1sdtool to refresh a subscribed directory fails, as the hash never actually changes.

Roman knows exactly what the issue is, and the very simple fix he showed me was to just touch a placeholder file in the local directory and then restart the syncdaemon. This changes the hash and forces a refresh, and the files then get transferred properly.

I believe he said that this will be fixed in an SRU for either u1sdtool or syncdaemon itself.

Roman: if you see this, thanks again for helping me sort this out at UDS, and for the explanation about what was going on. If you happen to know what bug number is appropriate, could you mark this as a duplicate?

[papukaija (papukaija)]

"This is actually a duplicate of another bug, but I do not have the bug number to mark this appropriately" - Sorry, dupplicate bugs are closed. Please add the bug number if you find it.

[Jeff Lane  (bladernr)]

Duplicates are not always marked as closed.

In any case, I found the master for this, marked it and remarked as confirmed as it is in fact confirmed, duplicate or no. Please let it be, and all updates will now take place within the master bug.