https://bugs.freedesktop.org/show_bug.cgi?id=67909 --- Comment #1 from Eugenio Parodi <eugenio.parodi(a)intel.com&gt; --- Created attachment 83853 --> https://bugs.freedesktop.org/attachment.cgi?id=83853&action=edit Dbus Full Session Dump -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=67909 Patrick Ohly <patrick.ohly(a)gmx.de&gt; changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |NEEDINFO --- Comment #3 from Patrick Ohly <patrick.ohly(a)gmx.de&gt; --- The relevant logic which checks for new data is here: bool PullAll::getContact(int contactNumber, pcrecpp::StringPiece &vcard) { SE_LOG_DEBUG(NULL, "get PBAP contact #%d", contactNumber); if (contactNumber < 0 || contactNumber >= m_numContacts) { SE_LOG_DEBUG(NULL, "invalid contact number"); return false; } Content::iterator it; while ((it = m_content.find(contactNumber)) == m_content.end() && m_session && (!m_session->transferComplete() || m_tmpFile.moreData())) { // Wait? We rely on regular propgress signals to wake us up. // obex 0.47 sends them every 64KB, at least in combination // with a Samsung Galaxy SIII. This may depend on both obexd // and the phone, so better check ourselves and perhaps do it // less often - unmap/map can be expensive and invalidates // some of the unread data (at least how it is implemented // now). while (!m_session->transferComplete() && m_tmpFile.moreData() < 128 * 1024) { g_main_context_iteration(NULL, true); } m_session->checkForError(); if (m_tmpFile.moreData()) { // Remap. This shifts all addresses already stored in // m_content, so beware and update those. pcrecpp::StringPiece oldMem = m_tmpFile.stringPiece(); m_tmpFile.unmap(); m_tmpFile.map(); pcrecpp::StringPiece newMem = m_tmpFile.stringPiece(); ssize_t delta = newMem.data() - oldMem.data(); BOOST_FOREACH (Content::value_type &entry, m_content) { pcrecpp::StringPiece &vcard = entry.second; vcard.set(vcard.data() + delta, vcard.size()); } // File exists and obexd has written into it, so now we // can unlink it to avoid leaking it if we crash. m_tmpFile.remove(); // Continue parsing where we stopped before. pcrecpp::StringPiece next(newMem.data() + m_tmpFileOffset, newMem.size() - m_tmpFileOffset); const char *end = addVCards(m_content.size(), next); int newTmpFileOffset = end - newMem.data(); SE_LOG_DEBUG(NULL, "PBAP content parsed: %d out of %d (total), %d out of %d (last update)", newTmpFileOffset, newMem.size(), (int)(end - next.data()), next.size()); m_tmpFileOffset = newTmpFileOffset; } } if (it == m_content.end()) { SE_LOG_DEBUG(NULL, "did not get the expected contact #%d, perhaps some contacts were deleted?", contactNumber); return false; } vcard = it->second; return true; } I see org.freedesktop.DBus.Properties.PropertiesChanged signals in the D-Bus log, which should wake up SyncEvolution and cause it to check the file size. In other words, I it is not obvious why it doesn't read more contacts from the file. Can I get a syncevolution-log.html file of the target side with loglevel=4? -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=67909 --- Comment #5 from Patrick Ohly <patrick.ohly(a)gmx.de&gt; --- Created attachment 83893 --> https://bugs.freedesktop.org/attachment.cgi?id=83893&action=edit ignore Status=active instead of terminating when seeing it This patch fixes the problem for me. -- You are receiving this mail because: You are on the CC list for the bug.

https://bugs.freedesktop.org/show_bug.cgi?id=67909 --- Comment #6 from Eugenio Parodi <eugenio.parodi(a)intel.com&gt; --- It seems fixed also here. I'll try to perform in any case some more tests. Thanks. -- You are receiving this mail because: You are on the CC list for the bug.