Hey guys, just installed Thunderbird on my desktop because I need a email/calendar solution.
I’ve setup my @e.email address just fine, but the tutorials for syncing contacts and calendar don’t work.
Contacts won’t validate the url for the ecloud file even though the log in info is correct.
Calendar connects to the e account, but does not download any appointments nor can it write new ones.
The built-in CalDAV / CardDAV has never worked for me. I use TBSync addon in Thunderbird which handles /e/ calendar and contacts with no problems.
Oh that’s great! Thanks for the tip.
For me the calendar sync works fine (TB 78.10, ubuntu)
For contacts, I find CardBook works very well.
While on the subject of Thunderbird + ecloud, another useful plugin is the Nexcloud file link
I have been struggling for a while to get Thunderbird to synching properly with the ecloud contacts. At the end I found out that it was dead simple. The standard Thunderbird Addressbook works perfectly fine.
However the trick was to copy the right URL into the field “location” during setup. In the above and also in other posts it is suggested to copy the complete URL from the ecloud/contacts page into the setup dialog. However I had to strip some parts of the end of the URL. In my case I had to paste just the base URL part “https://murena.io/remote.php/dav” into the Addressbook setup wizzard.
this together with the right username (xxx@e.email) and password made it work at the end.
Hope it will help others to hear the default address book works fine. I didn’t try it but I guess the same approach would work for cardbook too.
The advice from the last 2 postings by @ewblen (syncing Contacts with CardBook) and @cliffi30 (syncing Calendar with native Tbird CalDAV calendar management) has also worked for me to sync both Contacts and Calendar on Thunderbird.
In fact this is saving my workflow since the UI for both of these Tbird integrations is far more useful than what’s currently available via the web UI on murena.io.
I have been using this for several years: my contacts, calendar and tasks in murena.io and using the interface of Thunderbird on the PC.
Since two weeks there is a major hiccup: some changes in murena.io (and on my mobile) are not synced with Thunderbird, those events are left behind there in an outdated state.
Anyone else has this experience?
Thanks!
I’m still at the same platform above after an additional year, with 1 new device added to it, and everything has been working continuously up through this moment except for some 2-hour Murena server downtime periods.
All but one of these was reported in advance but I think the last one… probably the one 2 weeks ago… might not have been: I remember there was something unusual about that announcement. But since the end of that downtime window everything has been working as before.
I don’t always see immediate sync when I change something on the mobile calendar & often have to push it out to see it on Murena calendar. But this happened before the /e/OS software updates and on AOSP before that. There’s a Refresh button on the default Calendar app that syncs explicitly with the CalDAV server.
Thank you @cliffi30 , with that method I was able to sync the calendar with Thunderbird.
It is a pity that I have found that in the forum, and not in the documentation (at least a web search pointed to this thread first …)
Nevertheless, I have a general question: does the sync work in 2 ways?
I have perhaps spotted an issue last week: I added/modified a couple of entries into the calendar, from the iOS calendar app, and that update has not popped up in the Murena cloud calendar. It is well possible that I was lacking connectivity at the precise moment, could it be the cause of the issue? Is it not the iOS calendar app trying to sync later? Or is there any tricks I do not know?
Nevertheless, it seems that it works flawlessly when updating from Thunderbird ( = few moments later, I can see that in the iOS calendar app).
Thank you in advance for any suggestions
Hi,
Some feedback about the above issue.
In the end, it syncs both ways. But there is a timing issue, as far as I could see:
Any thoughts?
Thank you in advance
In Android I always have to manually sync from one of these:
… by turning the switch off & on again, according to which CalDAV data set(s) need to be updated, when either:
I haven’t had to do this for Calendar entries since noticing that there’s a Refresh setting on the ... menu in the upper right hand corner on the default /e/OS calendar app.
If the Contacts app also had such a button, it would save me a lot of manual work… or if there were some CalDAV app that would maintain a tighter connection somehow (shorter interval or on-demand).
The synchronisation between Thunderbird (native Calendar + CardBook for contacts) and the Murena server is much tighter, so I never have problems on that end. There is a Synchronise button for both that I get used to hitting every time I’ve made a change anywhere.
My one reservation is that these Tbird sync processes display no diagnostics, so you can’t verify what it’s doing or whether it finished right. I’ve had some cases where updates made to contacts on both sides didn’t converge… even if happening days apart… and it would be nice to have some clue about why.
Sync interval can be checked / set at
Settings > Accounts > Murena A/C > My Account > Settings > tap on A/C ID > top right settings gear wheel icon > Synchronisation.
thanks… it shows 15 minutes for both (would be the default, since I’ve never changed either): yet my Settings often show “Last synced” hours ago even when I’ve made local changes on the phone (which should sync immediately) or updated a server contact within 15 minutes.
Of course I can’t be sure what is at fault here. It would be nice to get enough information to submit a problem report, though I’ve decided to delay this until I can set up my own Murena instance so I can test any problem at both ends.
Worth doublechecking: in these account settings there’s a button for “sync only via wifi”
ON may cause delays for obvious reason
thanks, in general yes that’s worth checking… though in my own case it’s always been the default of “connection type not taken into account” and in any case it’s on WiFi over 90% of the time which offers good Internet bandwidth over 99% of the time. 
Interesting … thank you all
