Sharing doesn't work in Read Activity

[wad]

On builds 656, 691 and 693, on production laptops (but with suspend inhibited), sharing of documents using the Read activity doesn't work.

This has been verified to fail in both the simple mesh and AP network modes, using both invites and joins as the method of sharing.

Documents downloaded to the laptop as well as documents on a USB stick were tested. All failed.

The method of failure is that the invitation (or shared document) appears fine on the other laptops. When selected, the Read activity is launched OK, but it never receives the document being shared. It just sits there with a blank screen.

[rwh]

Ouch! I tested here on Salut back-end (either I can't get Gabble to work or olpc.collabora.co.uk is not functioning). I think there are two issues: the first is that the timeout for the (local) Activity.Join call is a bit short (anybody an idea what the default is?), and two: the stream tubes seem to have trouble transferring the whole file. I'm not sure where the problem is exactly, but the GlibURLDownloader always used to work. It checks whether the data blocks are the expected size (4096). I changed the code to just check whether there is data at all, and this is the result:

1203291580.779578 DEBUG read-activity: Downloaded 4096 bytes from tube 514189109...
1203291580.792029 DEBUG read-activity: Downloaded 8192 bytes from tube 514189109...
1203291580.795031 DEBUG read-activity: Downloaded 12288 bytes from tube 514189109...
1203291580.796583 DEBUG read-activity: Downloaded 12377 bytes from tube 514189109...
1203291580.798068 DEBUG read-activity: Downloaded 12377 bytes from tube 514189109...
1203291580.799587 DEBUG read-activity: Got document /tmp/1203291580 (1203291580) from tube 514189109

No more data seems to be coming, although the 'server' instance definitely writes the whole file.

Any ideas?

[rwh]

Could anybody from collabora (or other presence developers) comment?

[gdesmott]

This is a Salut bug. We don't flush the transport buffer when we disconnect it so we lose its data.

I'm working on a fix.

[gdesmott]

Fixed in upstream.

[morgs]

telepathy-salut-0.2.2-2.olpc2 built in koji for joyride, with this patch included.

[morgs]

Make that telepathy-salut-0.2.2-3.olpc2 actually :(

[gdesmott]

As said previously they are at least 2 issues here. Let's focus on the stream tube problem in Salut, I'll open a new ticket about the other one.

Problem was Salut loosing data because it doesn't flush transport buffer. That should be fixed with the attached patch and in telepathy-salut-0.2.2-3.olpc2. I think we should consider to ship it for Update.1.

[gdesmott]

See #6537 for the suspend issue.

[morgs]

Joyride-1721 has telepathy-salut-0.2.2-3.olpc2

[walter]

FYI, sharing still doesn't work on 699 with a simple mesh under a very light network load. The other activities I tried--Write and Distance--shared fine.

[wad]

I just checked and I was able to share a PDF from one laptop to two other pretty well over a simple mesh. When I tried to share it to 8 other laptops, things broke down.

Laptops would start the application, but would never show any content. Quitting and re-joining the shared activity would sometimes work.

Build 699, Read-44, simple mesh, no other RF traffic on channel 1.

When things started falling apart, all of the laptops could no longer "see" one another in the neighborhood views.

This could be the multicast limited to single hop affecting us (it is definitely present in the packet traces). I will try to retest enabling multihop.

[wad]

This definitely gets worse with multihop mesh re-enabled.

[gdesmott]

Could be related to #6537. Can you try to disable read suspend (touch /etc/inhibit-ebook-sleep) please?

[cjb]

Could be related to #6537. Can you try to disable read suspend (touch /etc/inhibit-ebook-sleep) please?

Build 699 already has /etc/inhibit-ebook-sleep written, so I don't suspect that's it.

Wad, you might try seeing whether telepathy-salut is still running in the failing state -- perhaps this is another telepathy-salut crasher.

[gdesmott]

We'll need Read and Salut log: http://wiki.laptop.org/go/Telepathy-debug

Does it work fine with Gabble when trying the same use case?

[cjb]

Michael and I caught an error with Read and Salut logging turned on last night. It'll be up here soonish.

[mstone]

logs from a failed join attempt

[mstone]

logs from a successful join attempt

[mstone]

See http://lists.laptop.org/pipermail/devel/2008-March/011943.html for are more detailed description of the measurements that generated these logs.

[mstone]

Walter and I briefly discussed the state of our knowledge about these failures and we reached the tentative conclusion that we should advise clients (particularly Peru) not to rely on Read-sharing as their primary mechanism for distributing etexts to children.

[walter]

To expand upon Michael's post, presuming we have robust Journal-to-USB-to-Journal sharing, we have a fall-back position, hence I would assert we change this from blocker to high priority. That said, we should consider removing the share menu from read a la

toolbar = toolbox.get_activity_toolbar()

toolbar.share.hide()

so as to not give the impression that sharing works when it doesn't

[hhardy]

Replying to wad:

I noted a similar behaviour at the OLPC Boston gathering last night. Sharing between my 702 build and their (probably) 656 builds failed when trying to use the measure activity. You could see the doc and try to share but the button for measure never un-greyed-out. Simple mesh, was also connected to COSI wifi. Same behaviour whether they or I initiated the activity. They could measure amongst themselves ok.

On builds 656, 691 and 693, on production laptops (but with suspend inhibited), sharing of documents using the Read activity doesn't work. This has been verified to fail in both the simple mesh and AP network modes, using both invites and joins as the method of sharing. Documents downloaded to the laptop as well as documents on a USB stick were tested. All failed. The method of failure is that the invitation (or shared document) appears fine on the other laptops. When selected, the Read activity is launched OK, but it never receives the document being shared. It just sits there with a blank screen.

[bemasc]

The situation has actually gotten worse. In Update.1-702, when A shares an instance of Read, B sees A's XO jump in the mesh view, but no Read icon appears. Therefore, in this build Read can only be shared by invitations.

Document transfer does work, under ideal conditions (mesh with 2 XO's, no suspend). This has been the case for some time. Document transfer only fails on denser meshes, or when Read suspends and breaks the transfer.

[bemasc]

Heisenbug! After a reboot, the exact same sequence works correctly, with the icon for A's Read session appearing as expected in B's mesh view, and the PDF file transferred as desired.

[gdesmott]

Salut log from logs.SHF72500057.2008-03-19.23-00-12.tar.bz2 doesn't have the "---Finished joining phase!!!!---" so that could be the same bug as #6739. As for this bug, a tcpdump could be useful.

[gdesmott]

Closing this bug as the original stream tubes bug was fixed and #6739 is already open about the joining problems.

[gregorio]

Milestone Never Assigned deleted