You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I found a working workaround, yet I'm still submitting this report.
In case someone else has the same issue or if there is some simple fix that can be implemented this can be used as base for discussion.
Baikal version:
0.9.2 using MySQL database
PHP 8.1
Expected behaviour:
When I perform a sync on Thunderbird (v102) I expect new entries to be synced and show up in the calendar.
The entries are exist in the database and have been created since the last sync.
Current behaviour:
On clicking sync in Thunderbird a request with a sync ID is send to Baikal but the response does not contain any calendar entries to be fetched.
A sync from Thunderbird (v102) to Android client using DAVx5 is working.
A sync from Android client using DAVx5 to Thunderbird (v102) is not working.
A sync from an Thunderbird (v102) to another different Thunderbird (v102) client is not working.
DAVx5 seems to access Baikal differently than Thunderbird.
Thunderbird can access Baikal, but only "one way"
Workaround:
After digging around in the database I figured out that the synctoken values might be not in sync with the calendar changes.
Purging the calendarchanges table of all entries and setting the synctoken in the calendars table to 1 for each calendar entry did solve this issue. Afterwards the calendar must be resubscribed in order to get the updated synctoken.
On the old table before the purge the sync token was at 500 (SELECT synctoken FROM calendarsWHERE id = 2) but the highest synctoken for this calendarchanges was 943 (SELECT synctoken FROM calendarchanges WHERE calendarid = 2 order by synctoken desc limit 1)
Steps to reproduce:
On a fresh Baikal version this seems reproduce the issue:
Setup a new Baikal instance with one user and one calendar
Manipulate the synctoken in the calendars table to a high starting value (e.g. 100)
Then subscribe to the calendar in two different Thunderbird instances
Then Manipulate the synctoken in the calendars table to a lower value (e.g. 50)
Thunderbird will use the to high synctoken in the request
Baikal will not yield any calendar update response
I do not know what exactly caused this issue I started noticing this only after the recent update of Baikal from 0.7.1 to 0.9.2
The text was updated successfully, but these errors were encountered:
Did you try just to Unsubscribe / Subscribe?
It seems, at least for now, to do the trick for me.
I'm running 0.9.2 too but on SQLite and issue was with TB 102.9.0.
Edit!
I can confirm, after doing the unsubscribe / subscribe on all my running TB, it works as intended now.
Yes I did. See my steps to reproduce.
I setup a fresh local baikal + portable thunderbird.
Loaded in my existing calendar data and connected the two.
Any unsubscribe and resubscribe the issue was still there with syncing any new created items from outside.
The only solution was to manually reset of the calendarchanges table and resetting the synctoken.
If I understand the database this data is not really required as the actual calendar data is stored in a different table.
Since this change everything works again.
I found a working workaround, yet I'm still submitting this report.
In case someone else has the same issue or if there is some simple fix that can be implemented this can be used as base for discussion.
Baikal version:
0.9.2 using MySQL database
PHP 8.1
Expected behaviour:
When I perform a sync on Thunderbird (v102) I expect new entries to be synced and show up in the calendar.
The entries are exist in the database and have been created since the last sync.
Current behaviour:
On clicking sync in Thunderbird a request with a sync ID is send to Baikal but the response does not contain any calendar entries to be fetched.
DAVx5 seems to access Baikal differently than Thunderbird.
Thunderbird can access Baikal, but only "one way"
Workaround:
After digging around in the database I figured out that the
synctoken
values might be not in sync with the calendar changes.Purging the
calendarchanges
table of all entries and setting thesynctoken
in thecalendars
table to 1 for each calendar entry did solve this issue. Afterwards the calendar must be resubscribed in order to get the updatedsynctoken
.On the old table before the purge the sync token was at 500 (
SELECT synctoken FROM
calendarsWHERE id = 2
) but the highest synctoken for this calendarchanges was 943 (SELECT synctoken FROM
calendarchangesWHERE calendarid = 2 order by synctoken desc limit 1
)Steps to reproduce:
On a fresh Baikal version this seems reproduce the issue:
synctoken
in thecalendars
table to a high starting value (e.g. 100)synctoken
in thecalendars
table to a lower value (e.g. 50)synctoken
in the requestI do not know what exactly caused this issue I started noticing this only after the recent update of Baikal from 0.7.1 to 0.9.2
The text was updated successfully, but these errors were encountered: