Broken/incomplete JPEGs from phoneThumbnail field

[Andy Holmes]

That might be related somehow, but I can confirm a recharge doesn't
fix the problem.

The file transfer in the notifications plugin is checksum hashed so I
could detect if something is wrong on my end, but the phoneThumbnail
field in the telephony plugin is just a string of base64 encoded
bytes. I assume if there was a "transfer" problem it would result in a
malformed JSON packet, and if I was decoding it incorrectly it
wouldn't render at all.

For now I'll just render the thumbnail as is and prefer the icon
passed by the notifications plugin, but if someone gets a chance to
run 'jpeginfo -c' on a decoded phoneThumbnail to confirm I'm not crazy
I'd appreciate it.

On Wed, Nov 8, 2017 at 1:03 AM, Ianseeks <bingmybong at btinternet.com> wrote:
> On Tuesday, 7 November 2017 18:55:33 GMT Andy Holmes wrote:
>> Actually, I didn't notice until just now, but Gmail seems to correctly
>> render the JPEG I attached, which is definitely broken. Gimp prints
>> the same warning as jpeginfo but also renders the JPEG correctly. I'll
>> attach a PNG screenshot of how it's being rendered with GdkPixbuf.
>>
>> I can't tell if they are also broken with KDE Connect, actually, since
>> they are rather small and QPixmap might be handling errors like other
>> programs apparently do. This doesn't seem to happen when the icons are
>> passed via a "payload" transfer, only in the telephony plugin as
>> base64 bytearray.
> I had a similar problem where a transfer via kdeconnect would not complete, it got to about 80-90% but if i transferred the same files with dolphin, it worked fine.  I forgot to charge my phone and as a result of the "reboot", it cleared the problem.
>
>> I've tried decoding and rendering the pixbuf directly and saving the
>> JPEG to disk in the implementation and re-reading. Even hand copying
>> the base64 from terminal output, converting the base64 and saving to
>> file has the same results.
>>
>> On Tue, Nov 7, 2017 at 6:20 AM, Albert Vaca <albertvaka at gmail.com> wrote:
>> > I don't follow the problem: Are they also broken when received with KDE
>> > Connect, or only when receiving them using your implementation? Is the issue
>> > found when creating the image, or when reading it afterwards?
>> >
>> > On Sat, Nov 4, 2017 at 4:16 AM, Andy Holmes <andrew.g.r.holmes at gmail.com>
>> > wrote:
>> >>
>> >> Hi,
>> >>
>> >> I'm writing a small program to interact with the KDE Connect android
>> >> app in GLib/Gtk and I'm encountering problems with the base64
>> >> phoneThumbnails being transmitted with telephony events.
>> >>
>> >> I'm not at all familiar with QPixmap but I assume it's comparable to
>> >> GdkPixbuf, so doubt this is the problem. I've used the utility
>> >> jpeginfo to confirm the image is broken and Eye of Gnome to confirm
>> >> that image can be opened (and I'm decoding the data correctly) but is
>> >> corrupted. I'll attach the corrupted JPEG and below is the
>> >> jpeginfo/GdkPixbuf output:
>> >>
>> >> jpeginfo:
>> >>
>> >> test.jpg   96 x 96   24bit JFIF  Normal Huffman    4191  Premature end
>> >> of JPEG file  [WARNING]
>> >>
>> >> GdkPixbuf:
>> >>
>> >> GdkPixbuf.PixbufError: Error interpreting JPEG image file (Application
>> >> transferred too few scanlines)
>> >>
>> >> I can also confirm that libfolks is obtaining the same avatars
>> >> correctly, so I don't believe these images are broken at the source.
>> >> Could anyone advise on how I might try and track these errors down?
>> >
>> >
>>
>
>
>
> --
> opensuse:tumbleweed:20171102
> Qt: 5.9.2
> KDE Frameworks: 5.39.0
> KDE Plasma: 5.11.2
> kwin 5.11.2
> kmail2 5.6.2
> akonadiserver 5.6.2
> Kernel:  4.13.10-1-default
> Nouveau:  1.0.15_1.2
>