magnetik and solutor what version and build of showshifter are each of you running ?

magnetik there is no need to go through all the development setup stuff to just use the drivers in showshifter

magnetik,

I know you weren't knocking anything. My rant was not in relation to your post - I guess I should has written it up in a seperate post from my reply to you. I too was thinking it was a junk card, but after all this I'm almost feeling one with the card "My mind to your mind. My thoughts to your thoughts" as Tuvok might say - hahaha

Spectrum

I installed 1.5 spec bda drivers and when watching tv on any channel using DigitalWatch BDA it freezes after about 5mins, I've read this post and saw that a few prople are having problems with this, should I be using 1.4.5 drivers?

My version is here:

http://www.showshifter.com/files/download/...02.2595-DVB.exe


Properties of Showshifter.exe says 3.2.0.2595 (there's a typo in one of the two)

moth1,

Are you absolutely sure you're using 1.5? Can you check the version information on windowssystem32driversthbdatun.sys please.

If anyone else gets "freezing" with 1.5 please let me know. I'm pretty sure I've eradicated the major cause for this in the 1.5 set so if it's still occurring I need to find out why. That's if it is caused by the driver and not some other reason.

Spectrum

moth1,

where did you get your digitalwatch from, the one I have loads the BDA filters by name and in the new driver (1.5) the names have changed thus it will not find the BDA source filters at all for me.

Is there a new version of DW that fixes this?

null_pointer,

Check here: http://robdvd.radfiles.net/viewtopic.php?t...er=asc&start=59

Spectrum

im using the same version 99% sure (im at work now so cant check!) - viewing

http://www.showshifter.com/files/download/interim/

only shows 1 installer in the folder..... I wonder what else it could be?? I might try removing ffdshow 2nite and try that.

JoeyBloggs, yeah I thought that would be the case - since SS works excellent - I just cant record..... the vision stays fine and works, but the audio goes out except for a few blips and blops..... now I am using a USB sound card on my HTPC - its actaully a USB to toslink sound card that I used to use with my Sony Minidisc recorder years ago- but now it feeds optically into my logitech Z-680's THX 5.1 sound system (excellent system IMHO!)

maybe its that?

The graphedit step, is only for testing, SS install its own tuning space.

I dont think codecs installed are relevant, if I'm not wrong, mpeg2 recording not involves it at all.

In dvb, mpeg stream will be written to hdd with no (or very little) conversion, this is a lot different from analogue to avi recording.

Try to open regedit, delete this key

HKEY_LOCAL_MACHINESOFTWAREHome Media Networks

and then reinstall SS

BTW what happen exactly when you try to record ?

and what you see in compression setting page of SS

To Null_Pointer,
I got my DigitalWatch version form the BDA DigitalWatch thread under Technical&Developement it is version 0.722.

To Spectrum,
I will have a look thisafternoon and find out what version of the drivers are in windowssystem32drivers. I'm pretty sure they are version 1.5 but , they might'n be because I did try and install 1.4.4 but it wouldn't work so I downloaded 1.5 and installed 1.5!

Cheers,
Moth1

okay this is the deal with SS..


channel 7 worked fine tonight recording - sound stayed/etc.... did start/stop recording 7-10 times all worked perfectly... this was during Blue Heelers.

any other channel - no luck... so im guessing its to do with the audio transmission type?

does anyone have an idea on a fix for that?

If a channel has AC3 audio and you try and record it with SS, it'll go balls up even if your not listening to the AC3 stream. If there's AC3 audio assigned toa channel, it won't work.

thanks for that - I guess I need to await the next SS release!

Or the one after that. It seems to be a generic problem with BDA Architecture and Microsoft are going to have to fix it before the end of the year to release MCE here. For some reason when you activate an AC3 component (stream) the Microsoft Network Provider, Transport Information & Mpeg2 Demux filters will not map it through to a output pin :cry:

that seems really weird and/or silly....? :roll: just seems weird if you can view the channel perfectly that you cant capture that same data to disc? are you sure this is the real issue?

havent been following progress, but does the BDA version of Webscheduler o r Digital watch suffer the same fate?

BDA digital watch has no problem with live AC3, so im not sure this is all correct.

As you say, if it can be produced live, why cannot the same stream be dumped to the drive?

I will try some .ts captures with the AC3 stream, i would think it would work, hmmmm who knows haha

On the topic of the MPEG 2 Demuliplexer (MS version), does this have to be used? Is there other options that may work better?

I don't fully understand all this, but to get .ts and .tp files working in zoomplayer i found "universal Open Source Mpeg Demuliplexer" (thats what it was called on the site) once installed there is

"Universal Open Source MPEG Source"
"Universal Open Source MPEG Spliter"

Both are incorporated in the same .ax

Gonna post a URL?

I tried that Open Source MPEG2 Demulitplexer but it refuses to install :?:

I don't know where i got it from.

i'll put it here for now
http://members.optusnet.com.au/spoonfed/os...28052004_nt.exe

Good find Spoonfeed,

I just dowloaded & tried a Universal Open Source MPEG Splitter from

http://www.inmatrix.com/zplayer/formats/mpeg2.shtml

Seems to render .ts ok in Graphedit but I can't choose any sub streams & Zoomplayer 3 just brings up a cannot connect decoder error. I may have a dud version but it appeared to be fairly new.(28 May 2004)

I think I will stick with VLC Media Player 7.22 for a while longer as it seems to allow sub program selection & Play the .ts better. It also plays files as they are recorded, great for time shifting & streams them as well.

P.S. Have you tried the Moonlight Player 2.2?

Dan.

Nope. I use elecard codecs for DTV playback. Was for DVD but no menu highlights. Apparently newer version does BUT it has chorma bug thingy.

A guy on Avsforum is discussing with moonlight to fix this.

As for the muliple stream, i only mux .ts so not sure there

Whilst WS BDA and DW BDA are using BDA Drivers they are not fully implementing the BDA Architecture in particular the Microsoft Unified Tuning Model. This is the part of the architecture that does not seem to be working with AC3 streams.

Agreed that if you have the video and AC3 streams and a muxer that will combine them. Then you should be able to write them out as a PVA PS Stream.

Hi again,

Has anybody had any joy with recording AC3 programs with BDA DW?

I have been testing another mux but I have some sync issues with the ac3 audio intermittantly delaying by up to a second.

Is it possible that DW needs to begin recording at a particular time referenced to the Program Clock Reference?

Dan.

I've been running WDM + BDA drivers for a while. Just gone back to 2 * BDA V1.5 drivers and I'm having problems getting dual graphs running either within UltraDTV or in one or two instances of graph edit.

Before I start regressing the drivers. Has anyone else tested multiple graphs / instances with the V1.5 BDA drivers ?

Hi I’m having problems with BDA driver version 1.5.0.0 in that Show Shifter will not display the Television or Radio menus and DigitalWatch produces the error

AddFilterByName: Failed to find matching Filter. Then the error cannot load Tuner Device.

When I switch back to version 1.4.5.0 all works fine. I’ve run the Tuner Space register - anyone any ideas?

in version 1.5.0.0 the tuner name was changed. You need to get the latest DW BDA executable.

Cheers Nate, that cured the problem now all I have to sort out is why I can't see the Television or Radio menus in ShowShifter when I have version 1.5.0.0 installed yet I can see them with version 1.4.5.0.

Just a bit of reading for anyone interested.

This doc looks at future hardware and application scenarios and set-ups.
http://www.via.com.tw/en/vtf2004/presentat...l_Microsoft.pdf

This one is a high level view of tuner drivers. I still have a few areas to work on to make mine compliant.
http://download.microsoft.com/download/1/8..._WINHEC2004.ppt

Spectrum

Hmmm interesting.

I notice mention of card and filter sharing etc. I guess this sort of relates also to muliple cards (ie if any BDA cards can be shared then muliple cards should no be an issue)?

As I understand it ~ The key for accurate multicard would seem to be. From TW04059_WINHEC2004 p17
which enables each tuner instance to connect to the correct demod instance to the correct capture instance

Also as you where saying. From TW04059_WINHEC2004 p18
Seems like a real half arsed way of doing things

:roll:

There are a bunch more papers here for people who are interested http://www.microsoft.com/whdc/winhec/papers04.mspx more on MCE and DRM for example

"Talk to Microsoft about more granular tuner control in future releases"

Yeah that caught my eye too (and i was mainly "skimming")

what the???? can u talk to microsoft? hehe. What happens if you use a liquid detergent in your washing? Do you have to switch to "granuals" before ringing?

hmmmmm

I've implemented hardware instance IDs, but I'm still working on a few other bits. I'll release it all soon.

Spectrum

Does this mean that at the moment the current BDA driver does not do multiple cards?

EDIT:
I currently do not have two cards in the same machine but I was intending to start work on this in the new few weeks to add support to WS for multiple BDA cards etc.

It does work already but YOU have to be sure you don't mix the Tuner filter from one card with the Capture filter from another. The point of adding hardware IDs is so that you CAN NOT intermix them.

Spectrum

so for us stupid people, for each physical card WS for example to avoid the issue you mention should identify that card by hardware and build the appropriate filter graph?

in which case say if null implements this method then say when Dvico pull their finger out and release BDA drivers, he would have to modfiy WS somewhat to work with that card also?

Spectrum, in a multi card situation how can you tell if a card is in use, from what I can see the only point you can tell that a card is not available is once you build the graph when you run it you get an error.

Do you know of any other way to tell if a card is in use before you build the graph etc, it would be ideal to be able to check before you try to build any graph etc.

From what I can see so far it is going to be up to the app to keep track of what cards are available and what ones are in use. Some sort or system wide Mutex could be used for this, we could work out a way of storing card/(tuner cap filter) combinations in the registry and when an app is using a card it can create a mutex (CreateMutex) to notify other apps the card is in use.

Anyway is is just speculation at the moment, this would require that all apps did this which is not going to happen, true DW and WS could work this out and play together but other apps would not.

I suppose the question is this, can you see a way for an app determining what cards are available and what cards are in use without having to have inter process communication and handshaking?

null_pointer,

There is no way to know if someone else has already "acquired" the hardware until you attempt to run the graph. If you successfully put your graph into run state then you have acquired it and no one else can until you stop your graph and therefore release the hardware.

I don't presume to be able to read minds, but I suspect your thinking is to get a hold of one card to do recordings with say WebScheduler and use the other card for live viewing with DigitalWatch. Or maybe have WebScheduler record two programs simultaneously.

Trying to reserve access to cards ahead of time is probably pointless as you can not know the configuration that the user will put your application in.

If I had to recommend a way to programme an application, then I would tell you this:
[list]

[*]Build as many graphs as there are cards.

[*]When it's time to start playing live TV or recording TV submit a tune request on the first card and try to run the graph.

[*]If you fail with the first card, repeat the process with the second card.

[*]And so on for the 3rd and subsequent cards until you eventually get one or fail with them all.

[*]If you have failed to get any card then the user must be doing something else with them and you should notify them that they don't have any cards available for your application to use right now.
[list]

Spectrum

EDITED for correct HTML

Ok I see, I do not mind creating the graphs and trying to run them etc but how do you work out how many cards are available? and how do you work out which tuner/capture filters belong to which card etc.



Would you have to have the app know how many cards there were and what filters where for which card?

One way to do this would be use the system enumerator and use the filter index as the id. i.e. To find the tuner device for the first card it is at index 2 of the system enumeration of BDA tuner devices and the capture filter is at index 2 of the BDA capture devicees etc. And thus card 2 would be at index 3 and 3 etc, this wold work as long as you did not add or remove new BDA devices, if you did you would have to setup the app again to know about the new hardware.

Does this sound like it would work?

I have implemented something like this before for an app I wrote a long time ago called Virtual VCR, it was an analogue capture tool that used the index of the capture device in the system enumeration of video input devices to work out what card to use.

Use the System Device Enumerator as you've already said:
http://msdn.microsoft.com/library/en-us/di...eenumerator.asp


Sounds to me like you want to store this information somewhere persistently? It's probably best not to - just do the whole process every time your application starts up, it will be far less complicated.

Well yes. If you Enumerate 3 KSCATEGORY_BDA_NETWORK_TUNER filters then you know there are 3 BDA compliant cards in the box (whether they're Twinhan or Fusion etc it doesn't matter).

You'd have to try it in code to see I guess.

Here's how I'd do the whole initial process of building graphs:
[list]

[*]Enumerate all KSCATEGORY_BDA_NETWORK_TUNER (tuner) filters into an array - lets say you get 3 filters (devices). If you don't get any altert the user and exit.

[*]Enumerate all KSCATEGORY_BDA_RECEIVER_COMPONENT (capture) filters into an array - from above there should also be 3 filters (devices) but don't have a fit if there are fewer - possibly the user failed to load the drivers properly for all cards so you'll just use the ones that are available. If there are none then again alert the user and exit.

[*]Based on the result above, create 3 graphs.
[list]
Repeat this loop for each graph (for X = 1 to 3):[list]

[*]Create a Network Provider in graph X.

[*]Submit a tune request on the Network Provider.

[*]Add Tuner Filter X to graph X.

[*]Forcibly connect the Network Provider filter and the Tuner filter.

[*]Repeat this sub-loop for each Capture Filter (for Y = 1 to 3 or what ever the number of capture filters you enumerated is) Insert Capture filter Y into graph X, attempt to forcibly connect it to the Tuner filter. If it succeeds move on. If it fails, remove it from the graph and try the next capture filter in Y. If they all fail then you may as well destroy this graph X as there is no capture filter associated with this tuner filter (user must not have drivers properly installed).

[*]Once you have successfully connected the capture filter to the tuner filter you can continue building that graph as usual.

[*]Repeat for the next graph in X.
[list]
If you get through all of X and could not build a graph then alert the user and exit.

You can be more intelligent about the whole thing, like not testing a capture filter in a graph if it's already successfully in use in a graph you've already built. You can have fun coming up with your own algorithms here.

Keep in mind this won't work with my driver version 1.5.0.0
I will release a new version shortly that is compliant.

Spectrum

EDITED for correct HTML

I know you are going to change your driver to allow dynamic alignment of files (tuner to capture) but what about other drivers for other cards? wil they do this also, I would rather create an app that can work with any BDA driver.

That is why I suggested a filter mapping approach so you pre set the tuner to capture filter mapping based on the system enumerator ID's etc.

Other drivers for other cards MUST also implement proper hardware IDs on their pins TO BE COMPLIANT with the BDA driver spec.

If you write your application for use with fully compliant drivers then manufacturers will be forced to write fully compliant drivers.

As an FYI for everone, I've been working on a few things from the power point slide in an earlier post.
1. Implement hardware IDs on pins (Done)
2. Capture samples must include an integral number of transport packets (Done)
3. Don't wait for signal lock before returning a result from a request to tune. The network provider will query signal strength to determine whether and when a signal is locked (Done)

Number 1 was most important as there are people waiting on this. Number 2 was not mentioned anywhere in the DDK so I hadn't considered it before now. Number 3 also wasn't mentioned in the DDK and I'm not sure if/how applications will see a difference at all. I previously only returned from tuning the card when the whole tuning process succeeded or failed.


Hopefully I'll post the new version tonight. Anyone not testing multiple cards should stick with the 1.5.0.0 set while the developers do their tests.

Spectrum

Cool, so does that mean that if I add a tuner filter and then a capture filter that they will work out what devices that have to talk to etc.

So all I have to do from a programming point of view is make sure I add one tuner and one capture filter and they will work out the rest?

There is yet one more wrinkle to the whole process seeing as how Microsoft in their infinite wisdom didn't provide a demod device category for enumeration. And that is determining whether you need to construct

tuner => capture => demux

or

tuner => demod => capture => demux

depending on the card

I haven't had time to do a lot of testing but as I tried to describe above, you add the tuner filter to the graph, then add the capture filter and try to connect them together. If they don't connect then try the next capture filter and so on.

A tuner filter and capture filter that are on the same physical card will have the same hardware ID on their filter pins. Different cards MUST have a different hardware ID.

EG. Card A has hardware ID 0x1234 exposed on its pins.
Card B has hardware ID 0x6789 exposed on its pins.
Card A's tuner filter will not connect to Card B's capture filter because the hardware ID on the tuner filter's pin is 0x1234 and the hardware ID on the capture filter's pin is 0x6789 - they don't match.


As an FYI I have not come up with a reliable way of assigning hardware IDs out of thin air programatically, so it will rely on the user to pick one when they install the card (it will be a registry value set in the inf file).

Spectrum

EDIT - JoeyBloggs, you're right again. I'll keep investigating to see if there's an easier way to do all this.

Ok, so the tuner/capture filter will not dynamicly work out what hardware they need to talk to, they will just not connect if they are the wrong instances, is this correct?

Also the more I think about this the more I think there is going to have to be a way to tell the app what cards to use and what filters etc, you may want WS to just use one of your cards, a reason for this is that you have 3 BDA cards but only want WS to ever use the first 2 and DW to use any free card, this would allow you to always have a free card for DW, this is just an example.

You may also have a non complient BDA card that will not work with WS but shows up in the system enumeration, you do not want to use this card so you just dont add it to the list of usable cards etc.

While in an ideal world having the app dynamicly work out how many cards etc are available I think in the real world it is a little more difficult.

Kind of correct. Each filter will not dynamically work out which other filter they need to talk to, they will just not connect if they are the wrong instances. I'm not sure whether the MSVidCtl COM object is smarter but it's only available in WinXP anyway.


Hold on a minute - you shouldn't start writing your software to work with faulty drivers. If a user buys a card and it doesn't work with your software they should go banging on the hardware vendor's door - not yours.

The whole point of having a graph for each piece of hardware is that you can use whichever one is free when you're ready to transition to run state. If the first card is in use try the next. If they're all in use then the user obviously wants it that way and you (the application) altert them that you can't do what they want you to because there are no free resources.

If you are Web Scheduler (or the like) then you only transition into run state when you are starting a recording. The moment the recording is finished you stop the graph and it becomes available for some other application to use. When you are next ready to record another program you start all over again trying to transition the each graph to run state, until either one graph does or you run out of graphs - and you tell the user that there are no free resources.


What I am trying to explain here is my best understanding of how BDA works. Don't fight the system otherwise you won't be able to cooperate with future applications and hardware.

Spectrum

I am still not convinced that just rellying on the system enumeration to build the graphs is the best way to go, what if you have a non complient BDA driver where the capture filter connects to you BDA tuner ok, it will look like the connection worked fine but in fact there is no way in hell it is going to work.

I know I keep going on about non complient BDA drivers but so far I have played with two BDA cards the VP card and V-Stream, the V-Stream card has BDA drivers but that will not work with any BDA software as they do not implement the Tuner correctly, you need to use a customer COM object to tune the device first. When I queried them about this they said that they are not intending to update this anytime soon and as far as they are concerned they have BDA driver, it is just that no one else can use them.

This is the way of the world, if it was an ideal place life would be much better but it is not and we have to hack at things to get them to work :-)

