I've recently added a Hauppage PVR-500 (in addition to the original PVR-250) and a four-way splitter (using three outputs) to my R5F27 back end box, and since then, I have apparently random issues with one of the recordings becoming corrupted when multiple tuners are active. The affected recording appears, for lack of a better word, "untuned" - like the frequency for the channel is slightly off - color washed out to black and white, fuzzy, horizontal hold out of whack, sound appears to be coming from another channel...

Things I can prove: It happens. It's not guaranteed to happen under any circumstances I can find... but:

Things I suspect: limited testing makes it appear as though it is a combination of which channels are being recorded - when I experimented this morning, I could reliably mangle recordings on channel 27 as long as channel 7 was recording on the first tuner. Recent recordings follow that pattern, too, but not 100% - I have recorded on that channel combination in the past without either recording being mangled.

Any ideas at all on how to proceed would be wonderful, and thanks in advance for any help you can provide. Detailed configuration information available, but I couldn't think of what would be relevant.... Ask, and you shall receive.

Have you tried changing the capture resolution to 720 x 480 as outlined in tjc's Hints and Tips under "known issues"?

Good suggestion - the symptoms don't sound like a perfect match, but close enough to see if will help.

(I'll attempt first just to disable VBI and see what that gets me, as well as try to force the recording format to 720x480).

No dice on either front. As I said before, a good suggestion, but no dice.

VBI is disabled (unless I misread the output below), and changing to 720x480 (which was a good idea anyway) did not fix it:

root@backend:~# v4l2-ctl -d 1 --log-status | egrep -i "vbi|fps"
ivtv1: VBI Format: No VBI
ivtv1: Video: 720x480, 30 fps
ivtv1: Stream encoder VBI: status 0x0000, 0% of 1040 KiB (61 buffers) in use
ivtv1: Read MPG/VBI: 59228096/0 bytes
root@backend:~# v4l2-ctl -d 0 --log-status | egrep -i "vbi|fps"
ivtv0: VBI Format: No VBI
ivtv0: Video: 720x480, 30 fps
ivtv0: Stream encoder VBI: status 0x0000, 0% of 1040 KiB (61 buffers) in use
ivtv0: Read MPG/VBI: 38834176/0 bytes

That's with the 250 (tuner 0) and one of the 500s (tuner 1) actively recording. Tuner 0 is actually the one that has the messed up recording.


Just in case, I'm going to try dropping all the tuners, instead of just deleting from the GUI, see if that buys me anything... Any other ideas much appreciated.

Dropping and recreating the table didn't fix it. While I was doing that, though, I disconnected the PVR-250 from its data source in mythtv-setup, to see if the problem only followed the 250 - it does not. With just the two 500 tuners enabled, it will mess up one of the recordings on the 500.

In desperation, I dropped the table again, recreated it from the install sql scripts, rebooted, recreated all three tuners. Since that time, all recording has been flawless - even after a drop back to 480x480. (I found that my front end, on a measly 100Mbit connection, could not quite handle playback 720x480 at a bitrate that still looked good -- either that, or the via mpeg acceleration didn't like it - choppiness).

It's been quite a while since then, so I think this is resolved.

Thanks jzigmyth for the suggestion.

Glad you are part way there.

I am curious about the statement here:



Could you post hardware specs maybe someone here can help with that issue. I say that because 100Mbit is all I run, I have 2 SBE/FE and the one MBE/FE. All are attached via a 100 Mbit switch each carrying it's own 100mbit link

As an alternative, try to locate here or in the Knoppmythwiki.org the performance tuning like DMA, etc. Could be an issue.

For Reference:
I find I can run 4 captures off the BE's and watch 3 streams via Frontends and also have say a laptop watching a stream direct from the storage. This is all SDTV. Since you list essentially SDTV specs for capture might be useful.

It works the MBE Storage very hard at that point, but it doesn't seem to be saturating the network.

One thought that comes to mind, My MBE used to be on the First SBE listed below, it has a good processor, but the backplane memory Bandwidth is only PC133 SDRAM. Whenever I would run 2 captures and watch 2 streams I would get stuttering on the FE's. A remote stream direct from disk would bring it to it's knees then.

Anyway, HTH.

_________________
KnoppMyth R5.5
MBE: AMD64 3400+, K8N Neo4 Plat., 1Gig, Asus Extreme N6200, 320G pata, 2x320Gsata, 750Gsata, PVR-150 Retail w/Blaster
SBE: AMD XP2000, GA 7ZMMH, 1 Gig, XFX 256M 6200, 20 Gig, PVR-150 Retail w/Blaster
SBE: AMD Dur1800, 512M, PVR500

Well, I just found some snowy recordings from my pvr-500, too. I use only over-the-air channels. The problem is that sometimes channel 3 recordings are fine and sometimes they are very snowy, just like the antenna was disconnected. It only crops up occasionally, but it is totally reproducible. Channel 3 recordings on tuner 1 of the pvr-500 are always perfect and channel 3 recordings on tuner 2 are perfect some of the time and very snowy at other times.

It turns out that if tuner 1 is recording or last recorded on channel 3 then tuner 2 can record channel 3 fine. If tuner 1 is recording or last recorded on another channel, then tuner 2 records channel 3 with low signal strength (very snowy). (Tuner 1 always records fine)

The channels in my area are 3, 15, 21, 27, 47 and 57. For those of you not old enough to remember, channels 2 through 13 are in the VHF band and 14 through 60-something are in the UHF band (this only applies to over the air channels. Cable channels 14 and on up are in yet different bands), so I have just one channel in VHF and the rest in UHF. My hypothosis is that when tuner 1 changes to a UHF channel it somehow also switches tuner 2's band selector to UHF even though tuner 2 itself hasn't switched channels. So as long as tuner 1 is tuned to a UHF station, tuner 2 gets a poor signal on VHF stations, but not UHF stations.

The reverse isn't true. When tuner 1 switches to a VHF channel, tuner 2 can still record on UHF just fine. So the tuner 2 band selector only follows the tuner 1 band selector in one direction, not the other. This leads me to think that it is not a hardware problem with the tuner, if the two band selectors were somehow shorted together in the hardware, they would follow each other both ways.

I don't know if The IVTV code deals with the tuners on this low of a level or if the problem is actually in the tuner, itself. I have tried to find the IVTV source code on the web but failed to find it.

Anyway, my work around was to create a second lineup at Schedules direct without channel 3 and assign it to tuner 2, so it can never record on that channel. This works pretty good, but sometimes not, like when tuner 1 is recording something on 15 and I want to watch 3 live. The only tuner left doesn't have 3 in its lineup!

If anyone could easily point me to the IVTV source that is used in R5F27, I'd like to look it over.
Thanks.

Greg, I don't understand the above. Could you detail what table, how to drop it and exactly how to recreate it? Thanks!

I am not a Knoppmyth wizard, nor a MySQL guru. Follow any directions here at your own risk. Your mileage may vary. This procedure may impregnate your cat or have other undesired consequences.


That said, here's what I did. The CREATE TABLE I grabbed out of /usr/local/share/knoppmyth/KnoppMyth.sql .

back up my stuff:
mythbackup
stop mythbackend:
/etc/init.d/mythtv-backend stop
connect to mysql:
mysql -u mythtv -p
From mysql, rename the original capturecard table, and create an empty one:
mysql> alter table capturecard rename oldcapturecard;
mysql> CREATE TABLE `capturecard` ( `cardid` int(10) unsigned NOT NULL auto_increment, `videodevice` varchar(128) default NULL, `audiodevice` varchar(128) default NULL, `vbidevice` varchar(128) default NULL, `cardtype` varchar(32) default 'V4L', `defaultinput` varchar(32) default 'Television', `audioratelimit` int(11) default NULL, `hostname` varchar(255) default NULL, `dvb_swfilter` int(11) default '0', `dvb_recordts` int(11) default '1', `dvb_sat_type` int(11) NOT NULL default '0', `dvb_wait_for_seqstart` int(11) NOT NULL default '1', `skipbtaudio` tinyint(1) default '0', `dvb_on_demand` tinyint(4) NOT NULL default '0', `dvb_diseqc_type` smallint(6) default NULL, `firewire_port` int(10) unsigned NOT NULL default '0', `firewire_node` int(10) unsigned NOT NULL default '2', `firewire_speed` int(10) unsigned NOT NULL default '0', `firewire_model` varchar(32) default NULL, `firewire_connection` int(10) unsigned NOT NULL default '0', `dvb_hw_decoder` int(11) default '0', `dbox2_port` int(10) unsigned NOT NULL default '31338', `dbox2_httpport` int(10) unsigned NOT NULL default '80', `dbox2_host` varchar(32) default NULL, `signal_timeout` int(11) NOT NULL default '1000', `channel_timeout` int(11) NOT NULL default '3000', `parentid` int(10) NOT NULL default '0', `dvb_tuning_delay` int(10) unsigned NOT NULL default '0', `contrast` int(11) NOT NULL default '0', `brightness` int(11) NOT NULL default '0', `colour` int(11) NOT NULL default '0', `hue` int(11) NOT NULL default '0', `diseqcid` int(10) unsigned default NULL, PRIMARY KEY (`cardid`) ) TYPE=MyISAM;
mysql> quit;

Rebooted the back end host.

Then just recreate the necessary tuner settings from the gui.

Since this was such a bizarre and somewhat difficult to reproduce issue, I am not sure at all that this was the fix - but the issue _is_ gone...

The backend was under no stress at all (I can easily record three streams and play one back with zero issues, and when testing the FE nothing was recording), here's the frontend specs:

Via EPIA Samuel2 600Mhz, 512MB RAM, diskless/PXE boot, 100Mbit ethernet.


Performance is flawless at 480x480x2Mbit/sec encoded playback.

CPU usage during playback is 50-60% - without XvMC it pins the chip and chops, so I think it's got to be using XvMC.

Cat5 cable quality, NIC quality, and switch quality may all be possible suspects if network is the issue, I have not profiled it at all because it Works For Me(TM).