View source for Talk:MythTV on Mac x86

== Binary Packages? ==

(Tux541) Well I've posted a working version of Myth Frontend v0.19-Fixes without MMX support.  Anyone who wants to download it can find it here:

[http://www.wipzradio.com/files/mythfrontend-0-19-fixes-x86-nommx.dmg  www.wipzradio.com mythfrontend]

(Tux541) Here is the updated version of Myth Frontend v0.19-Fixes with MMX support from tji.

[http://www.wipzradio.com/files/MythFE_0.19fixes_mmx.tbz www.wipzradio.com MythFrontend-MMX]

(mmead) Thanks for the updated MMX instructions - I've gotten a (non fixes branch) 0.19 built with MMX at [http://www.goof.com/~mmead/Mythfrontend-0.19-intel-mmx.dmg.bz2 www.goof.com Mythfrontend-0.19-intel-mmx.dmg.bz2].  Using a Mac mini intel duo core 1.66Ghz, I see ~85% CPU use by mythfrontend when playing 1080i with bob deinterlacing over nfs and ~68% when playing 720p over nfs.

(mmead) [http://www.goof.com/~mmead/Mythfrontend-0.19-fixes-20060407-intel-mmx.dmg.bz2 www.goof.com Mythfrontend-0.19-fixes-20060407-intel-mmx.dmg.bz2]

(tji) That's similar performance to what I'm seeing.. I got between 85-95% with 1080i filmed material, and 95-99% with 1080i sports video.  I think that's because of the field/frame rate of the source material.    With 720p, I also got around 70% cpu.

In looking at the performance info via 'shark', the two biggest CPU users are the yuv420-2vuy colorspace conversion, and for 1080i, the deinterlacing.   The deinterlacing is already MMX accelerated.  But, the colorspace conversion is not.  If we can find/create mmx code to do that, we can probably save 5-10% more cpu time.

(flaggz) I'm getting very choppy performance on a 1.66GHz core duo with the MMX enabled binaries linked below. This applies to both 1080i content, and scaled 480i content, which I found pretty strange. For comparison, the latest trunk builds of VLC play these same files perfectly over the network, so the machine is clearly capable.

Interestingly, if I turn off 'Scale Video as Necessary' in TV Settings->Playback, then the problem goes away, at least for the 480i content. There is a corresponding impact to the profile information that Shark reports. The difference appears to be the YUV422_UC_ToRGB32BitColorBGRA QuickTimeComponents function, which is the primary consumer of cycles in everything except the '480i, do not scale video' case. Checking/unchecking the scale video setting has no effect on the performance of 1080i playback.

(tji) I don't see the YUV2RGB conversion at all on mine, that is done in hardware.   What kind of system is this?  Is it running an unaccelerated video driver?  Is it non-Apple hardware?

== Build Status ==

(tji) My current status:
*0.20 SVN non-MMX:
Frontend runs,  communicates with backend, and can view live TV.  My Core Duo mini is not fast enough to display smooth HD 1080i with this build.

I must have a MySQL version imcompatibility.  My FE/BE communications have some problems..  displaying the list of recorded shows fails.  I can see the data being transferred, but it hangs requesting channel icons ( 2006-03-17 10:17:23.454 MSqlQuery: SELECT icon FROM channel WHERE chanid = '1020' ; )  It hangs, repeating that sql request every half second.   Anyone else seeing this?

(jpg)I had/have a similar problem [SELECT icon FROM channel]... it's not actually hanging for me, if you hit escape you will go back to the menu. 

*0.20 SVN with MMX enabled:
Same as above, except 1080i HD displays smoothly, taking 85-95% of one CPU on a Core Duo Mini.

*0.19-fixes non-MMX:
Builds cleanly.  Requires some of the older patches, since this branch wasn't updated with all the 0.20 fixes.  All menus and program listings work fine.  Can play live video or select recorded.   Cannot play smooth HD video on Core Cuo Mini (needs MMX enhancements).

*0.19-fixes with-MMX:
Same as above, except MMX is working, and I'm getting video playback with less than 100% cpu.

== MySQL ==

(Gaspode) Yes I have the same problem as (tji) - the Mac frontend communicates with the linux backend - and the linux backed responds - but the frontend does not seem to receive it.

<br>(tji) Do you get complete failure of communication, or partial?   On mine, I can view Live TV, and navigate some menus, but viewing the recorded program list fails, and navigating into setup menus fail.

running "mythfrontend -v all" from the command line shows more debugging info.  When I try to access the recorded programs menu, it just scrolls the same message "MSqlQuery: SELECT icon FROM channel WHERE chanid = '1020' ;"     I did a network sniff, and verified the communication is working, and the response appears to be okay, but the frontend doesn't accept it.

I'm wondering if it's a version incompatibility between MySQL client libs and server..

<br>(Tux541) I had the same problem with mine, but only once.  The very first time I tried to connect my frontend to my backend, after that it was fine.

<br>(TTT_Travis) I opened the app it showed the setup screen so I set it up and then when I open it it just hangs sorta, icon just bounces and bounces for like minutes then closes 

<br>(Tux541) Try running it from a terminal.  That happened to me when it can't connect to your database.  If you run it from a terminal you will see it sits there trying to connect, then times out after 60 seconds, then tries again.  If so try rm -rf /Users/*username*/.mythtv. This will blow out your settings, then try it again.  This might be related to some of MySQL problems were seeing.  By the way...  What version of MythTV are running on the backend and what version of MySQL.

<br>(Gaspode) Partial failure - Live tv works - menus work (except menus that trigger an sql query - (eg. setup, recorded programs)
I used ethereal to sniff the network and the backend does respond to the front end.  Also logged in to the backend mysql using the client on the frontend and verified that communication works.

I don't think it is a version problem (I have the same mysql version on the backend and the frontend) .It's either QT doing something strange to the data or the frontend itself.

<br>(tji) Good info..   I'll try a newer version of QT, once I go back to messing with 0.20.  I used the '20060321' snapshot of 3.3.6 with MythTV 0.19-fixes, and it worked fine there.

<br>(Gaspode) Sorry , I should clarify that - I think it's either QT doing something strange to the data, or it is something in the frontend code.