Mailing List Archive

On Sunday 13 April 2003 12:25 pm, Brett Bolen wrote:
> Has anybody tried MythTV on apple hardware. I would like to run
> at least the frontend on PPC hardware.
>
> Any reason why this won't work?

Since this seems to be happening with some regularity -- if you're going to
cross-post between the -dev and -users list, you better have a really good
reason to do so. I don't consider asking a question that's already been
discussed on the lists a 'really good reason'.

Isaac

>>>>> On Sun, 13 Apr 2003 12:25:57 -0400, Brett Bolen <brettb@moya.trilug.org> said:

b> Has anybody tried MythTV on apple hardware. I would like to run
b> at least the frontend on PPC hardware.

b> Any reason why this won't work?

I have the frontend working on Linux/PPC. It required some
big-endian patches. I can post these patches if there's interest. I
was trying to get it working on MacOSX but it turns out that there is
no Xv support and X11 ShM is not usable. I need to try it again after
the recent non-ShM mode fixes. Adding SDL support to Myth may be the
way to go but it's not something I can try to do for now.

--
Gregorio Gervasio, Jr.
gtgj@pacbell.net

>
>
> I have the frontend working on Linux/PPC. It required some
> big-endian patches. I can post these patches if there's interest. I
> was trying to get it working on MacOSX but it turns out that there is
> no Xv support and X11 ShM is not usable. I need to try it again after
> the recent non-ShM mode fixes. Adding SDL support to Myth may be the
> way to go but it's not something I can try to do for now.
>

Yes, I would love more info and patches to get mythtv compiled on ppc.
I gave it a whirl today, but I don't think I had much of a chance,
since I don't know much about this stuff. I don't even know what the
hell "big-endian" means. Anyway, here is what I did.


Today I tried to compile mythtv today on an slot loading imac G3 400
mhz with mandrake 9.1 ppc.

It failed even when I changed settings.pro from:

release {
DEFINES += MMX
QMAKE_CXXFLAGS_RELEASE = -O6 -march=pentiumpro
-fomit-frame-pointer -funroll-loops -fexpensive-optimizations
}


to


release {
DEFINES += MMX
QMAKE_CXXFLAGS_RELEASE = -O6 -march=powerpc
-fomit-frame-pointer -funroll-loops -fexpensive-optimizations
}


got a similar error when I tried 'ppc' rather than 'powerpc'

I guess that isn't the only change I have to make. Any help would be
appreciated. Thanks

Cedar



this is the error I got:


make[2]: Leaving directory `/home/cedar/download/MC/libs/libavformat'
cd libmyth && make -f Makefile
make[2]: Entering directory `/home/cedar/download/MC/libs/libmyth'
qmake -o Makefile libmyth.pro
make[2]: Leaving directory `/home/cedar/download/MC/libs/libmyth'
make[2]: Entering directory `/home/cedar/download/MC/libs/libmyth'
g++ -c -pipe -Wall -W -O6 -march=powerpc -fomit-frame-pointer
-funroll-loops
-fexpensive-optimizations -D_REENTRANT -fPIC -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -DPREFIX=\"/usr/local\" -DMMX -DQT_NO_DEBUG
-DQT_THREAD_SUPPORT -I/usr/lib/qt3/mkspecs/default -I.
-I/usr/local/include
-I/usr/lib/qt3/include -o dialogbox.o dialogbox.cpp
cc1plus: invalid option `arch=powerpc'
make[2]: *** [dialogbox.o] Error 1
make[2]: Leaving directory `/home/cedar/download/MC/libs/libmyth'
make[1]: *** [sub-libmyth] Error 2
make[1]: Leaving directory `/home/cedar/download/MC/libs'
make: *** [sub-libs] Error 2
[cedar@localhost MC]$

>
> Okay, I'll catch up to the latest CVS, clean it up, and try
> and get something out late tonight.
>


Super, I'm looking forward to it.
Maybe at the same time you can enlighten me about this big-endian
issue. I've done a bit of poking around and found a couple of things
that suggest that PPC supports big _or_ little endian words. Here are a
couple of quotes I found on message boards:

> Since the Motorola 680x0 series was big endian, though the PowerPC can
> run in either mode, Apple uses the PowerPC in big endian mode. The
> IA32, by contrast, is little endian, and can only run in little-endian
> mode.

I also found this:

> the PowerPC can indeed manage either byte order, but some operations
> have extra boundary conditions in little-endian mode. <snip> it`s both
> possible and desirable to limit the endian-sensitivity of software to
> small parts of the kernel, small routines in the C library, and small
> parts of a few specialised applications. most programs shouldn`t be
> bothered about which scheme is in use. perhaps this is an appropriate
> time to encourage people to make the effort to use portable binary
> representations in files exported by a program (ie, non-temporary
> files).


I'm just curious why with whole distros and all their packages compiled
for PPC, why mythtv has a problem with this issue? Or did mandrake
have to patch/port all those packages, fixing the endian issue one
package at a time? Also, I've compiled a number of programs from source
on linux ppc and more often OS X and not run into this issue. What is
different about myth? Is it something inherent to writing a pvr
program, or is it just a failure to write portable code?


Finally, when I compile for ppc what else do I have to do other than
apply your endian patch? The compile error I posted earlier seemed to
suggest that I had not set the arch correctly? The heart of the error
seemed to be:
cc1plus: invalid option `arch=powerpc'
What does a correct settings.pro file look like when compiling for ppc?


