Difference between revisions of "Talk:FireWire"

From MythTV Official Wiki
Jump to: navigation, search
Line 13: Line 13:
 
::Yes, they've gone away.  I did have them to begin with, but I'm now skeptical of whether it had anything to do with the firewire driver.  I can routinely cause the glitches by using startx instead of X&;mythfrontend&.  I noticed my xinitrc has a nice -n -2 mythfrontend in it.  I'm going to try to isolate whether the nice -n -2 was causing the problem or not.  I'll have more info soon! --[[User:Mmead|mmead]] 13:38, 25 April 2006 (UTC)
 
::Yes, they've gone away.  I did have them to begin with, but I'm now skeptical of whether it had anything to do with the firewire driver.  I can routinely cause the glitches by using startx instead of X&;mythfrontend&.  I noticed my xinitrc has a nice -n -2 mythfrontend in it.  I'm going to try to isolate whether the nice -n -2 was causing the problem or not.  I'll have more info soon! --[[User:Mmead|mmead]] 13:38, 25 April 2006 (UTC)
 
:::Please do, and to the mailinglist as well.--[[User:Steveadeff|Steveadeff]] 17:18, 25 April 2006 (UTC)
 
:::Please do, and to the mailinglist as well.--[[User:Steveadeff|Steveadeff]] 17:18, 25 April 2006 (UTC)
 +
::::Ok, sent a post to the mailing list.  I'm certain the nice -n -2 mythfrontend was contributory to my problems. --[[User:Mmead|mmead]] 18:29, 27 April 2006 (UTC)

Revision as of 18:29, 27 April 2006

this is all technically not needed. Motorola boxes should be set up with broadcast connection and 400mbps. If channel tuning fails, use the 6200ch in the contrib folder and specify the "new" method.--Steveadeff 22:22, 22 February 2006 (UTC)

Sorry Steve, but I've been using 6200ch since you recommended it and still have had to fiddle with the plugctl script at least once to restore connectivity with one of my two cable boxes. (Sadly, the number of (infrequent, but still annoying) failed channel changes hasn't gone down, either.) YLee 16:35, 8 March 2006 (UTC)
YLee, you need to set it to Broadcast/400mbps, shutdown the mythbox, unplug the cable box and then turn them all back on. This should fix any issues with streaming data from the box. As to channel tuning, I can't understand whats wrong unless your not passing the correct parameters to 6200ch. It has two possible methods, one is how Myth changes channels internally, the other is a different method only found in 6200ch. If neither work and your setting the node,etc correct then all I can think is that there is something wrong with your box.--Steveadeff 14:04, 21 April 2006 (UTC)
I forgot to mention that 6200ch isn't an entirely out-of-the-box solution, anyway; you still need to specify the node with -n in a multibox situation. You don't actually have more than one FireWire cable box, do you? If you did I bet you'd run into the (for example) "both boxes can't be on broadcast" issue.YLee 16:37, 8 March 2006 (UTC)

Thanks for the update SlicerDicer. I got this working last night, then it went to ashes. I still have no issues whatsoever using test-mpeg2 -r 0 >file.mpg and simultaneously running mplayer file.mpg. This works perfectly! Every once in a while, mythtv will work perfectly, too, but it eventually just starts showing me all sorts of mpeg2 decoding errors (invalid motion errors, others about specific types of frames, etc.), playback glitches, and the machine's load goes through 7 or 8 with near 100% cpu use. The only configuration I have gotten this working for any period of time with is using kernel 2.6.16.9, custom-built to compile in the options you show in this page. It is worth noting that I cannot get firewire capture to work, even with test-mpeg2, if I leave out ethernet over firewire. This is sort of annoying because I use modules for my regular ethernet devices, and ethernet over firewire being built into the kernel becomes eth0, forcing me to renumber my regular ethernet devices. At this point I am beginning to suspect a timing issue within mythfrontend that is chewing cpu and degrading interrupt handling (ultimately creating problems for the firewire transfer). I'm seeing enough reports from others on mythtv-users about high cpu usage I believe something else is going on here. In fact, I am unable to get back to a configuration where I can play 720p without consuming 97% cpu, which is absolutely crazy, since the AMD64 hardware I'm using is much more capable than my old Athlon XP k7 hardware, which could play 720p without breaking a sweat. --mmead 13:19, 21 April 2006 (UTC)

Mmead, this is due to a bug in the kernel firewire driver, 2.6.16.9 may have a fix for this, I haven't kept up to date on their progress in fixing the bug.--Steveadeff 14:04, 21 April 2006 (UTC)
Thanks for the update, Steveadeff. Do you have any reference to this particular bug that I might use to track its progress and look for a solution? Also, what is the bug affecting, just the corrupted stream issue I'm seeing? --mmead 14:22, 21 April 2006 (UTC)
I know Jim Westfall was working on this, I believe he patched the issue within MythTV itself. http://www.linux1394.org/ is the homepage for the linux kernel driver, and they look to have made some changes in the last two releases but I don't know if any of them fixed this issue since I'm not really sure what was causing it. As to what is affected, I mention it in my addition to this main article but basically what happens is that the code gets into a state where it requires lots of CPU and is unable to continue grabbing the data from the stream causing the buffer to overrun and data to be missed. So what you see is high CPU usage and missing data in the written mpeg file which results in glitches in playback. SVN pre-0.19 had issues playing this back and crashing quite a bit, but 0.19 should have that problem fixed. 0.19-fixes has Jim's patch included from what I understand, so its now basically down to when the kernel driver will be fixed.--Steveadeff 14:52, 21 April 2006 (UTC)

Update from mmead. So I got this working tonight. I have moved to kernel 2.6.15.1 and am using the 1394 modules, rather than building them into the kernel. Here's the weird part. In testing, it was working fine when I was logging in as root, running X>/dev/null 2>&1 &; and then running mythfrontend against the X server. Normally, my lirc watchdog script starts up X and mythfrontend by using startx. When I switched to my normal startup mode with startx, I began getting corrupted streams. I have switched my lirc watchdog script so that it runs X>/dev/null 2>&1 &; DISPLAY=:0 mythfrontend >/var/log/mythfrontend.log &; Everything seems to be working pretty well, including capture of multiple HD streams simultaneously (firewire + OTA receiver cards). I can't fathom why this made a difference, but I'm now curious to go back and try 2.6.16.9 again, given that the dvb cards seemed to work a little better at that kernel version. I'm still having high cpu usage during playback, but it has decreased some by using linear blend deinterlacing and nvidia driver 7667. --mmead 03:34, 25 April 2006 (UTC)

So did the firewire glitches go away? did you have them to begin with?--Steveadeff 13:24, 25 April 2006 (UTC)
Yes, they've gone away. I did have them to begin with, but I'm now skeptical of whether it had anything to do with the firewire driver. I can routinely cause the glitches by using startx instead of X&;mythfrontend&. I noticed my xinitrc has a nice -n -2 mythfrontend in it. I'm going to try to isolate whether the nice -n -2 was causing the problem or not. I'll have more info soon! --mmead 13:38, 25 April 2006 (UTC)
Please do, and to the mailinglist as well.--Steveadeff 17:18, 25 April 2006 (UTC)
Ok, sent a post to the mailing list. I'm certain the nice -n -2 mythfrontend was contributory to my problems. --mmead 18:29, 27 April 2006 (UTC)