new info on what causes "seeker halt" error and pvr-350 lockups

[maximumpig]

SO i did a fresh install on an old 440BX machine

SageTV 2.15B worked great with my PVR-350, with HW out and HW-UI-out turned on--about 98% perfect.

I also tested recording some favorites overnight and those worked perfectly too--1 file per show, at the right time, and no skipping

THEN

I installed the USB-UIRT and driver and re-did the setup wizard to configure control of my set-top cable box-- after that the hw-out from the pvr-350 was unusable--I would get a green screen on my TV although the overlay display on my monitor would continue to work, a little choppily. The green tv screen would continue until a reboot.

Also, favorite recording no longer worked--I started getting the "SEEKER HAS DETECTED A HALT IN THE ENCODER" message, which appeared every 5 minutes in the log file and corresponded exactly to where the shows recorded were being split into multiple files, with pieces missing. Others have reported this behavior as well, with no resolution (search the forum using "halt seeker" and you'll find the threads.

THEREFORE

the USB_UIRT support, or perhaps the generic Sage support for channel changing using *any* IR blaster device, is the likely souce of both problems.

PS On the theory that running thru setup wizard twice might be the problem, I then uninstalled SageTV, Java and deleted the frey directory and all related registry keys, did a fresh install of 2.15B and ran the setup wizard just once, with USB-UIRT support, and both problems were still present.

I have every faith that, now that I have helped to narrow down the location of the problem in the code, the developers will do their very best to resolve this issue.

[Deadbolt]

Wow! Great work! Now that I think of it...that is the same experience I had! My 440BX was working (end-of-file bug back then but no green screen or encoder halt) I then installed the USB-uirt and all hell broke loose.

Too bad I already orderd a new mobo, proc, and RAM.

Deadbolt

[TunaBoo]

Right now until I get the server re-fixed, I have 1 PVR 250 in my PC. Nothing else like usb-uirt (dont own it) or girder (don't own it). And still, I get the errors on the 5 minute marks. Now this is rare, maybe 5 per day, and it doesn't ALWAYS split the file.

I really want someone from sage to explain how it does this wacky halt thing on the 5 minute mark?

[maximumpig]

well, i re-re-reinstalled sage without usb-uirt driver installed and once again i was able to use hardware out and record continuous unbroken files.

of course Sage could no longer control the channel changes.

[maximumpig]

Since my last post, I also tried using the good old EXEtuner plugin but, interestingly, I still get split up file fragments, again, mostly on the 5 minute marks.

[maximumpig]

even more interestingly, with the exetuner plugin installed and active but without the usb-uirt drivers installed, the prog works ok.
no file splits or skips.
but of course no way to change channel without the usb-uirt

[jrhees]

Very interesting. What happens if you have the USB-UIRT drivers installed but *don't* have the USB-UIRT plugged in?

-Jon

[maximumpig]

i will give that particular combination a shot tonight.
and of course report back

[jrhees]

This has me wondering what can affect the TV out on the PVR-350 when the PC overlay still works??? I was under the impression that the PVR-350 uses all-hardware decoding?

Are others successfully using the 350 with the USB-UIRT?

-Jon

[maximumpig]

for me it is more an issue of what on earth in the usb-uirt drivers or hardware can affect the pvr-350 *encoder* since that is where my trouble is.

in any event the pvr-350 uses hardware decoding but that output only comes out the ports on the card (intended to go to tv). the overlay video that appears on the computer monitor is generated by one of various software codecs Sage can use, for example, the intervideo codec that comes with the hauppauge cards.

[jrhees]

You don't mind sending me your PC setup for debug, do you

If you're willing to debug this, here's some things you can try (although some require cost/effort).

1. Try putting the USB-UIRT behind a 'powered' USB hub set to 'external powered' mode. This would help sort out if there is some sort of power-supply issue...

2. Try some different USB drivers. Download http://www.usbuirt.com/USBUIRT%20Drivers%20v1_3.zip and unzip to a folder. Copy the FTD2xx.SYS file overtop the one in your Windows\System32\drivers folder AND copy the FTD2xx.dll overtop the one in your Windows\System32 folder. Then reboot and see if this has any effect.

-Jon

[maximumpig]

i already have a hub so no problem (wasn't using it but will try it)
I'll try the 3 things:
- uirt drivers w/o hardware plugged in
- external powered usb hub
- the FTD2xx files you describe above

plus a bonus shot if you think it might help:
- non-acpi win xp install with manual IRQ config

here is my setup
DELL XPS-R400 (intel 440BX AGP motherboard) latest bios from Dell (A13)
with a powerleap unit with a Celeron 1.2gig proc
ATI Radeon 7200 All-In-Wonder (using s-video-out)
Catalyst 4.3 drivers (latest)
Quantum Fireball 40gig boot drive on mobo ide-1 master
Maxtor 250 gig data drive on ide-1 slave (currently not in use to isolate potential large-size drive issues with mobo)
TDK 8-4-32 CD-R/W drive on ide-2 master
M-Audio 2496 Audiophile soundcard w/latest drivers from site
Hauppauge PVR-350 card w/ latest drivers (#22037 from hauppauge site)
3Com Network interface card (forgot model #)
WinXPSP1a with directx 9.0b runtime and all critical updates

Sage Beta 2.015
using s-video from cable box
same problems occurred with sage non-beta 1.410

and of course, the usb-uirt with the latest drivers from the site.

The only software i have is SageTV and Girder (from my attempts to make the EXEtuner plugin work) plus the hauppauge intervideo codec and the cyberlink ATI codec and the java runtime environment installed with sage.

[maximumpig]

ok here are the results:
- UIRT drivers without the hardware plugged in:
works ok (obviously minus channel changing ability)

- UIRT behind powered hub, 1.3 drivers installed
not ok

- UIRT 1.3 drivers, UIRT HW installed
not ok

- non-ACPI Win XP install, 1.3 drivers, UIRT HW installed
not ok

I thought I was on to something last night when I saw that the USB root and the Hauppauge card were on the same IRQ (#9) but then I moved the card to a different PCI slot and it showed up as IRQ #11 while the USB root was still on #9 but the problem persisted.

I am at a loss here . . .

[jrhees]

Well,

I've been trying to round up a 440BX motherboard but so far no luck.

If I were to guess, there's some sort of interrupt/driver latency issue with the USB device installed. Since full-speed USB devices are 'polled' by the USB host every 1 mS, there may be some issue that is being created.

For grins you may want to try installing some other USB peripheral you have lying around...

I'm pretty much out of things to suggest. I have put in a support request to Hauppage to see if they know of anything like this happening before, and to get an idea of why a HW decode card would even care what is happening on the rest of the PC.

You may also want to check what other IRQ's share with the USB (i.e., sound card or video).

-Jon

[maximumpig]

yeah i was thinking of trying another usb item to see if this is unique to the usb-uirt

the usb port is not sharing an irq at this point, nor is the hauppauge card

there are 3 other things i will try, which I think aren't likely to help but maybe you could give me some insight:

1. setting the priority in the registry to Irq#11 (the hauppauge card) or alternatively the USB ports (#9)

2. installing this:
http://support.microsoft.com/?kbid=822603

3. setting sage to accept input from the usb-uirt as a receiver (right now I am just using it as a transmitter, since I am planning to introduce an ATI remote wonder+girder into the mix when I get the rest of this working)

#3 I figure has the least likelihood of doing anything but we'll see.

[jrhees]

Yeah,

I doubt #3 will do anything, since the 'API Driver' for the USB-UIRT will handle send/receive and this makes no difference to the HW.

IRQ's are a difficult thing to verify, since they are often 'virtualized' once you see the IRQ # in Windows. For example, a motherboard may actually share the samy *physical* IRQ line among all PCI slots and then the Bios/OS may split them back up. This is a function of the Bios and how it utilized the Interrupt Controller.

One other thing you can try (one again costs $$) is to put a cheap PCI USB port card in one of your PCI slots and try using it instead of your built-in USB ports.

-Jon

[maximumpig]

Since I installed Win XP without ACPI, it is not using virtualized IRQ #s--that's how I was able to change the IRQ for the Hauppauge card by changing PCI slots. At least that's the impression I'm currently under.

I actually have a USB card but I was avoiding using it since that would tie up my last free PCI slot which I was saving for my sigma xcard (I had big plans for this box, you see. . . )

however, in the interests of science and human understanding, I will install the USB card and report back . . .

[maximumpig]

The Good New is, using the USB card fixed the problem.


The Bad News is, it ties up my last PCI slot so that I can't install my X-card, which I was going to use to watch DIVX files through Sage. . .

[Crowdx42]

Is this a motherboard issue with the USB-UIRT or has anyone gotten this problem using the Nforce chipset? I know older machines usb was not good in a lot of ways, newer boards tend to have pretty trouble free usb, is it just that the older machine is suffering from usb 1.1 issues?
Patrick

[jrhees]

My (trying to be unbiased) guess is that this is related to first-generation USB. A while back I worked on the HiPix team and we chased a similar issue with interrupt latencies/failed busmaster DMA transfers, etc., on end-user's machines, only to find if they disconnected *idle* USB devices like scanners and mice the problem would magically go away!

Our guess at that time was that the USB was somehow interfering with other PCI devices in the system -- although it was difficult to pin down since the USB was implemented in the motherboard chipset.

If using another USB card in the PC solved the problem, then most likely the built-in controller is not using an efficient mastering system when interacting with the host. Efficiency is key because USB must essentially 'poll' all connected USB devices every millisecond or so (USB has no 'interrupt' mechanism on the chain).

I would doubt you'd see problems on a newer USB 1.1 or USB 2.0 system as well.

Sorry that's not the answer you were looking for on this!

Crowdx42, I guess the best answer I can give to your ?? is that there are >2000 USB-UIRT's out in the field now and I've only seen a handful of USB-type issues reported.

-Jon