thanks again for your help!


Cedar

Here are patches against CVS a few hours ago to make
mythfrontend work on PowerPC machines running Linux (tested on Debian
stable). I have also patched backend routines but have no way to test
them so they may be incomplete (x86 still works).

My 400MHz G4 can just about decode 480x480 mpeg4. Altivec
routines in libavcodec are unused (don't have a compiler that supports
them). Live previews are a bit garbled -- I think the patches to
yuv420_argb32_non_mmx are correct but my machine just can't keep up.

Developers, let me know if the changes should be done
differently. The edits to the .pro files to include config.mak are
ugly but it seems that nested includes with relative path names don't
work properly so including it from settings.pro didn't work. These
changes could be dropped if the user just edits settings.pro instead
of using the result "configure". Or maybe there's a cleaner way to do
this.

>>>>> On Mon, 14 Apr 2003 22:06:18 -0700, Cedar McKay <cedarmckay@mac.com> said:

c> Super, I'm looking forward to it.

I've just sent my patch to the list. Give it a try. I'm not
sure Isaac will accept it soon so I'd appreciate it if someone else
could test it. You can apply it with "patch -p0". For your G3, I
think you can edit "settings.pro" and change "-mcpu=7400" to
"-mcpu=750". Let me know if you run into problems.

c> Maybe at the same time you can enlighten me about this big-endian
c> issue. I've done a bit of poking around and found a couple of things
c> that suggest that PPC supports big _or_ little endian words. Here are
c> a couple of quotes I found on message boards:

Yes, the PowerPC can run in both modes but both Linux and
MacOS X use big-endian mode. I think little-endian mode is used in
some embedded systems.

MythTV is affected because the nuv file is a binary file which
has little-endian fields in some headers -- these fields need to be
byte-swapped so that they're interpreted correctly on PPC. The pixmap
RGB and sound stream formats are similarly affected.

MythTV is not really different from any other software that
reads/writes binary files. It's just that most Unix software works
because they've already been ported to big-endian machines (like Sun,
HP, and IBM workstations). For older stuff, they may have even been
developed on big-endian machines. I guess it's really only when new
binary file formats show up that some porting needs to be done. (I
remember when xmms would just generate screeching sounds on LinuxPPC!)
--
Gregorio Gervasio, Jr.
gtgj@pacbell.net

This is a terrific step! Congratulations..

Could this possibly lead to a port to TiVo's hardware? (ppc based, if
I'm not mistaken)?

