[mythtv] Fwd: [mythtv-commits] mythtv branch master updated by jyavenard. v0.28-pre-1024-g9cba5e2

Jean-Yves Avenard jyavenard at gmail.com
Thu Mar 27 02:18:57 UTC 2014


On 27 March 2014 12:25, Craig Treleaven <ctreleaven at cogeco.ca> wrote:

> Is it possible that the image isn't complete or is malformed so way? The
> logging indicates it is transferred in 1428 byte chunks.  Is it possible
> that the last chunk is being dropped or padded and therefore is malformed?

no... this is multi-part mime. The size of the file being received is
known in advance. We read until we have received all the data.

Also, you are receiving a proper image.
>From your log:
Received 960x720 png photo

if it reads the actual dimension and the QImage object was created, it
means the data is valid


You can if you want to check write the image received to disk. and
check the file yourself.

Use the following patch:

diff --git a/mythtv/libs/libmythtv/AirPlay/mythairplayserver.cpp
b/mythtv/libs/libmythtv/AirPlay/mythairplayserver.cpp
index 0a6c046..7d7c118 100644
--- a/mythtv/libs/libmythtv/AirPlay/mythairplayserver.cpp
+++ b/mythtv/libs/libmythtv/AirPlay/mythairplayserver.cpp
@@ -843,6 +843,15 @@ void MythAirplayServer::HandleResponse(APHTTPRequest *req,
                 .arg(image.width()).arg(image.height()).
                 arg(png ? "jpeg" : "png"));

+            if (!image.save("/tmp/airplayimage", png ? "png" : "jpeg"))
+            {
+                LOG(VB_GENERAL, LOG_ERR, LOC + "Error writing image to disk");
+            }
+            QFile file("/tmp/airplayimagebin");
+            file.open(QIODevice::WriteOnly);
+            file.write(req->GetBody());
+            file.close();
+
             if (m_connections[session].notificationid < 0)
             {
                 m_connections[session].notificationid =

This will write two files:
/tmp/airplayimagebin which is the file exactly as it was received
and /tmp/airplayimage which is the QImage saved using QImage::save().
A QImage is a bitmap internally, so that means the file will be
re-encoded in the required format, and as such different than the
original

but you can you the finder to check what the file looks like

If you are seeing a red circle where the image is supposed to be
displayed, there will be an error somewhere, or the theme is wrong....
check the log.


> For crying out loud, you are awfully quick to dismiss my results.  I picked
> up these changes because I spend my (limited) time reading the -commits
> list.  I spent more of that time building and testing the code on four
> different frontends with multiple iOS devices as sources.

I said right from the beginning that I wouldn't support one more
packaging method. Especially after I spent such a massive amount of
time getting myth to work fine on a mac.
I made it clear that my goal is to have a proper mac like application,
self contained to do everything.
Why should I be expected to support your choice, when I clearly
pointed out where my preferences were.

You also have to admit, that you're not making it very easy to want to
help you either.

I've been spending an awful lot of time on issues that turned out to
always be unique to your usage. Either custom qt patches existing only
in macport, or problem related to your hardware.

In almost all circumstances with problems you have reported, they
turned out to be incorrect... the majority of them.
*You* are the one systematically blaming those problems on others, and
being very verbose about it. And then when massive amount of time has
been spent troubleshooting the issue: it turns out it was your problem
(where in several cases I painfully remember, you just turned quiet
and nothing more from you was heard on the topic. Didn't even
acknowledge anything, or even a "thank you for helping". Those are
appreciated you know. All myth devs are here on a voluntary basis !

I usually take the approach on making sure the problem doesn't come
from something I did, only then do I blame someone else.
You have systematically taken the opposite approach.

So, I'm sorry if any issues you now report go back to the bottom of my queue.
I'd be very happy to be proven wrong in the future. That wouldn't
waste my time more than I have to.

> Just how many other users have confirmed that your code works in their
> environment.  Any?
>
> I appreciate that you adapted this code from XBMC and have done the work to
> bring it to Myth.  Why don't you give me the same courtesy with the testing
> I'm doing?

I did copy?

I'm not aware of that.

You have things backward...

All the AirPlay code in mythtv was written or rewritten from scratch,
and in fact you'll find that things like retrieving artwork and
metadata from iTunes playing was actually copied from myth, not the
other way around.
XBMC got the AirPlay support from the Boxee project.

Myth has its own, complete audio support; while everyone else out
there uses libshairplay which has no support for A/V Sync
whatsoever... Ever tried to play remote audio with a local video?
Notice on how A/V sync is just as good as a real Apple TV (and we have
to support a virtually unlimited amount of hardware). All the others
have a 2s delay.

I'm very proud to say that AirPlay support in myth is superior to any
other implementation out there (short of the commercial AirServer
product which also supports mirroring, but they don't support HLS or
AirTunes)

I have spent time in setting a 10.6 VM to test your problem. yourself
said it works on 10.9.2. Fact: it works just fine using either the Qt
I built from source without any patches whatsoever, and it works just
fine with the Qt binary packages downloaded from qt site.

It doesn't work for you... on something *you* compiled and packaged.

Where do you think the problem is most likely going to be .... honestly ?


More information about the mythtv-dev mailing list