No synchronsation
Since around 10:30 this morning Astiga refuses to synchronize. I've added a few extra files after the last synchronisation (which finished 10:27 according to logs) during the day (varying between 3 and 1 hours ago so at least some should have been picked up by the automatic hourly synchronisation), but they're not getting added and the log shows the last synchronization finished 10:27.
Trying to manually synchronize results in the page opening saying that it'll synchronize (so no message it's busy), but nothing happens. The old log stays in place where it normally disappears in favour of generating a new one, and nothing get synchronised.
Comments
Update. I just got an email saying it finished synchronising but no songs are added. The log is updated, however. According to the new log, it grabbed the folders but didn't add the files for unknown reasons. It are basic and working MP3 files however so I'm not sure why.
Another update. It seems the issue is fixed. Not sure what caused it tho.
Hi @Cambionn - we did have high memory usage at that time on the server. In the logs, do they show the sync completing after grabbing the folders, or does it look like the sync was ongoing?
When you say it seemed to fix itself, is that with no obvious change to the log files?
At the first update comment, it said completed (last log output: "2021-08-31T12:24:11 END 2021-08-31 12:24:11").
Interestingly enough, that log is still the latest. So there is no log of actually adding the songs, despite them being added by now. So yeah, it seems fixed without obvious change in the log files. I'm not sure how I can see more than the latest log tho. I don't know the exact moment it got fixed, but I first noticed the songs being added around 16:45 when I was just heading home from work.
That's odd - the same start and end time. I can see the latest refresh in the database was between 13:11-13:20 - I can see this just traversed your existing folders and didn't add anything.
It's getting worse. Some files I added and changes I made in my folder structure in OneDrive last Friday still aren't synchronised by now (Sunday) despite hourly synchronisation being turned on. A regular manual synchronisation also isn't fixing it. Just ran manual, which simply logs:
But the files still aren't added. I also tried the full resync option which normally goes by every file and folder, but even that simply returns:
Considering it's been about 2 days now since I added the files and changed folders, I'm guessing it's not some simple high memory usage thing this time?
I have the same issue - my log looks the same as above.
Deleting and re-adding my storage seems to have fixed it for the time being.
Ah - this might be due to the ownership transfer again. As part of this, we had to register a new OneDrive 'app' that connects to the OneDrive storage. The way this works is that an authentication "token" is created when you delete/re-add the storage (I think it should also work if you simple edit the storage, click Get token, copy and paste it in and then Save).
Can you all double check that's working? Thanks.
I think it should also work if you simple edit the storage, click Get token, copy and paste it in and then Save
Yes! This is enough indeed, thanks!!
Interesting that it can still play the files gained from the old "app", but not synchronize again. I mean, on a non-public OneDrive folder you would think playing files and finding new files would be similarly protected, but apparently there is a difference ┌(゜゜)
I am also a bit surprised because I thought the token would continue to work. Initially I thought that it might be that it expired, but as you say I don't see why there's the disparity. It might relate to the sync code being a bit different...
Looking at my Microsoft account, an Astiga last used Sunday is set as "play.asti.ga", while the other is set as used today is set as "unverified". The terms also differ, as the privacy policy of the one that says "unverified" starts with:
These terms of service (“Terms”) apply to your access and use of Astiga (the “Service”) operated by elsten software limited, located at Unit 4934, PO Box 6945, London, W1A 6US, United Kingdom. Please read these terms carefully.
So I'm guessing the need to get a new token has to do with legal reasoning, as the owner is in the terms of the permission. We gave Koen permission, but not you after all. I guess that way, Microsoft protects you from permissions being bought over which could cause privacy issues.
As you say I don't see why there's the disparity
Based on this, my best guess is that old files could still play because the permission for Koen was still in my Microsoft account, and that because I accessed those files through the permission to him already during synchronizing that link stuck. Either that, or either Microsoft or your code doesn't want your permission per se, just a permission. But that synchronization didn't work, because either Microsoft or your code wants to access the drive through your permission specifically which is blocking that until getting a new token. But that's just an educated guess, since I have no clue about the actual code of either party of course.
I just deleted the old permission to Koen. As expected, the already synchronized files are also reachable with your permission without a resync. For the sake of keeping their permissions set only to those who should actually have them, I would recommend OneDrive users (and other services with similar structures) not only add a new token, but also to take a moment to go to their Microsoft account and delete the old one. That includes you @davvvd ;). Handily, Microsoft sends you an email with a link to your connected apps where you can do this right after adding a new token to Astiga.
Thanks for that @Cambionn .
Looking at my Microsoft account, an Astiga last used Sunday is set as "play.asti.ga", while the other is set as used today is set as "unverified".
This is annoying, because some of the delay on this has been to make sure we are counted as "verified".
I just double checked my own records, and I also see two Astiga apps. I'd never added the old integration when Koen was running things. For the most recent one, "play.asti.ga" appears, with the new terms and conditions. But I also had another app too, marked "unverified", with the same terms. I removed that one from my own personal account, and Astiga still works for me.
There might have been a complication in that, at one stage, there were two app "registrations" being developed. But AFAIK the secondary one was not exposed to end users.
For me the URL to manage apps is: https://account.live.com/consent/Manage .
This is annoying, because some of the delay on this has been to make sure we are counted as "verified".
For the sake of testing, I removed all permissions to Astiga and added a new token. Only the "unverified" one appears back I fear. Perhaps the wrong one got exposed to end-users, and the verified one didn't?
I fear I removed the play.asti.ga one before I thought about checking the terms for clues about what and why, so that that one is Koen's is just a guess based on the fact I've used Astiga for a long time when he owned it thus there should be one from him. I can't guarantee that my play.asti.ga one was the same as the one you have.
It's also interesting that the play.asti.ga one was last used Sunday, while I've listened to music on my way to work before I added a new token today, so it seems the (other, likely also the new) token only got "used" while synchronizing (which I did last Sunday before making my post). Perhaps once synchronized, the whole token isn't used anymore for listening? Adding that to previous findings I guess my first theory that the permission to access files stays open after synchronizing might have a sense of truth to it. That would also explain why music already synchronized kept working.
For me the URL to manage apps is: https://account.live.com/consent/Manage
Yup, the same page I'm looking at, and the same as the Microsoft mail redirects to.
I removed all the Astiga tokens from my MS account and readded it, and once the sync gets a few thousand tracks in, I get this set of errors in the log:
Then a few dozen tracks later it picks back up, but the tracks that received this error don't get added.
FWIW I've removed the old app registration.
I think I maybe have not completed the deployment of updated code within the Astiga synchroniser, though. I have now, best I can tell. Can you both give synchronisation another go?
I can see both of your records are correct in the database, so you aren't doing anything incorrectly, to be clear.
It looks like my current sync got stuck and won't respond to the stop command.
Sync is not working for me since yesterday. I have checked my Pcloud is allowing Astiga access a couple of times and obtained/input the token into Astiga.
I can play but not sync. I use Astiga everyday and have not been able to sync since yesterday afternoon UK time.
@Coyley (this is a different issue as far as I can see) I can see on the 12th there were messages about revoked tokens and an incorrect password.
Yesterday, these errors are repeated:
Sounds like that's surprising to you, if you re-established the token?
Ah, but it looks like there was another issue on the synchroniser. Hopefully I cleared that up - can you test (both of you?)
Thanks. Yes I had sorted the token. Sync has just worked fine. Thank you.
😅
My sync also seems to be going through correctly now.
I haven't had issues synchronizing. But for what it's worth, I removed the permission and added it again. I noticed that during the process, Elsten is listed as a verified party I'm giving permission, but on the Microsoft website it's still listed as unverified.
Synchronization works just fine here, all my files are in my library.
I will say I've had the:
followed by the failed message a few times before, but it always fixed itself over time so I never paid too much attention.
But for what it's worth, I removed the permission and added it again. I noticed that during the process, Elsten is listed as a verified party I'm giving permission, but on the Microsoft website it's still listed as unverified.
That's useful, thanks. Can you give me a URL to where you see _unverified_? I want to try to replicate with a personal account I have - currently it shows "play.asti.ga" which I believe is what it should say when it is verified.
One quick positive report - syncing is really fast since the change. Thanks.
Thanks!
Hi,
I am having the same sync issue between Astiga and pCloud. The automatic and manual attempts come back with a failed connection error message on Firefox.
It has been ongoing for 24 hours or so. I cannot even download logs to see when it last ran properly. I am just going by what the last files that I can see. I tried to use a new pCloud token but the issue persists.
I switched off all the adblockers and HTTPS addons just in case.
I managed to run a sync again, but it looks like it is a historical one relating to the issue.
Here is where the issue starts and it ends 3 mins later after a series of failed attempts. At first I thought it might be a naming convention but other ogg files with the same convention have synced across with no issue.
Seems to have resolved.
Thanks.