[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 23:02:06 UTC 2014


On 28 March 2014 01:16, Craig Treleaven <ctreleaven at cogeco.ca> wrote:

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

there's no reason this can't be done in a bundler.
And I still need to get all the python and perl bindings for the
frontend anyway for things like metadata retrieval to work...


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

I'm not in the packaging business.
But as I now use a mac as development platform, I needed something to
test my code. At the time there was no mac solution that were actually
working on 10.6. Qt didn't compile anymore and it was taking an awful
long time.

I didn't want to have to compile Qt, hence the writing of the new packager.

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

As far as I can tell, most issues ever reported on the mac, have been
linked to the macport install, and are Qt related.
Fact is, using the official binary Qt package I don't have any such
issues and have been unable to reproduce those isses.

Last I check the Qt macport instal, it was full of patches. Why a
packager believes there's a need to heavily patch a beast like Qt is
beyond me. If there's a fix to be done on Qt, it needs to be done
upstream.
I also seriously doubt that whomever package Qt has a better knowledge
of the code than the Qt developers...
That's no disrespect to the person making Qt compile. That alone is
close to a miracle.
I've submitted over 20 patches and bug reports to Qt on the mac.

Patching things so they compile that's fine, modifying core behaviour isn't.


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

Well, I'm hoping one day they will work :)

I don't use them, they compile, I put them in


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

Memphiz found out that refreshing the Bonjour advertising service
every 10s made the AirPlay service appear as a full service.

That's what the acknowledgement was about.
Now AirPlay on myth update the Bonjour service data every 10s (can't
do more often than that, otherwise in OS X, the system will disable
the service completely)

It seems that the issue of the iPhone showing Myth Airplay as speaker
only rather than a full service is related to the order in which the
service are discovered.
You have two services: RAOP and AirPlay

AirPlay must be seen after RAOP.

IMHO, this is still a big hack. If I advertise AirPlay as supporting
FairPlay (Apple's DRM stuff) then the system shows up instantly and
with 100% reliability.

It's only when we advertise as not supporting AirPlay that it requires
to mess with the order of advertising.

It's likely this functionality will stop working one day as tweak things

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

that leaves two possibilities:
1- It works for them
2- There's no-one else to use it.

In both cases, it means you're the only one having the issue... It
works for me... See where I'm getting at :)


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

photos work 100% of the time, provided you understand the limitation
that iOS 7.1 may take a little while to initialize the Airplay service
and you may have to wait a little while before wanting to use it.

What I mean is that in your typical production install where the
frontend is running and left alone for hours it's fine.
In a testing environment, where you start the frontend, test, close:
it will fail from time to time at the beginning


More information about the mythtv-dev mailing list