OK, my frustration level with this problem has just reached a new high. Despite the fact that I wasn't 100% convinced the problem was related to my network setup, some of the suggestions made in this thread, like getting the hub and the IPCop box out of the mix, made perfect sense. And since I couldn't prove anything without trying something I decided to move both the HDHR and my Myth B/E server to the internal network (
192.168.0 - same network as the F/E). I moved everything around, got everything hooked back up, and reconfigured for the network change. I then went to the F/E, and with high hopes that I had fixed the problem, fired up Myth.... Wouldn't you know it, same stinking problem still exists. (By the way, I think this new network configuration make more sense, and will work out better for me in the long run anyway, so I'm certainly not regretting the changes I made.)
<br><br>In the process of the rearrange I had to move the HDHR to a new location, with a new cable feed. I was thinking that maybe, just maybe I had fixed one problem and introduced another by making this move. So, as a sanity check I fired up the test Myth master B/E system that I had setup last night and did a little testing. On this test system a recording and playback was pretty much spot-on perfect. Now this test box and the production Myth B/E box are located about 6 feet away from each other, are both connected to the exact same switch, and essentially have the same network path to both the HDHR and the F/E system.
<br><br>So, where does that leave me with this problem? I guess back to looking at some of the other things suggested in this thread, like a power supply or hard drive issue. But if it is one of these things why does the problem only present itself when I'm using the HDHR and the F/E at the same time? These are load issues that I would think I would see when I recorded off of the tuner cards, or when I ran some of the F/E functions on the B/E system, and this is not the case. Maybe a fluky NIC in the B/E system? I guess this is another possibility, but again I go back to if this was the case wouldn't I likely see some evidence of a problem in the system logs?
<br><br>To answer Scott's question about the kernel, I am using stock Fedora Core 6 kernels all the way around (B/E, F/E, even the test B/E). And although it wasn't asked, I'll tell you the Myth packages are from the Axel's ATrpms 'bleeding' repo, which were built from the SVN trunk on or around January 30th (revision 12674). All other packages on the system are pretty much up to date. (I'm just missing whatever has been released in the last few day, while I have dedicated my attention to this problem.)
<br><br>My next step I guess is to start gathering some data points. I'll start the mythbackend process with the '-v all' option and see if anything interesting shows up in the myth logs. I usually use 'top' to monitor system performance. Anyone know of any other freely available tools in Linux that might be useful for troubleshooting this issue?
<br><br>If anyone has any more suggestions please keep 'em comin'. I'm willing to try just about anything at this point.<br><br>Thanks,<br>John<br><br>