Andy Holmes

Thanks for reporting. Looks like concurrent packets sent from `Core.Channel.upload()` are hitting `G_IO_ERROR_PENDING`, probably because the packet queue is on the device side.

I'm not sure what you mean exactly, but that sounds like a different issue.

Correct, you can consider all open issues unresolved :slightly_smiling_face: I don't use GSConnect myself anymore and don't really contribute much code for that reason. A fix for this will probably...

I don't have much of an opinion on this. GSConnect was intended to be specifically for GNOME Shell, but if another maintainer wants to give it a :+1: I won't...

Thanks for reporting! Looks like support needs to be added for transfers with a missing `payloadSize` field (and probably `0` for `totalPayloadSize` eventually).

Did we decide this issue was a false positive? I see there was a [comment](https://github.com/GSConnect/gnome-shell-extension-gsconnect/pull/1418#discussion_r922162320) stating this could be closed after v54 + testing.

Closing then, let me know if this was in error and I'll re-open.

> What should prompt gsconnect to detect that that the proxied application is no longer running and therefore it should stop proxying it? The same as starting. The remote device...

> This may be a KDEConnect app fault, of course, for not sending the packets, or it may be gsconnect for misunderstanding which packets ought to be sent; I don't...

> GSConnect would also occasionally receive updates for the Shazam instance, all of them marked "isPlaying": false because it's not playing, and every time this would cause an unholy freakout...