On Mon, 2003-04-14 at 23:42, Gregorio Gervasio Jr. wrote:
> >>>>> On Mon, 14 Apr 2003 22:06:18 -0700, Cedar McKay <cedarmckay@mac.com> said:
>
> c> Super, I'm looking forward to it.
>
> I've just sent my patch to the list. Give it a try. I'm not
> sure Isaac will accept it soon so I'd appreciate it if someone else
> could test it. You can apply it with "patch -p0". For your G3, I
> think you can edit "settings.pro" and change "-mcpu=7400" to
> "-mcpu=750". Let me know if you run into problems.
>
> c> Maybe at the same time you can enlighten me about this big-endian
> c> issue. I've done a bit of poking around and found a couple of things
> c> that suggest that PPC supports big _or_ little endian words. Here are
> c> a couple of quotes I found on message boards:
>
> Yes, the PowerPC can run in both modes but both Linux and
> MacOS X use big-endian mode. I think little-endian mode is used in
> some embedded systems.
>
> MythTV is affected because the nuv file is a binary file which
> has little-endian fields in some headers -- these fields need to be
> byte-swapped so that they're interpreted correctly on PPC. The pixmap
> RGB and sound stream formats are similarly affected.
>
> MythTV is not really different from any other software that
> reads/writes binary files. It's just that most Unix software works
> because they've already been ported to big-endian machines (like Sun,
> HP, and IBM workstations). For older stuff, they may have even been
> developed on big-endian machines. I guess it's really only when new
> binary file formats show up that some porting needs to be done. (I
> remember when xmms would just generate screeching sounds on LinuxPPC!)
> --
> Gregorio Gervasio, Jr.
> gtgj@pacbell.net
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@snowman.net
> http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

On Tuesday 15 April 2003 09:58 am, Aaron Stewart wrote:
> This is a terrific step! Congratulations..
>
> Could this possibly lead to a port to TiVo's hardware? (ppc based, if
> I'm not mistaken)?

Not a chance.

Isaac

On Tuesday 15 April 2003 02:05 am, Gregorio Gervasio Jr. wrote:
> Developers, let me know if the changes should be done
> differently. The edits to the .pro files to include config.mak are
> ugly but it seems that nested includes with relative path names don't
> work properly so including it from settings.pro didn't work. These
> changes could be dropped if the user just edits settings.pro instead
> of using the result "configure". Or maybe there's a cleaner way to do
> this.

Wouldn't it be easier to byteswap the frameheaders on load/save? I know you
asked before, but..

Isaac

lol

-----Original Message-----
From: mythtv-users-bounces@snowman.net
[mailto:mythtv-users-bounces@snowman.net] On Behalf Of Isaac Richards
Sent: Tuesday, April 15, 2003 11:26 AM
To: Discussion about mythtv
Subject: Re: [mythtv-users] MythTV on PPC


On Tuesday 15 April 2003 09:58 am, Aaron Stewart wrote:
> This is a terrific step! Congratulations..
>
> Could this possibly lead to a port to TiVo's hardware? (ppc based, if
> I'm not mistaken)?

Not a chance.

Isaac

_______________________________________________
mythtv-users mailing list
mythtv-users@snowman.net
http://lists.snowman.net/cgi-bin/mailman/listinfo/mythtv-users

>>>>> On Tue, 15 Apr 2003 10:31:18 -0400, Isaac Richards <ijr@po.cwru.edu> said:

i> Wouldn't it be easier to byteswap the frameheaders on load/save? I
i> know you asked before, but..

I thought it might be better to keep the structure details in
format.h, but I agree it's less intrusive and probably safer to do
what you say. I'll change it and try again in a few days.
--
Gregorio Gervasio, Jr.
gtgj@pacbell.net

well, I had time to try out your patch. It applied cleanly and using
"750" for the arch seemed to do the right thing. Once installed I gave
it a whirl with mixed results. The frontend worked beautifully.
Watching a recording also yielded really great looking smooth playback
of my 480x480 mpeg4 recordings. I was pretty happy that my old 400mhz
imac could do that (and easily it seems!) However, recordings had
messed up sound. It sounded like HAL from 2001 when he is being shut
down. Slowwww and lowwww. Sounded like a drug trip. However, the sound
did seem to somewhat match the action.

Console showed this message:

[cedar@localhost cedar]$ mythfrontend
connecting to backend server: 192.168.1.102:6543
Setting PCM volume: : Invalid argument
Reading PCM volume: : Invalid argument
Changing from None to WatchingPreRecorded
audio device cannot report buffer state accurately,
audio/video sync will be bad, continuing anyway
Over/underscanning. V: 0.000000, H: 0.000000, XOff: 0, YOff: 0
Using XV port 61



