Set the "Network Type" to a natively supported tuner?

[routerunner]

Hi,

after lots of testing I came to the conclusion that the SageTV tuner card detection mechanism has to work hard to make your tuner card working natively and the main reason is the lack/incorrect information in the BDA drivers.

One particular important information is the "TunerType (Network Type)" which should be provided by the card manufacturer via the BDA capabilities bit-map and empty as in the example below:

Mon 10/15 7:04:08.731 [Scheduler@1a437b6] initGraph0 (ver 2.1.0) called capDev='TBS 6984 Quad BDA Digital Capture DVBS-0', Country:'United Kingdom', TuningMode:, TunerType: Cap:0x49000
Mon 10/15 7:04:08.847 [Scheduler@1a437b6] Not specify TV type ( Network type  ), to search matching one.

The capabilities bit-map (in bold red) contains few information that the SageTV BDA "scanner" extract and stores in the "Sage.properties":

• The "TuningMode" which is stored as "mmc/encoders/xxxxxxxxxxx/100/0/tuning_mode=" and which value is "Air" when the capabilities is equal to "0x49010".
• The "TunerType (Network Type)" which I believe it should be stored in the properties file and unfortunately isn't.

To perform the "Network Type" detection, SageTV does a pretty empirical approach, basically it tries any possible network type (ATSC, DVB-T, DVB-C and DVB-S) for every tuner you have installed until it does find the match (it takes about 2 seconds with 8 tuners). The detection is done automatically just before starting a new recording and the matching "Network Type" is then stored somewhere (not in the properties file AFAIK) and it remains valid until you restart the server.

When you have one or more recording in progress and you start a new one with a tuner which hasn't been determined its "Network Type" yet, SageTV will start the detection in parallel for about 2 seconds searching all tuners even the one configured already causing all the other recordings to timeout and stop (yellow icon warning).

Eventually, when all the tuners have their "Network Type" determined I can start/stop all the 8 recordings simultanously without problem, then if restart the SageTV server you're back to square one.

I reckon this is a general issue for all natively supported tuners when the total number reaches lets say eight. When I had four tuners never encoutered this issue, probably because the detection process never took enough time to kick in the timeout.

I'm looking for solution here. I've contacted the tuner manufacturer already to see whether they could provide the right information in the BDA drivers as it should be, the first reply was to switch to MediaPortal, then I told them that, with all due respect, SageTV was still the best solution "off" the market by a long mileage.

I was wondering whether anyone knows about a "Sage.properties" setting that can set the "Network Type" for each tuner or whether I can chance the seeker timeout to avoid recording failures.

Thanks
Eddy

[BobPhoenix]

Originally Posted by routerunner

... and it remains valid until you don't restart the server....

Think you really meant to remove the "don't" here. Sorry I can't help you otherwise.

[routerunner]

Originally Posted by BobPhoenix

Think you really meant to remove the "don't" here. Sorry I can't help you otherwise.

yes, you're right...nice catch
Eddy

[drewg]

In the SageTV 6 days on linux, I had a similar problem where I would have "glitchy" HD recordings because SageTV failed to issue an ioctl to adjust the tuner's buffer size to a larger value, and just stuck with the (designed for SD) tiny default. To work around this, I wrote an LD_PRELOAD interposing library to watch for the tuner being opened, and issued a DMX_SET_BUFFER_SIZE ioctl to increase the buffer size to the same thing that other PVR software used. ( Qian fixed the issue in the 7.x beta cycle)

At any rate, I would see if the same thing is possible on Windows (search for "Windows dll interposer") What you'll want to do is to intercept the BDA ioctl that gets the cap, and replace 0x4000000 with the "correct" value.

Drew

[routerunner]

Originally Posted by drewg

At any rate, I would see if the same thing is possible on Windows (search for "Windows dll interposer") What you'll want to do is to intercept the BDA ioctl that gets the cap, and replace 0x4000000 with the "correct" value.

@drewg:
Hi brother ;-). Are you talking about "winapioverride32"?

I sent another request to TBS praying support to forward the request to their R&D as is a "one line" change...

Anyway, I still hope that I can workaround this via the registry or via SageTV property setting, but I guess this is more a question for Opus4.

Thanks
Eddy

[routerunner]

Originally Posted by drewg

At any rate, I would see if the same thing is possible on Windows (search for "Windows dll interposer") What you'll want to do is to intercept the BDA ioctl that gets the cap, and replace 0x4000000 with the "correct" value.

Drew,

you know what? If TBS is going to let me down on this, there is still the "old" days way...get the Linux driver source, find the right value, change the Windows driver binary...job done

Eddy

[drewg]

Originally Posted by routerunner

Drew,

you know what? If TBS is going to let me down on this, there is still the "old" days way...get the Linux driver source, find the right value, change the Windows driver binary...job done

Eddy

I think the linux source will be quite different than the BDA driver, unfortunately.. If you cannot find a registry hack, I think the interposer is your best bet. Or buy a linux license, next time one comes up

Drew

[routerunner]

I finally managed to let Sage knowing that the tuners are DVB-S, so no more "Network Type" search needed and tuning is now about 2 seconds (from pressing the play button to video on screen)

Wed 10/17 7:04:14.742 [Scheduler@64978b] initGraph0 (ver 2.1.0) called capDev='TBS 6984 Quad BDA Digital Capture DVBS-5', Country:'United Kingdom', TuningMode:, TunerType:DVB-S Cap:0x49000
Wed 10/17 7:04:14.850 [Scheduler@64978b] BDA capture is found on location:'pci:3-0' id:'PCI\VEN_1131&DEV_7160&SUBSYS_00136984&REV_02' for TBS 6984 Quad BDA Digital Capture DVBS-5 (@device:pnp:\\?\pci#ven_1131&dev_7160&subsys_00136984&rev_02#4&3723292c&0&0030#{fd0a5af4-b41d-11d2-9c95-00c04f7971e0}\{5bb3dbd0-9e1e-424c-9281-6b5e00080201}) (it's a BDA only).
Wed 10/17 7:04:14.850 [Scheduler@64978b] Add BDA filters (capture:'@device:pnp:\\?\pci#ven_1131&dev_7160&subsys_00136984&rev_02#4&3723292c&0&0030#{fd0a5af4-b41d-11d2-9c95-00c04f7971e0}\{5bb3dbd0-9e1e-424c-9281-6b5e00080201}') for device=TBS 6984 Quad BDA Digital Capture DVBS
Wed 10/17 7:04:14.850 [Scheduler@64978b] Setup DVB-S BDATuningSpace (6  0)
Wed 10/17 7:04:14.855 [Scheduler@64978b] LoadTuneTable DVB-S
Wed 10/17 7:04:14.878 [Scheduler@64978b] Loaded Sage TV Splitter Filter 0x4b06bacc
Wed 10/17 7:04:14.879 [Scheduler@64978b] BDA Filters are loaded

However, is not over yet.

It still doing the search within the available (8) DVB-S tuners via CLSID match, and I'll still investigate whether I can avoid that (maybe the tuning time will drop down to 1 second), but I this point I think is not a real problem.

Instead, the real issue is the "seeker/duration_for_halt_detection=60000" property which kicks the tuners reset after 60 seconds as it seems that the watchdog doesn't get stopped once the tuner has been found.

I'll do more digging on that, but a quick solution could be to increase the timeout to 18 hours as the server is switched off overnight.

Eddy