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

[Craig Treleaven]

At 1:18 PM +1100 3/27/14, Jean-Yves Avenard wrote:
>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.

I'll give this a go and report.

>
>>  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.

Packaging the frontend in a bundle is great; I've said so repeatedly. 
MacPorts and the bundled apps are geared to quite different use 
cases.  For those of us that want to run the full system on OS 
X--including the backend--bundling makes it harder.  My work on 
MacPorts is all about making it easier to set up an OS X backend. 
Plists so it automatically runs on boot up, logging (and log 
rotation) in a rational location, full suite of myth* programs, 
functional Perl and Python bindings for backup and metadata, etc.

Honestly, why do you, a developer, want to be in the packaging 
business anyway?  There are upteen MythTV packagers out there.  Why 
is one more, MacPorts, an issue?  Homebrew has a half-assed version. 
Long ago, Fink had one.  Myth is just another software package. 
Building a functional version should not require special magic.  I 
see questions from other packagers from time to time on the Myth 
mailing lists.  They have problems, I have problems, hopefully the 
problems get sorted out.

BTW, a side issue:  why do you include MythBrowser, MythNetVision and 
MythNews in the frontend bundle?  None of those are actually 
functional, right?

>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 !

The fact is, I've reported 15 tickets in 3+ years [1], four including 
patches.  One is closed "Invalid"--yes, bizarre hardware problems led 
me to believe there was a code fault.  I admitted I was wrong and 
asked that the ticket be closed [2].  Not "a majority", not "almost 
all circumstances", not "several cases".

>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.

Let's review the AirPlay ticket [3].  I started testing in August 
2013 and we went back and forth through September (when I filed the 
ticket) without determining why Video AirPlay worked for you and not 
me.  You found and fixed a problem in October [4].  I updated but 
that didn't get me any further.  In January, another user reported 
what seemed to be the same problem I had [5].  From time to time, I 
retested but had nothing new to add to the ticket.

Four days ago, you committed some changes [6], noting "Since the 
release of iOS 7, AirPlay? has been very much unusable."  IOW, the 
issue I reported 6 months ago was, in fact, valid.

Now, I'm trying to confirm that the issue is actually resolved. 
Perhaps the remaining problem is due to the MacPorts implementation 
of Qt4.  As my last email showed, the current AirPlay implementation 
isn't exactly 100% reliable with the bundled app.  If MacPorts is the 
problem, I'll follow up with the maintainer of the Qt4 port to get it 
fixed.

>  > 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)

The commit referenced above [6], says "Thanks to Memphiz from the 
XBMC team to figuring the cause."  I took that to mean that they had 
a working implementation.  I apologize for misunderstanding.

Keep in mind that I want AirPlay to work!!  It is a seriously cool 
feature and I think being able to display iPhone photos and videos on 
a frontend machine is an awesome feature that will get people excited 
about Myth.  Particularly folks that have invested in the Apple 
ecosystem--folks that are likely to want to run the backend on OS X.

Would you rather get no feedback?  If I test and find it doesn't 
work, should I just shrug my shoulders and move on?  You sure aren't 
getting much from other users.

>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 ?

Two can play that game--it is not 100% on something *you* compiled 
and packaged.  Rather than guess, let me build another test version 
incorporating the patch and see what it tells us.

Craig

[1] 
https://code.mythtv.org/trac/query?status=accepted&status=assigned&status=closed&status=infoneeded&status=infoneeded_new&status=new&status=started&reporter=~ctreleaven&col=id&col=summary&col=status&col=owner&col=type&col=priority&col=resolution&order=priority

[2] https://code.mythtv.org/trac/ticket/11756#comment:17

[3] https://code.mythtv.org/trac/ticket/11901

[4] https://code.mythtv.org/trac/ticket/11909

[5] 
http://www.gossamer-threads.com/lists/mythtv/users/560694?search_string=airplay;#560694

[6] 
https://code.mythtv.org/trac/changeset/8ee257cf970c2a304e746524ef43aebe4043331d/mythtv