Otherwise sound seems to work fine on this system with Mandrake 9.1. I
know that doesn't really make it myth's (or your patch's) fault yet,
because a lot of people seem to have working sound, but still have
trouble getting sound to work with mythtv. However, I'm not trying for
recording and playing at the same time so I don't need duplex, so I was
hoping it would just work. Any ideas?

I thought of manually installing alsa from source since that worked to
get my x86 mandrake 9.1 sound working with mythtv, where the included
alsa didn't work for me. But I don't know the name of the sound card in
this imac, and couldn't really figure it out from the sound cards page
on the alsa website, so i didn't do that.

Finally, here is my modules.conf file:

alias eth0 gmac
probeall usb-interface usb-ohci
alias ieee1394-controller ohci1394
alias sound-slot-0 dmasound_pmac


pretty simple eh? Anyway, if anyone has any advice, or success getting
this going on an imac, I would love to hear about it. In the meantime I
appreciate your work with the patches, I'm a lot closer than I was
before!


best,
Cedar

ps
Mandrake 9.1 seems really snappy on my imac! It rivals the
responsiveness and perceived quickness of my much faster amd system.
However that impression was different during the compile. That took a
really long time.

>>>>> On Tue, 15 Apr 2003 20:33:59 -0700, Cedar McKay <cedarmckay@mac.com> said:

[...]

c> Console showed this message:

c> [cedar@localhost cedar]$ mythfrontend
c> connecting to backend server: 192.168.1.102:6543
c> Setting PCM volume: : Invalid argument
c> Reading PCM volume: : Invalid argument
c> Changing from None to WatchingPreRecorded
c> audio device cannot report buffer state accurately,
c> audio/video sync will be bad, continuing anyway
c> Over/underscanning. V: 0.000000, H: 0.000000, XOff: 0, YOff: 0
c> Using XV port 61

I forgot to mention this. I had the same problem -- using
ALSA was the solution for me. You can build alsa-driver with:

./configure --with-cards=powermac

My modules.conf says:

alias char-major-116 snd
alias snd-card-0 snd-powermac
alias char-major-14 soundcore
alias sound-slot-0 snd-card-0
alias sound-service-0-0 snd-mixer-oss
alias sound-service-0-1 snd-seq-oss
alias sound-service-0-3 snd-pcm-oss
alias sound-service-0-8 snd-seq-oss
alias sound-service-0-12 snd-pcm-oss

--
Gregorio Gervasio, Jr.
gtgj@pacbell.net

I am trying to get MythTV compiled under Mandrake 9.1 PPC on my Ti-Powerbook
to use strictly as a frontend. I can't get the patch to apply cleanly
against the MythTV 0.80 release. Here is what I did:

*****************************************
[spumco@mypowerbook mythtv-0.8]$ patch -p0 < ppc-mythtv-20030414.patch
patching file settings.pro
patching file filters/invert/invert.pro
patching file filters/linearblend/linearblend.pro
patching file libs/libavcodec/libavcodec.pro
Hunk #2 succeeded at 79 (offset -1 lines).
patching file libs/libmyth/libmyth.pro
patching file libs/libmythtv/NuppelVideoPlayer.cpp
Hunk #1 succeeded at 113 (offset 11 lines).
Hunk #2 succeeded at 342 (offset 25 lines).
Hunk #3 succeeded at 3421 (offset 829 lines).
Hunk #4 succeeded at 3449 (offset 829 lines).
Hunk #5 succeeded at 3467 (offset 829 lines).
patching file libs/libmythtv/NuppelVideoPlayer.h
Hunk #1 succeeded at 232 (offset 1 line).
patching file libs/libmythtv/NuppelVideoRecorder.cpp
Hunk #1 FAILED at 1220.
Hunk #2 succeeded at 1173 (offset -75 lines).
Hunk #3 succeeded at 1182 (offset -75 lines).
Hunk #4 succeeded at 1206 (offset -75 lines).
Hunk #5 succeeded at 1217 (offset -75 lines).
Hunk #6 succeeded at 1236 (offset -75 lines).
Hunk #7 succeeded at 1284 (offset -75 lines).
Hunk #8 succeeded at 1293 (offset -75 lines).
Hunk #9 succeeded at 1305 (offset -75 lines).
Hunk #10 succeeded at 1903 (offset -339 lines).
Hunk #11 succeeded at 1983 (offset -675 lines).
Hunk #12 FAILED at 2077.
Hunk #13 FAILED at 2090.
Hunk #14 FAILED at 2100.
Hunk #15 FAILED at 2124.
Hunk #16 succeeded at 2152 (offset -665 lines).
Hunk #17 succeeded at 2192 (offset -665 lines).
Hunk #18 succeeded at 2257 (offset -665 lines).
Hunk #19 succeeded at 2270 (offset -665 lines).
Hunk #20 succeeded at 2284 (offset -665 lines).
Hunk #21 FAILED at 2299.
6 out of 21 hunks FAILED -- saving rejects to file
libs/libmythtv/NuppelVideoRecorder.cpp.rej
patching file libs/libmythtv/RTjpegN.h
patching file libs/libmythtv/format.h
patching file libs/libmythtv/libmythtv.pro
Hunk #1 succeeded at 6 with fuzz 1.
can't find file to patch at input line 842
Perhaps you used the wrong -p or --strip option?
The text leading up to this was:
--------------------------
|Index: libs/libmythtv/nuppeldecoder.cpp
|===================================================================
|RCS file: /var/lib/cvs/MC/libs/libmythtv/nuppeldecoder.cpp,v
|retrieving revision 1.5
|diff -u -b -r1.5 nuppeldecoder.cpp
|--- libs/libmythtv/nuppeldecoder.cpp 14 Apr 2003 22:11:12 -0000 1.5
|+++ libs/libmythtv/nuppeldecoder.cpp 15 Apr 2003 00:57:17 -0000
--------------------------
File to patch:
Skip this patch? [y]
Skipping patch.
28 out of 28 hunks ignored
patching file libs/libmythtv/yuv2rgb.cpp
patching file libs/libvbitext/libvbitext.pro
patching file programs/menutest/menutest.pro
patching file programs/mythbackend/mythbackend.pro
patching file programs/mythepg/mythepg.pro
patching file programs/mythfilldatabase/mythfilldatabase.pro
patching file programs/mythfrontend/mythfrontend.pro
Hunk #2 FAILED at 23.
1 out of 2 hunks FAILED -- saving rejects to file
programs/mythfrontend/mythfrontend.pro.rej
patching file programs/mythprogfind/mythprogfind.pro
patching file programs/mythtv/mythtv.pro
patching file setup/setup.pro
patching file themes/themes.pro
*****************************************

Obviously, it won't compile after applying the patch. Does anyone have any
suggestions?

Thanks,

Patrick Benton



--Begin-Quote-------------------------------------------------
I've just sent my patch to the list. Give it a try. I'm not
sure Isaac will accept it soon so I'd appreciate it if someone else
could test it. You can apply it with "patch -p0". For your G3, I
think you can edit "settings.pro" and change "-mcpu=7400" to
"-mcpu=750". Let me know if you run into problems.

c> Maybe at the same time you can enlighten me about this big-endian
c> issue. I've done a bit of poking around and found a couple of things
c> that suggest that PPC supports big _or_ little endian words. Here are
c> a couple of quotes I found on message boards:

Yes, the PowerPC can run in both modes but both Linux and
MacOS X use big-endian mode. I think little-endian mode is used in
some embedded systems.

MythTV is affected because the nuv file is a binary file which
has little-endian fields in some headers -- these fields need to be
byte-swapped so that they're interpreted correctly on PPC. The pixmap
RGB and sound stream formats are similarly affected.

MythTV is not really different from any other software that
reads/writes binary files. It's just that most Unix software works
because they've already been ported to big-endian machines (like Sun,
HP, and IBM workstations). For older stuff, they may have even been
developed on big-endian machines. I guess it's really only when new
binary file formats show up that some porting needs to be done. (I
remember when xmms would just generate screeching sounds on LinuxPPC!)
--
Gervasio, Jr.
gtgj@pacbell.net

