[mythtv] Debugging Unreliable DCT-6200 Recording

jrandall at ftrd.us jrandall at ftrd.us
Fri Sep 23 19:41:10 UTC 2005


Thanks!  I had been using P2P connection type with myth and now using  
broadcast it works.  I also think I understand more of what it going  
on at a low level.  I've been doing a lot of testing with  
libiec61883 / test-mpeg2 to see what exactly changes between good a  
bad trials.

What seems to be going on is that the CMP (connection management  
protocol) function that creates p2p output  
(iec61883_cmp_create_p2p_output) only works about half the time, and  
is what needs to keep being retried to get it going.  Once it is  
going, one can use iec61883_cmp_overlay_p2p_output instead of the  
create function to get the already-working connection on the same  
channel.  I'm currently looking for a way to tell if the p2p  
connection is good before actually trying to receive data from it.   
If that is possible, the fix probably belongs in libiec61883.  If it  
isn't possible, the fix would be more appropriate for myth -- it can  
just detect that it isn't reading from the stream and reset the p2p  
output using CMP.

Your workaround (using broadcast) seems to work 100% once you get it  
going, but it would still be good to fix the bug so that myth can  
start up on it's own!


On Sep 23, 2005, at 11:53 AM, Jim Westfall wrote:

> You have mythtv setup using broadcast firewire connection type?
> test-mpeg2 -r 1 > blah.ts uses a peer to peer connection type.   
> Doing this
> seems to initialize something in the driver or dct-6200 and it ends up
> making a boardcast connection work 100% after that.
> I know a few people that use the workaround that I do and it works for
> them as well.
> jim
> jrandall at ftrd.us <jrandall at ftrd.us> wrote [09.23.05]:
>> Jim,
>> Thanks for the input on this.
>> For me, your fix only works for live tv.  I had been doing basically
>> the same thing before, although it's usually faster for me to skip
>> using test-mpeg2 and just go for a few tries with mythfrontend.  The
>> timeout is longer, but I haven't observed any relationship between
>> getting things going correctly with test-mpeg2 and then having them
>> subsequently work in myth.  I am seeing about 50% failure and haven't
>> detected any sort of pattern, although perhaps I will write up a
>> little script and let it go a few hundred trials just to check on  
>> that.
>> Once livetv starts working, it is true that you are "all set" in the
>> sense that you can (it seems) continue to watch live tv indefinitely,
>> change channels, etc without any problem.  However, if you want to
>> record it is still 50% odds that it works.  Even if you are watching
>> livetv and push the 'r'ecord button, it seems that it resets the
>> connection when switching to record mode and there's a good chance it
>> won't work.
>> I suppose another option for a workaround would be to just keep the
>> transport stream open once it is working (just like live tv does when
>> changing channels).  We could look for a way to hand off the open
>> firewire stream to the recording process rather than having it
>> reinitialized every time.
>> But that would still require human intervention to get things going
>> in the first place.  I'm going to try to hack up a way for the
>> firewire code to detect when the transport stream connection isn't
>> working and give a few tries at reinitializing it before giving up.
>> It looks like libs/libmythtv/firewirerecorder.cpp is the place to do
>> this, so that's where I'm headed.
>> I just noticed that there is a bug tracking system, but didn't see a
>> bug for this yet.  Should we add one so we'll have a place to submit
>> the patch?  It'll be good to have others who have this problem to
>> test and make sure it solves it for more than just me.
>> Josh.
>> On Sep 22, 2005, at 8:16 PM, Jim Westfall wrote:
>>> Hi Josh
>>> I have this issue as well on one of my dct-6200's.  I havent had  
>>> time
>>> to see what the exact cause it, but the following work around  
>>> gets it
>>> working 100% for me.
>>> make sure your firewire connection type is set to broadcast in
>>> mythsetup.
>>> run 'test-mpeg2 -r 1 > test.ts' over and over until you get
>>> output.  once
>>> you get output stop test-mpeg2 then attempt to watch livetv in
>>> myth.  If
>>> livetv works you should be all set.  If not, you will need to
>>> repeat the
>>> process until it does.  It will usually take me a few (less then
>>> 10) tries
>>> to get it in a working state.
>>> This process should only be required if you reboot your box or
>>> dct-6200.
>>> jim
>>> jrandall at ftrd.us <jrandall at ftrd.us> wrote [09.22.05]:
>>>> I'm having intermittent trouble recording with my DCT-6200 cable  
>>>> box
>>>> connected via firewire.  Basically it seems like about half the  
>>>> time
>>>> the program/live tv doesn't start coming in.  For example, when you
>>>> select "Watch TV" the screen just goes blank for a little while and
>>>> then returns.  If you try a few times, it always starts working
>>>> eventually, but it is much more of a problem for recording -- which
>>>> fails completely half the time.
>>>> I have seen other people posting similar issues, so I know it is  
>>>> not
>>>> just me.
>>>> I suspect that it is not an issue with MythTV per se.  I have also
>>>> observed this phenomenon when using the test-mpeg2 utility that  
>>>> comes
>>>> with libiec61883.  Basically, running "test-mpeg2 -r 1 > /tmp/ 
>>>> foo.ts"
>>>> will either start to fill up the file or will leave a 0 byte file
>>>> "forever".  Either way, test-mpeg2 says "...Established
>>>> Connection..." and "Starting to receive" -- it doesn't seem to know
>>>> whether data is actually coming or not.  I also have my DCT-6200
>>>> connected directly to a TV for debugging, and I note that it always
>>>> glitches a little whenever you start capturing from it (picture
>>>> freezes and audio stops for a second, then continues).  This  
>>>> happens
>>>> whether the data is transmitted or not.
>>>> When the connection is not working, mythbackend says:
>>>> "Firewire: No Input in 15 seconds [P:1 N:1] (select)"
>>>> followed by:
>>>> "RingBuffer: Couldn't read data from the capture card in 15  
>>>> seconds.
>>>> Stopping."
>>>> Once data starts flowing, I have never observed any problems,  
>>>> but as
>>>> I said, it has this problem about 50% of the time.  When using  
>>>> test-
>>>> mpeg2 to capture, it isn't really a problem, since I note right  
>>>> away
>>>> that no data is flowing and retry until it works.  But, mythtv  
>>>> fails
>>>> much harder.  It takes many seconds to timeout on live tv before
>>>> letting you retry, and has the problem on channel changing as well.
>>>> And recording shows only works about half the time, because it is
>>>> either go or no-go... there seems to be no retry possible.
>>>> How should I go about debugging/fixing this?
>>>> We could probably add a way to detect that no data is flowing over
>>>> firewire after the receive connection has been established and then
>>>> retry the connection, but should this problem be fixed here or at a
>>>> lower level (such as in libiec61883?).  Unfortunately, the
>>>> linux1394.org server still seems to be down, so I can't check the
>>>> buglist there to see if this is a known problem or not.
>>>> It seems probable that the real problem here is with the  
>>>> firmware in
>>>> my cable box, but since it is not up to me to update that, I'd  
>>>> rather
>>>> see a workaround in software.
>>>> Could someone who is familiar with the firewire STB support in  
>>>> mythtv
>>>> let me know where the best place would be to put the fix?  I can
>>>> start hacking around, but I'd rather do it "right" the first time.
>>>> Thanks,
>>>> Josh.
>>>> _______________________________________________
>>>> mythtv-dev mailing list
>>>> mythtv-dev at mythtv.org
>>>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>>> _______________________________________________
>>> mythtv-dev mailing list
>>> mythtv-dev at mythtv.org
>>> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

More information about the mythtv-dev mailing list