jarod at wilsonet
Dec 12, 2008, 12:51 PM
Post #5 of 7
(1164 views)
Permalink
|
|
Re: mythtv finally works w/new firewire stack
[In reply to]
|
|
On Fri, 2008-12-12 at 22:09 +0200, Axel Thimm wrote:
> On Fri, Dec 12, 2008 at 02:39:12PM -0500, Jarod Wilson wrote:
> > On Fri, 2008-12-12 at 20:46 +0200, Axel Thimm wrote:
> > > Hi,
> > >
> > > On Fri, Dec 12, 2008 at 01:01:08AM -0500, Jarod Wilson wrote:
> > > > So... I *finally* have had some time to beat on firewire again... A few
> > > > patches to libraw1394 and one to mythtv, and now things finally work
^^^^^^^^^^^^^
> > > > using the juju firewire stack with firewire cable boxes.
> > > > libraw1394-2.0.0-5 for f10 and rawhide and libraw1394-1.3.0-11 for f9
> > > > have the necessary fixes, and I just committed the necessary mythtv
> > > > fixes to mythtv svn tonight.
> > >
> > > is this API/ABI compatible or does one need to rebuild mythtv and all
> > > packages depending on libraw1394?
> >
> > Its all API/ABI compatible, but the new libraw1394 packages have already
> > been pushed as stable updates, and you obviously need to rebuild MythTV
> > to get the benefit of the MythTV patch, so I presume you'd wind up
> > building w/the new one anyway. :)
>
> I'm not quite sure I understand - API/ABI compatible would mean that I
> *don't* have to build mythtv or any other dependent package, or not?
You *do* have to rebuild mythtv. See above... :)
And/or here:
http://svn.mythtv.org/trac/changeset/19342/branches/release-0-21-fixes/mythtv/libs
That patch is required, or mythbackend will segfault whenever the mpeg
stream gets out of sync, even with the latest and greatest libraw1394.
There were actually three separate issues recently fixed:
1) libraw1394 + juju was screwing up reporting back allocated iso
channel number, so iso receive was starting up, but would frequently
report back that it was running on channel -1, which is bogus (only 0-63
are valid), and mythtv would catch the -1 and inform you things were not
working. This was fixed in libraw1394-2.0.0-4.
2) libraw1394 + juju wasn't properly handling iso start/stop/start
sequences on the same firewire handle. dvgrab and kino were fine,
because every time you do an iso stop, you also destroy the firewire
handle, so the next time you start up, you're working on a freshly
allocated handle. Myth allocates a handle, starts up iso reception,
checks that we've got a valid stream, stops iso, then starts up the iso
stream again for recording or livetv. This is what was fixed in
libraw1394-2.0.0-5.
3) whenever the mpeg stream gets out of sync, mythtv was overwriting the
current sync byte in the incoming iso buffer with a non-sync-byte value
to trigger a resync of the stream on the next iteration of the stream
processor. With juju, the buffer is read-only to userspace, only
writeable by the firewire controller, so that write attempt by userspace
(mythtv) lead to a segfault. So I patched mythtv to set a resync flag
instead of trying to scribble on the stream as a work-around. (Some
might argue this is really a driver bug, but krh says this is by design,
its one of the features that makes throughput w/juju so much better -- a
single iso ring buffer simply mapped out to userspace for reads, vs.
memcpy'ing every packet out to userspace to do with as it pleases.)
So yeah, the new libraw1394 is API/ABI compatible, but you do still need
to rebuild MythTV to get thing all the way working, after adding that
patch. :)
--jarod
_______________________________________________
atrpms-devel mailing list
atrpms-devel [at] atrpms
http://lists.atrpms.net/mailman/listinfo/atrpms-devel
|