>>>>> On Thu, 22 May 2003 18:12:50 -0400, Patrick Benton <patrickb@umich.edu> said:

p> I am trying to get MythTV compiled under Mandrake 9.1 PPC on my Ti-Powerbook
p> to use strictly as a frontend. I can't get the patch to apply cleanly
p> against the MythTV 0.80 release. Here is what I did:

p> *****************************************
p> [spumco@mypowerbook mythtv-0.8]$ patch -p0 < ppc-mythtv-20030414.patch

[...]

Yes, you'll need CVS from around that time to use that patch
(which might be difficult due to the repository change). I
occasionally update my local tree and can try to generate patches for
more recent CVS builds if you're interested.
--
Gregorio Gervasio, Jr.
gtgj@pacbell.net

On Friday 23 May 2003 2:34 am, Gregorio Gervasio Jr. wrote:
> Yes, you'll need CVS from around that time to use that patch
> (which might be difficult due to the repository change). I
> occasionally update my local tree and can try to generate patches for
> more recent CVS builds if you're interested.

Thank you for you help! I think I'm headed in the right direction now. After
doing:

$ cvs -z3 -d :pserver:mythtv@cvs.mythtv.org:/var/lib/mythcvs checkout
-D2003/4/14 mythtv

I seem to get the correctly dated CVS. Running the patch works almost
flawlessly this time with just one failure:

