I tried building revision 12150 by using the 12150 sources I checked out. The thinking was that if I used the revision 12150 osx-packager.pl, I might have better luck.

But unfortunately I'm getting a whole new error:


I'm just not having a lot of luck here. But it's probably because I'm a myth noob, although I'm an experienced Mac developer.

Any thoughts on how to proceed? Again, what I'm after is a solution to my HD performance problem. If it isn't solved in a recent build, then I want to try and solve it by changing the code.

Thanks in advance.

_________________
Best,

Allen Cronce

Yes. I hadn't thought of that when I made recent changes to the script. Try:

When you are actually starting to hack (er, modify) the code, this should probably move to the mythtv-dev mailing list? Until then, I don't think Cecil will mind if we keep it here. Just as long as we mention KnoppMyth occasionally

_________________
| Nigel Pearson, nigel.pearson.au@gmail.com
| "Things you own end up owning you" - Tyler, Fight Club

Only a warning there. I think the error occurred just before that. make -j N runs several jobs in parallel, and the output sometimes gets confused.

_________________
| Nigel Pearson, nigel.pearson.au@gmail.com
| "Things you own end up owning you" - Tyler, Fight Club

I setup a build of 12150. It didn't get that error (I got another one to do with mythzoneminder, which I disable in newer versions of osx-packager.pl), so I am a bit stumped.

Normally I would advise doing a clean build (add --clean), but another workaround would be to just disable the plugins for now? (add --pluginskip)

_________________
| Nigel Pearson, nigel.pearson.au@gmail.com
| "Things you own end up owning you" - Tyler, Fight Club

Hmm... The .osx-packager invisible directory in my build folder is empty. The disk image has that path though. Are you suggesting that I mount the disk image and do the following command:



Agreed. By the way, I really like KnoppMyth

_________________
Best,

Allen Cronce

Thanks for your continued help.


I guess I could try again with the -clean option. But if I failed the first time I built, would -clean do anything?

If you got different results from your build attempt, then either we're doing something different, or we have a different environment. Could you tell me the exact steps you took to build 12150?

Thanks in advance.

_________________
Best,

Allen Cronce

On a freshly installed MacBook, after adding SVN binaries in my path, exact steps:

That fails due to the osx-bundler.pl script not being in this old source tree, so:

That succeeds:

Note that the disk volume that is created is only unmounted if the build is successful. That is why the old version of osx-packager should be available under .osx-packager/src

_________________
| Nigel Pearson, nigel.pearson.au@gmail.com
| "Things you own end up owning you" - Tyler, Fight Club

Hi Nigel,

Unfortunately following your exact steps resulted in the build error related to mythzoneminder:


What I did to work around this problem was use the -pluginskip option, as per an earlier post from you.

So here's the steps that worked for me:

1. Create a new build directory and cd to it.

2. Download the bleeding edge build script:

3. Make the build script executable:

4.Perform the build:

5. When the first build error happens (due to the fact that the bleeding edge build script is too new), do the following:

The results in a built MythFrontend from revision 12150 with no plug-ins. Not ideal, but good enough for what I want to do.

I've done some quick tests and verified that the same dropped frames problem is happening with the 12150 revision as with the 0.20.0.svn20061001 version that I had previously downloaded. This is not a surprise, but I was hoping to get lucky.

So at this point, I need to dig into the code and figure out why it's scaling unnecessarily. Unfortunately I'm pretty wiped out with a cold, so I don't know if I'll be able to take this on today. And I don't even have Xcode installed on the Mac Mini, so debugging is impossible until I do that.

BTW, is there any way to debug the frontend from Xcode instead of gdb? I can do either, but prefer Xcode's source code level debugging. Call me a GUI wimp if you like. I assume the answer is no though since I can't find an xcode project in the sources.

Anyway, thanks for your help getting me this far. I'll let you know when I have any news.

_________________
Best,

Allen Cronce

Ah yes. I forgot that I had edited .osx-packager/src/myth-svn/mythtv/contrib/osx-packager.pl to disable that plugin.

I have only used gdb for crash debugging, not code tracing. I usually just add printf (or VERBOSE) statements.

_________________
| Nigel Pearson, nigel.pearson.au@gmail.com
| "Things you own end up owning you" - Tyler, Fight Club

