No synchronsation

CambionnCambionn Member

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.

  • gravelldgravelld Administrator

    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?

  • CambionnCambionn Member
    edited August 31

    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.

  • gravelldgravelld Administrator

    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.

  • CambionnCambionn Member
    edited September 12

    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:

    2021-09-12T09:57:15 START  2021-09-12 09:57:15
    2021-09-12T09:57:15 GET    /Astiga
    2021-09-12T10:00:16 END    2021-09-12 10:00:16
    

    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:

    2021-09-12T10:06:37 START  2021-09-12 10:06:37
    2021-09-12T10:06:37 GET    /Astiga
    2021-09-12T10:09:37 END    2021-09-12 10:09:37
    

    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.

  • gravelldgravelld Administrator

    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 ┌(゜゜)

  • gravelldgravelld Administrator

    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...

  • CambionnCambionn Member
    edited September 13

    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.

    Post edited by Cambionn on
  • gravelldgravelld Administrator

    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.

  • davvvddavvvd Member
    edited September 13

    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:

    2021-09-13T13:28:44 F_ERR  AADSTS70000: The provided value for the input parameter 'refresh_token' or 'assertion' is not valid. The token was issued for a different client id
    Trace ID: 9ec025a6-bd97-476c-9a58-eb1d9f9a6701
    Correlation ID: bd608287-c73a-4ef1-9753-91eb4ffd722c
    Timestamp: 2021-09-13 13:28:44Z
    2021-09-13T13:28:44 FAILED Music/Music/bis/Return to Central (Deluxe - 31 tracks)/11 A Portrait from Space.mp3
    2021-09-13T13:28:44 ERROR  This file does not appear to be an audio file
    2021-09-13T13:28:44 F_ERR  AADSTS70000: The provided value for the input parameter 'refresh_token' or 'assertion' is not valid. The token was issued for a different client id
    Trace ID: 8302aca4-91de-41f8-92f8-581c1d5d7900
    Correlation ID: fe45b18e-3719-4d35-8128-a8a905a30de9
    Timestamp: 2021-09-13 13:28:44Z
    2021-09-13T13:28:45 F_ERR  AADSTS70000: The provided value for the input parameter 'refresh_token' or 'assertion' is not valid. The token was issued for a different client id
    Trace ID: 02538181-b26a-4867-b401-770353c36a00
    Correlation ID: 55f5ebec-d914-4ad7-b54a-441785b9441e
    Timestamp: 2021-09-13 13:28:44Z
    2021-09-13T13:28:45 FAILED Music/Music/bis/Return to Central (Deluxe - 31 tracks)/12 Don't Let the Rain Come Down [Bonus Track].mp3
    2021-09-13T13:28:45 ERROR  This file does not appear to be an audio file
    2021-09-13T13:28:45 FAILED Music/Music/bis/Return to Central (Deluxe - 31 tracks)/13 Make It Through [Bonus Track].mp3
    2021-09-13T13:28:45 ERROR  This file does not appear to be an audio file
    


    Then a few dozen tracks later it picks back up, but the tracks that received this error don't get added.

  • gravelldgravelld Administrator
    edited September 13

    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.

  • CoyleyCoyley Member
    edited September 14

    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.

  • gravelldgravelld Administrator

    @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:

    Your pCloud password or token is incorrect
    

    Sounds like that's surprising to you, if you re-established the token?

  • gravelldgravelld Administrator

    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.

  • gravelldgravelld Administrator

    😅

  • 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:

    ERROR  This file does not appear to be an audio file
    

    followed by the failed message a few times before, but it always fixed itself over time so I never paid too much attention.

  • gravelldgravelld Administrator
    edited September 15

    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.

  • gravelldgravelld Administrator

    Thanks!

Sign In or Register to comment.