---------snip---------
patching file programs/mythfrontend/mythfrontend.pro
Hunk #2 FAILED at 23.
1 out of 2 hunks FAILED -- saving rejects to file
programs/mythfrontend/mythfrontend.pro.rej
---------snip---------

On compile I get the following:

---------snip---------
make[1]: Entering directory `/home/spumco/myth/mythtv/programs'
cd mythepg && qmake -o Makefile
cd mythepg && make -f Makefile
make[2]: Entering directory `/home/spumco/myth/mythtv/programs/mythepg'
g++ -c -pipe -Wall -W -O6 -fomit-frame-pointer -funroll-loops
-fexpensive-optimizations -mcpu=7400 -D_REENTRANT -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -DPREFIX=\"/usr/local\" -DQT_NO_DEBUG
-DQT_THREAD_SUPPORT -I/usr/lib/qt3/mkspecs/default -I. -I/usr/local/include
-I../../libs -I../../libs/libmyth -I/usr/lib/qt3/include -o main.o main.cpp
main.cpp: In function `int main(int, char**)':
main.cpp:16: no matching function for call to `MythContext::MythContext()'
../../libs/libmyth/mythcontext.h:50: candidates are:
MythContext::MythContext(const MythContext&)
../../libs/libmyth/mythcontext.h:53:
MythContext::MythContext(const QString&, bool = true)
make[2]: *** [main.o] Error 1
make[2]: Leaving directory `/home/spumco/myth/mythtv/programs/mythepg'
make[1]: *** [sub-mythepg] Error 2
make[1]: Leaving directory `/home/spumco/myth/mythtv/programs'
make: *** [sub-programs] Error 2
[spumco@mypowerbook mythtv]$
---------snip---------

This there something I am missing here?

Thanks again for your assistance. I want to make sure I exhaust my options
with this current patch before requesting that you try to make another.

-Patrick

On Friday 23 May 2003 5:55 pm, you wrote:
> I didn't make that many changes to that file so it should be
> easy to manually apply the patch. Just take a look at what the .rej
> file says.

Done. That part was easier that I thought!

> p> main.cpp: In function `int main(int, char**)':
> p> main.cpp:16: no matching function for call to
> `MythContext::MythContext()'
>
> I think this may be a problem with loss of history after the
> CVS repository was restored. Try changing that line to:
>
> gContext = new MythContext(MYTH_BINARY_VERSION);

After making that change in mythtv/main.cpp, it compiled on and gave me the
same error for mythepg/main.cpp, so I made the same change to that file.
That brings me to the latest error:

