[mythtv] [mythtv-commits] mythtv branch master updated by jyavenard. v0.28-pre-1046-gd7de3ff

Craig Treleaven ctreleaven at cogeco.ca
Fri Apr 4 11:37:13 UTC 2014

At 9:13 PM +1100 4/4/14, Jean-Yves Avenard wrote:
>On 4 April 2014 13:58, Craig Treleaven <ctreleaven at cogeco.ca> wrote:
>>  OK, I've checked that all the bits that were recently modified (latest
>>  0.27-fixes but including the two commits to master) work OK for me on
>>  10.6.8.  Well, except AirPlay of photos--I've tried a LOT of different
>>  things but can't make that work.  Must be a MacPorts-Qt4 glitch but it
>>  eludes me.
>>  Also tested the build on 10.9.2 and all seems well there.
>for your build, you could try this patch:
>diff --git a/mythtv/libs/libmythtv/AirPlay/mythairplayserver.cpp
>index 0a6c046..75f75c0 100644
>--- a/mythtv/libs/libmythtv/AirPlay/mythairplayserver.cpp
>+++ b/mythtv/libs/libmythtv/AirPlay/mythairplayserver.cpp
>@@ -834,10 +834,10 @@ void 
>MythAirplayServer::HandleResponse(APHTTPRequest *req,
>          if (req->GetMethod() == "PUT")
>          {
>              // this may be received before playback starts...
>-            QImage image = QImage::fromData(req->GetBody());
>              bool png =
>                  req->GetBody().size() > 3 && req->GetBody()[1] == 'P' &&
>                  req->GetBody()[2] == 'N' && req->GetBody()[3] == 'G';
>+            QImage image = QImage::fromData(req->GetBody(), png ?
>"JPG" : "PNG");
>              LOG(VB_GENERAL, LOG_INFO, LOC +
>                  QString("Received %1x%2 %3 photo")
>                  .arg(image.width()).arg(image.height()).
>This tells which format to use rather than letting Qt guess.
>not tested.

Thanks but I've essentially tried this.  I knew that all the images I 
was testing with are jpeg so, as a hack for testing, I did:

             QImage image = QImage::fromData(req->GetBody(),"JPG");
             QImage image = QImage::fromData(req->GetBody(),"JPEG");

Neither made any difference.  I also rolled back libpng and jpeg to 
the versions used in Qt's distributed binary.  That eliminated the 
ICC profile warning but I still can not get images to display.

Remember that it _does_ work on Mavericks for me.  I've asked the 
qt4-mac port maintainer if there is any build difference between 
Mavericks and all the other OS builds.  Waiting for an answer.

>  >...
>  > I know it is not a big deal to you, but I finally tracked down a build
>>  problem that has plagued me from the start on MacPorts--installed versions
>>  of the libs would be referenced due to an '-L/opt/local/lib' early in the
>>  linker's args.  I finally realized that it only affected libmythtv.
>>  mythtv/libs/libmythtv/libmythtv.pro includes the line:
>>  configure has filled FREETYPE_LIBS with the output from 'freetype-config
>>  --libs'.  On OS X, I get:
>>  $ freetype-config --libs
>>  -L/opt/local/lib -lfreetype -L/opt/local/lib -lz -lbz2 -L/opt/local/lib
>>  -lpng14
>>  I'm guessing that FreeType is trying to be 'helpful' since MacPorts
>>  installed it to a 'non-standard' location.
>>  Anyway, the line in libmythtv.pro is wrong.  FreeType's libs _are_ included
>>  later in the linker parameters.  Other uses of QMAKE_LFLAGS_SHLIB are for
>>  linker flags, not library references.  For example, line 83 of
>>  libmythupnp.pro sets:
>>  QMAKE_LFLAGS_SHLIB += -flat_namespace
>>  The above is in 0.27-fixes.  In master, I see that dblain wrapped the
>>  problem line in a conditional so that it would be excluded on win32-msvc*.
>>  I presume it was messing with him, too!
>>  I've deleted the offending line (line 52) and built successfully with both
>>  XCode 3.2.6 and XCode 5.1.0.
>>  Should I raise a bug for this?
>I'm not sure I understand what your problem is.
>Is the issue in freetype or in myth?
>Are you saying the myth uses installed headers/libraries rather than
>using the one in the current source tree?


>I'm seeing this problem too, even to the point where before I compile
>I always delete the system's installed mythtv librarires and headers.
>It's a pain cause often a compilation will fail at linkage simply
>because I've modified a library, but the new code is trying to link
>against the installed one; and as such I get non-existing symbol
>could this be the reason?


Plus the line makes no sense.  It is for flags; not link libraries. 
(And it's been there since 2006!)  Due to a quirk in Freetype, 
however, it has been no harm in the most common cases.  Only bites 
those of us packaging to non-standard locations.


More information about the mythtv-dev mailing list