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

[Jean-Yves Avenard]

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

I doubt I'll ever make this change permanent, simply because it
handles two formats only, and who knows what format apple will send
his photos as in the future, or even what iTunes artwork format could
be...

Plus, I'm strongly against putting work-around 3rd party's librairies
bug. That's not how a bug should be fixed.

>
> 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:
>
> QMAKE_LFLAGS_SHLIB += $${FREETYPE_LIBS}
>
> 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?