-------snip--------
[spumco@mypowerbook mythtv]$ make
cd libs && make -f Makefile
make[1]: Entering directory `/home/spumco/myth/mythtv/libs'
cd libavcodec && make -f Makefile
make[2]: Entering directory `/home/spumco/myth/mythtv/libs/libavcodec'
make[2]: Nothing to be done for `first'.
make[2]: Leaving directory `/home/spumco/myth/mythtv/libs/libavcodec'
cd libavformat && make -f Makefile
make[2]: Entering directory `/home/spumco/myth/mythtv/libs/libavformat'
make[2]: Nothing to be done for `first'.
make[2]: Leaving directory `/home/spumco/myth/mythtv/libs/libavformat'
cd libmyth && make -f Makefile
make[2]: Entering directory `/home/spumco/myth/mythtv/libs/libmyth'
make[2]: Nothing to be done for `first'.
make[2]: Leaving directory `/home/spumco/myth/mythtv/libs/libmyth'
cd libvbitext && make -f Makefile
make[2]: Entering directory `/home/spumco/myth/mythtv/libs/libvbitext'
make[2]: Nothing to be done for `first'.
make[2]: Leaving directory `/home/spumco/myth/mythtv/libs/libvbitext'
cd libmythtv && make -f Makefile
make[2]: Entering directory `/home/spumco/myth/mythtv/libs/libmythtv'
make[2]: Nothing to be done for `first'.
make[2]: Leaving directory `/home/spumco/myth/mythtv/libs/libmythtv'
make[1]: Leaving directory `/home/spumco/myth/mythtv/libs'
cd filters && make -f Makefile
make[1]: Entering directory `/home/spumco/myth/mythtv/filters'
cd invert && make -f Makefile
make[2]: Entering directory `/home/spumco/myth/mythtv/filters/invert'
make[2]: Nothing to be done for `first'.
make[2]: Leaving directory `/home/spumco/myth/mythtv/filters/invert'
cd linearblend && make -f Makefile
make[2]: Entering directory `/home/spumco/myth/mythtv/filters/linearblend'
make[2]: Nothing to be done for `first'.
make[2]: Leaving directory `/home/spumco/myth/mythtv/filters/linearblend'
make[1]: Leaving directory `/home/spumco/myth/mythtv/filters'
cd programs && make -f Makefile
make[1]: Entering directory `/home/spumco/myth/mythtv/programs'
cd mythepg && make -f Makefile
make[2]: Entering directory `/home/spumco/myth/mythtv/programs/mythepg'
g++ -c -pipe -Wall -W -O6 -fomit-frame-pointer -funroll-loops
-fexpensive-optimizations -mcpu=7400 -D_REENTRANT -D_GNU_SOURCE
-D_FILE_OFFSET_BITS=64 -DPREFIX=\"/usr/local\" -DQT_NO_DEBUG
-DQT_THREAD_SUPPORT -I/usr/lib/qt3/mkspecs/default -I. -I/usr/local/include
-I../../libs -I../../libs/libmyth -I/usr/lib/qt3/include -o main.o main.cpp
g++ -o mythepg main.o -L/usr/lib/qt3/lib -L/usr/X11R6/lib
-L../../libs/libmyth -L../../libs/libmythtv -L../../libs/libavcodec
-L../../libs/libvbitext -lmythtv -lavcodec -lvbitext -lmyth-0.9 -lXv
-lXinerama -lmp3lame -lqt-mt -lXext -lX11 -lm -lpthread
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x164): In function
`AvFormatDecoder::~AvFormatDecoder [not-in-charge]()':
: undefined reference to `av_close_input_file'
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x164): In function
`AvFormatDecoder::~AvFormatDecoder [not-in-charge]()':
: relocation truncated to fit: R_PPC_REL24 av_close_input_file
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x1c4): In function
`AvFormatDecoder::~AvFormatDecoder [in-charge]()':
: undefined reference to `av_close_input_file'
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x1c4): In function
`AvFormatDecoder::~AvFormatDecoder [in-charge]()':
: relocation truncated to fit: R_PPC_REL24 av_close_input_file
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x228): In function
`AvFormatDecoder::~AvFormatDecoder [in-charge deleting]()':
: undefined reference to `av_close_input_file'
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x228): In function
`AvFormatDecoder::~AvFormatDecoder [in-charge deleting]()':
: relocation truncated to fit: R_PPC_REL24 av_close_input_file
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x34c): In function
`AvFormatDecoder::CanHandle(char*, QString const&)':
: undefined reference to `av_register_all'
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x34c): In function
`AvFormatDecoder::CanHandle(char*, QString const&)':
: relocation truncated to fit: R_PPC_REL24 av_register_all
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x374): In function
`AvFormatDecoder::CanHandle(char*, QString const&)':
: undefined reference to `av_probe_input_format'
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x374): In function
`AvFormatDecoder::CanHandle(char*, QString const&)':
: relocation truncated to fit: R_PPC_REL24 av_probe_input_format
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x5a8): In function
`AvFormatDecoder::OpenFile(RingBuffer*, bool, char*)':
: undefined reference to `av_probe_input_format'
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x5a8): In function
`AvFormatDecoder::OpenFile(RingBuffer*, bool, char*)':
: relocation truncated to fit: R_PPC_REL24 av_probe_input_format
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x708): In function
`AvFormatDecoder::OpenFile(RingBuffer*, bool, char*)':
: undefined reference to `av_open_input_file'
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x708): In function
`AvFormatDecoder::OpenFile(RingBuffer*, bool, char*)':
: relocation truncated to fit: R_PPC_REL24 av_open_input_file
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x71c): In function
`AvFormatDecoder::OpenFile(RingBuffer*, bool, char*)':
: undefined reference to `av_find_stream_info'
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x71c): In function
`AvFormatDecoder::OpenFile(RingBuffer*, bool, char*)':
: relocation truncated to fit: R_PPC_REL24 av_find_stream_info
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x820): In function
`AvFormatDecoder::OpenFile(RingBuffer*, bool, char*)':
: undefined reference to `dump_format'
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x820): In function
`AvFormatDecoder::OpenFile(RingBuffer*, bool, char*)':
: relocation truncated to fit: R_PPC_REL24 dump_format
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0xba8): In function
`AvFormatDecoder::GetFrame(int)':
: undefined reference to `av_read_packet'
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0xba8): In function
`AvFormatDecoder::GetFrame(int)':
: relocation truncated to fit: R_PPC_REL24 av_read_packet
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x1080): In function
`avf_write_packet(void*, unsigned char*, int)':
: undefined reference to `url_write'
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x1080): In function
`avf_write_packet(void*, unsigned char*, int)':
: relocation truncated to fit: R_PPC_REL24 url_write
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x10a0): In function
`avf_read_packet(void*, unsigned char*, int)':
: undefined reference to `url_read'
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x10a0): In function
`avf_read_packet(void*, unsigned char*, int)':
: relocation truncated to fit: R_PPC_REL24 url_read
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x10c0): In function
`avf_seek_packet(void*, long long, int)':
: undefined reference to `url_seek'
../../libs/libmythtv/libmythtv.a(avformatdecoder.o)(.text+0x10c0): In function
`avf_seek_packet(void*, long long, int)':
: relocation truncated to fit: R_PPC_REL24 url_seek
collect2: ld returned 1 exit status
make[2]: *** [mythepg] Error 1
make[2]: Leaving directory `/home/spumco/myth/mythtv/programs/mythepg'
make[1]: *** [sub-mythepg] Error 2
make[1]: Leaving directory `/home/spumco/myth/mythtv/programs'
make: *** [sub-programs] Error 2
[spumco@mypowerbook mythtv]$
-------snip--------

At this point, would it be easier to have you generate a patch for a version
of MythTV after the CVS change? I would be very interested in that if you
think continuing with this current patch is too much of a hassle.

Thank you very much for your help and time. It is much appreciated!!! I'm
very excited about getting MythTV to work on my Powerbook via 802.11b. Once
I get it compiled, I'll let you know if the video preview works correctly.

Thanks again,

Patrick

Gregorio,

Your patched applied cleanly and mythtv compiled just fine, but I'm
having trouble connecting to my master-backend. So as soon as I get
that fixed, I'll let you know if the video preview works.

Thank you for providing that patch!

Patrick
On Wednesday, April 16, 2003, at 01:52 AM, Gregorio Gervasio Jr. wrote:

>>>>>> On Tue, 15 Apr 2003 20:33:59 -0700, Cedar McKay
>>>>>> <cedarmckay@mac.com> said:
>
> [...]
>
> c> Console showed this message:
>
> c> [cedar@localhost cedar]$ mythfrontend
> c> connecting to backend server: 192.168.1.102:6543
> c> Setting PCM volume: : Invalid argument
> c> Reading PCM volume: : Invalid argument