[mythtv] Firewire STB keeps jumping ports in 0.21-fixes. Suggestions?

Steven Adeff adeffs.mythtv at gmail.com
Mon Mar 17 18:29:58 UTC 2008


On Fri, Mar 14, 2008 at 6:39 PM, William Munson
<william_munson at comcast.net> wrote:
> 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.

as of 0.21 you can have mythbackend reset the bus, have you tried this
yet? It was technically in SVN for a while without a gui, but if you
have more than one box and reset the bus then you'll lose any other
recordings you have going on, which is why I opted to not use it and
went with my script.

-- 
Steve


More information about the mythtv-dev mailing list