display-picture-changed signal is emitted with NLNs, but soon after login we don't have endpoint data yet (arrives with UBXs), so if we start transfering the dp, peer_guid is None and the transfer fails resulting in a nice kaboom. a possible solution is emitting that signal also when an UBX is received, and make the p2p session fail when version is 2 and peer_guid is None. emitting the signal ONLY when an UBX is received is not a viable solution since the servers send only NLNs when an user changes his/her/its picture.
How does it work with WLM ? wouldn't it take the GUIDs from the JOI on the SB? or just send without the GUID and then use the GUID it receives in the response? also, how could it be version 2 and peer_guid is None? what is the deciding factor? I thought that it should be : if peer_guid is None: version = 1 else: version = 2 am I wrong ?
(In reply to comment #1) > How does it work with WLM ? wouldn't it take the GUIDs from the JOI on the SB? > or just send without the GUID and then use the GUID it receives in the > response? > also, how could it be version 2 and peer_guid is None? what is the deciding > factor? I thought that it should be : > if peer_guid is None: > version = 1 > else: > version = 2 > > am I wrong ? yesterday i had a brief look at the code with lfrb, and he said he thinks the endpoint list isn't ready yet, so i guess papyon is updating this list with UBXs (i didn't have time to check the code) and this bug is sort of a race condition where this list isn't updated yet and the p2p transfer is started (because i am starting the p2p transfer as soon as i receive the dp-changed signal that comes with NLNs).
*** Bug 30163 has been marked as a duplicate of this bug. ***
Fixed in papyon 0.5.1
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.