I got a little lost on this thread and the discussion about how to compile. However, I am interested to know if the end result fixed the problem with mythfrontend on mac mini. I have some of the same problems of tearing, minor studdering, and combing (especially on sports). I also have had some stability problems with mythfrontend crashing if I leave it running for long periods, and it takes a very long time to start.

Did recompiling yield a better result?

Background: I am using r5e50 on my backend. My mythfrontend was downloaded from collectivity.goof.com. I am using a mac mini core2duo 1.6GHz.

Thanks,

-Jeff

Unfortunately my time has been limited recently, so I haven't been able to spend much time on this problem. All I've had a chance to do is review the code and look for possible reasons why I'm seeing scaling performance problems.

What I *think* is happening is the VideoOutputQuartzView is being set to 1088 lines before the hack in VideoOutputXv::ResizeForVideo that normalizes the lines to 1080.

When I get more time, I'll verify this in the debugger and try to code a work around.

_________________
Best,

Allen Cronce

I've made a small change to VideoOutputQuartz::Init that I want to test. Namely, I've added the follow code at line number 1276 of videoout_quartz.cpp in svn revision 12150:

Unfortunately, I can't figure out how to build with this change. Everything I've tried has resulted in either build failures or re-checking out the code.

It's frustrating that it only took minutes to figure out the change I want to make, but it's taken hours trying to build it. I'm sure that the issue is that I'm just not hip to the process that should be used.

Nigel, can you please outline how I can build with my changes? Just to reiterate, I want to start with svn 12150 as a base, then I want to make small changes, then build the front end with those changes.

Also, let me know if you think it's time to move this discussion to the mythtv-dev mailing list. Although I'd kind of like to finish it here so that anyone else who runs into this issue can see the ending.

Thanks in advance.

_________________
Best,

Allen Cronce

Never mind Nigel. I think I've figured out how to build with my changes.

Basically what I did was a build of the svn revision 12150, with the set of work arounds covered earlier in this thread. Then I make my source changes in the .osx-packager hidden directory. Then I build with the following command:

The pluginskip option is still needed to work around that mythzoneminder problem.

In any case, the above results in an application that I can debug. Unfortunately, my hack hasn't resolved the issue yet. But at least I can move forward now.

_________________
Best,

Allen Cronce

Now that I can hack at the code, I've found some interesting results. It looks like early on in the initialization process myth takes 1080 lines and rounds it up to 1088, an even multiple of 16. This happens in a routine called "avcodec_align_dimensions" in a file called "utils.c" in libavcodec.

But the problem I've been seeing is that this delta between 1080 and 1088 lines results in scaling on the Mac OS X frontend when the display is set to 1080i. And the poor Mac Mini cannot keep up with this work, which results in dropped frames.

So as a binary chop, I hacked avcodec_align_dimensions to normalize to 1080 lines instead of 1088. Sure enough, the scaling problem goes away. With this hacked version, I'm was able to reenable the "Scale video as necessary" option and almost everything works. That is, lower resolution content scales (which is desirable) and 1080i does not scale, so everything looks OK and the Mini does not drop frames.

But this is clearly not the right long term solution. I have to assume that the rounding of 1080i to 1088 in avcodec_align_dimensions is intentional. Unfortunately none of this code is very well commented and I don't have enough experience with the code base to know what is and is not by design.

However experimentally I've determined that my hack does not work right for one of our HD channels. With our PBS affiliate I see about a 1 inch high green band at the top of the image, and green blocks pixelate down into the main image sometimes. It's distracting and not quite watchable.

I think that perhaps a better solution would be to make the "Scale video as necessary" option smarter, where it only scales if there's more than a certain percentage difference between the output image and the material. As an added advantage, this kind of fix would allow me to correct the overscan on my 1080i set without triggering a scaling of 1080i material, assuming that I set the scaling triggering threshold correctly.

I'll look into the feasibility of this kind of fix and report back when I've got some results.

_________________
Best,

Allen Cronce

Hi Allen.

1) I hadn't realised that libavcodec expanded the streams' dimension. I thought the stream from the stations were pre-oversized.

2) Note this code in videoout_xv.cpp:
I suspect videoout_quartz.cpp needs a similar hack to crop the expanded stream dimension. Something like this:

_________________
| Nigel Pearson, nigel.pearson.au@gmail.com
| "Things you own end up owning you" - Tyler, Fight Club