It is all well and good to say that if everything is to spec it will work but from my experiance that is not the norm.

So you have one non compliant card to work with and you will have to write your code to work around it's problems. What happens if another 5 vendors release non compliant cards - will you modify your code for each one to suit them too?

The whole point of writing to the BDA standard is so that you don't use each vendors proprietary API. If the V-Stream people won't release a compliant driver then don't use their card. I'm sorry but they must be forced into being compliant otherwise all application developers will lose.

Spectrum

Totally I agree 1000000% at least the drivers should be compliant. Unfortunately there is not a standardised api facade for the filters either. Decoders, Encoders, Muxers...

I think the idea i pitched here is starting to look like it'll work for defining which tuner and capture filters belong to a card. Instead of TunerFilterCLSID and CaptureFilterCLSID you'd use TunerFilterEnumID and CaptureFilterEnumID. When i posted that i didn't know that the tuner and capture filters didn't have unique clsid's.


I just want to make sure i understand this. Let's say your app is running with a graph built and in the stopped state. Now you want to start using the card, so
[list]you try to transistion to the run state to see if the card is free

[*]you stop the graph so that you can add and connect up all the decoding and rendering filters you need

[*]you start the graph again.
[list]The problem i see with this is that during step two some other app could transition to the running state and you still don't get the card even after you've checked that it's available. It's not a very effective mutex.

At the very least you have to write code that allows BDA compliant card to work in a system where a non-BDA compliant card is installed. One bad egg shouldn't ruin the whole basket.


I agree that all BDA should be make compliant, but thinking that we're going to be able to force companies to release fully compliant BDA drivers is probably a little ambitious.

What spectrum is saying is right. If they are going to both creating BDA drivers, it should be done correctly or they are wasting their time.
If the manufacturer cannot manage this with the resources on hand, yet an end user/enthusist with minimal info on the cards hardware (i guess?) can create such a driver then there is certainly no excuse on the manufacturers part.

But as you say, its not a perfect world and we get bodgey manufacturers like VStream for example.

When (well who knows when) Dvico release their BDA drivers perhaps we will see what perhaps a more established manufacturer does in regards to meeting standards. If we are lucky (and im hoping) it will meet all Spetrum describes and is required by the BDA standard.

While ultimately the automatic "roaming" of available cards is the best way (if drivers, filters of various cards all work) I would be happy dedicated a card to WS, and having the option in WS to capture a "same time"recording on an optional second card.
This is how i understand the dual tuner Topfield box works in that each tuner is "scheduled" independantly.

D