Jim,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!
josh. 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 thisseems 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 [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 alittle 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 JoshI 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 itworking 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 [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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 timethe 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 notjust me. I suspect that it is not an issue with MythTV per se. I have alsoobserved 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 (picturefreezes and audio stops for a second, then continues). This happenswhether 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 failsmuch 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 rathersee a workaround in software.Could someone who is familiar with the firewire STB support in mythtvlet 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 [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
_______________________________________________ mythtv-dev mailing list [email protected] http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
