[mythtv] Firewire STB keeps jumping ports in 0.21-fixes. Suggestions?
William Munson
william_munson at comcast.net
Fri Mar 14 22:39:08 UTC 2008
Simon Koch wrote:
>
>
> On Wed, Feb 20, 2008 at 4:29 PM, Steven Adeff <adeffs.mythtv at gmail.com
> <mailto:adeffs.mythtv at gmail.com>> wrote:
>
> On Feb 17, 2008 9:26 AM, William Munson <w.munson at comcast.net
> <mailto:w.munson at comcast.net>> wrote:
> >
> > Daniel Kristjansson wrote:
> > > On Sat, 2008-02-16 at 22:03 -0500, William Munson wrote:
> > >
> > >> First off, sorry to post this to the dev list however I have
> not gotten
> > >> any answers in the users list.
> > >>
> > >> I am testing the 0.21-fixes branch on ubuntu and am running
> into a
> > >> situation where if I accidentally tune a bad channel with my
> DCT6416 STB
> > >> it will cause the STB to switch ports from 1 to 0 and back
> again. The
> > >> port is still stable and firewire_tester will still capture
> packets in
> > >> broadcast mode just fine however the backend does not realize
> that the
> > >> port has moved even though the UUID is still the same. Am I
> missing
> > >> something or is there a bug that causes the backend end to
> miss the fact
> > >> that the port has changed? What can I do to troubleshoot this and
> > >> provide more useful info?
> > >>
> > >
> > > LinuxFirewireDevice::UpdateDeviceListItem() should update the
> device
> > > list when there is a reset, and
> LinuxFirewireDevice::HandleBusReset()
> > > should reconnect the device when it calls
> iec61883_cmp_reconnect(),
> > > but it doesn't always work. The Linux firewire guys weren't too
> > > interested in fixing this driver problem when I discovered it
> (though
> > > they were helpful in many ways with the firewire code.) They were
> > > working on a new driver which I understand should be immune to
> these
> > > types of problems. I no longer use the firewire recorder, so
> this is
> > > not something I've looked into further.
> > >
> > > The OSX FirewireRecorder does recover in these instances. But
> it has
> > > it's own problems. The OSX driver devs decided to always issue
> a bus
> > > reset when an application starts or stops using firewire, so
> you end
> > > up losing portions of your recordings if you have more than
> one STB
> > > or have some other firewire devices on the same bus.
> > >
> > > The upshot is that AFAICT the bug is in the Linux Firewire
> drivers and
> > > not in MythTV; unless you track down the bug in the drivers
> yourself
> > > it is not likely to be fixed until the whole firewire driver
> stack is
> > > replaced with the next generation firewire stack. BUT, it has
> been a
> > > while since I've been on top of this so you might want to read
> up on
> > > the posts in the linux1394-devel at lists.sourceforge.net
> <mailto:linux1394-devel at lists.sourceforge.net> the next gen
> > > driver might be in a usable state at this point, or it might
> have been
> > > abandoned, and/or someone might have written some patches to
> fix the
> > > problem in the existing drivers.
> > >
> > > Searching the linux1394 mailing list for "bus reset" might
> give you
> > > something useful...
> > >
> > > -- Daniel
> > >
> > >
> >
> > Thank you for the info. One more question. Is there a location
> in the
> > database that stores the current port? I was thinking of writing a
> > channel change script that would take a look at plugreport on each
> > channel change and update the database before changing channels.
> If myth
> > looks at this variable when setting up a recording then I could
> > dynamically update things whenever I change channel. It would
> also allow
> > me to stabilize the connection if required. This looks to be
> easier than
> > trying to patch the ubuntu 1394 stack.
> >
> > TIA,
> > William
>
> I have a channel change script that uses the Firewire GUID for the box
> in question to change the channel. It doesn't affect the database but
> since I've started using it (to fix 0-byte recordings) I've yet to
> miss a firewire recording. The downside is you have to manually give
> mythtv-setup the GUID of the box in the channel changer field, but
> otherwise it works great.
>
> http://www.mythtv.org/wiki/index.php/User:Steveadeff#6200changer.sh
>
> --
> Steve
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org <mailto:mythtv-dev at mythtv.org>
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>
> I have a similar script. I made 2 wrappers around it, each with the
> GUID of one of my cable boxes. I found that slightly more convenient
> than typing them in in mythtv-setup.
>
> Simon
Looks like we all had slightly different solutions. Since I only have
one stb I wrote a script that checks plugreport to find the node by GUID
then resets that port/node before changing channels. So far its recorded
everything as requested. I have that capture device set as my primary
signal source with my pvr-250's as backup so it sees lots of activity.
If anyone is interested I will post the script.
William
More information about the mythtv-dev
mailing list