Menu
▾
▴
bdadev-discuss — Discussion about BDA developement
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
(30) |
Mar
(3) |
Apr
(17) |
May
(17) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(6) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(1) |
Nov
|
Dec
|
|
From: Alan S. <asc...@bb...> - 2006-10-04 08:36:18
|
Hi I am developing a DVB-T, DVB-S, ATSC BDA device driver. I've downloaded the source code for the Nova-T driver and the DDK example code (Europa, BDACap, and BDATuner) for examples. Most of it seems to work well. I am having trouble with the Signal strength scan feature. The scan tunes to each frequency but moves on to the next frequency without waiting long enough to lock. The Nova-T and the DDK examples seem to have the same problem. Has anyone else seen this problem? If so, how did you fix it? In advance, Thanks, Alan |
|
From: <ben...@id...> - 2004-05-22 12:46:38
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Dmitry V. <da...@el...> - 2004-01-28 15:42:02
|
Hi all, I'm developing DVB-S BDA device driver. I've download your sorce codes = and was interested by them. My question is: Does your BDA Driver operate with Microsoft Network Provider or not. If = it operates can I connect your filter with Microsoft DVB-T Network = Provider it the GraphEditor? Best Regards, Dmitry Vergheles Solveig Multimedia |
|
From: John A. <Jo...@ad...> - 2004-01-23 08:47:20
|
> Does the BDA driver include support for the new Nova-T card? I've got = the driver working really well with an old pre-2003 Nova-t and some of = my own > recording software but I can't get it to work with a new one = I've bought. =20 Simon =20 Sadly the new card has a different tuner and demod chip and so the = driver would have to be heavily modified to use the new card. This = probably wouldn't be as bad a job as you might first think if you want = to have a go yourself as the Linux sources apparently work for this = card. =20 John |
|
From: Simon D. <si...@sd...> - 2004-01-22 22:42:26
|
Hi, Does the BDA driver include support for the new Nova-T card? I've got the driver working really well with an old pre-2003 Nova-t and some of my own recording software but I can't get it to work with a new one I've bought. Cheers, Simon |
|
From: Colin D. M. <li...@mi...> - 2003-12-02 03:24:09
|
Quoting Robert Schlabbach <rob...@gm...>: > BTW, Colin, while I got you on the list: It appears your driver has no > support for power management (just like mine:(). Have you looked into this, > or do you know of a good resource? I tried reading the DDK documentation, > but it only left me confused :( > I've not really looked at the power management stuff, and since I just recently upgraded to Windows XP I've not reinstalled the DDK yet (although I will soon). > The key thing one has to do is to restore the hardware state after resuming > e.g. from hibernating (i.e. complete power-off). Now the ugly thing about > this is that if a BDA graph is running when you hibernate, it will only be > put in _paused_ state, not stopped! Thus, you need to get the hardware back > exactly to that paused state, which I think is rather complicated... Or > maybe there is a way to request that the graph is put in stopped state? I > haven't found any, though :( I suppose if you stored the state of what you were told to do you could re-set the parameters of the card when you were awoken so the graph wouldn't realise anything had changed, but that could be tricky to make work, it seems a bit annoying that it only pauses. I'll have a look once I've re-installed the DDK to see if I can spot anything but I'm not sure if it's just going to have to be done a difficult way or such. Sorry I couldn't be of more help, Colin |
|
From: John A. <Jo...@ad...> - 2003-11-26 08:52:44
|
> I just wondered if any of you had seen this yet: >=20 > http://www.technotrend.de/english/download/sdk.html I got both the BDA and non-BDA SDK's. The BDA driver doesn't appear to work at all well and just locks the CPU. It appears to be based on the philips sample code so has a split tuner and capture driver. I didn't get it working properly with any software so I gave up. I haven't had a chance to look properly at the other SDK. John |
|
From: Robert S. <rob...@gm...> - 2003-11-26 07:14:01
|
BTW, Colin, while I got you on the list: It appears your driver has no support for power management (just like mine:(). Have you looked into this, or do you know of a good resource? I tried reading the DDK documentation, but it only left me confused :( The key thing one has to do is to restore the hardware state after resuming e.g. from hibernating (i.e. complete power-off). Now the ugly thing about this is that if a BDA graph is running when you hibernate, it will only be put in _paused_ state, not stopped! Thus, you need to get the hardware back exactly to that paused state, which I think is rather complicated... Or maybe there is a way to request that the graph is put in stopped state? I haven't found any, though :( Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
|
From: Robert S. <rob...@gm...> - 2003-11-26 07:10:11
|
From: "Colin D. Munro" <li...@mi...> > Hmm, doesn't sound too great. I gave the licence a quick look before > deciding to go for it and I didn't think it'd interfere with anything > else I was doing though (other than in the possible "Windows gets > confused as to which drivers are even compatible" problems I had even > with my own driver), what did you see to be a problem? Perhaps I > shouldn't post the letter tomorrow. Well, I don't like the "no reverse engineering" paragraph. Consider this: You make some enhancement to your driver, and TT comes and claims you stole that idea from their driver... Maybe they are nice guys and would never do such a thing, I don't know. But I'd rather be safe than sorry... Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
|
From: Colin D. M. <li...@mi...> - 2003-11-25 23:00:45
|
Quoting Robert Schlabbach <rob...@gm...>: > From: "Colin D. Munro" <li...@mi...> > > I just wondered if any of you had seen this yet: > > http://www.technotrend.de/english/download/sdk.html > > Yes, I heard about that last August. I didn't want to sign the NDA, though, > for fear it might undermine my own driver development efforts. But from > what I have heard, this driver might be based on the Philips SAA7146A > capture driver coupled with a separate frontend driver binary (I driver > model I dislike very much). > Hmm, doesn't sound too great. I gave the licence a quick look before deciding to go for it and I didn't think it'd interfere with anything else I was doing though (other than in the possible "Windows gets confused as to which drivers are even compatible" problems I had even with my own driver), what did you see to be a problem? Perhaps I shouldn't post the letter tomorrow. > Also, this driver appears to be incompatible with Windows XP Media Center > Edition right now. From the user comments found in the public MCE > newsgroups, it doesn't seem to work well either... > Hmm, doesn't sound like it's too great at all... Colin |
|
From: Robert S. <rob...@gm...> - 2003-11-25 22:25:35
|
From: "Colin D. Munro" <li...@mi...> > I just wondered if any of you had seen this yet: > http://www.technotrend.de/english/download/sdk.html Yes, I heard about that last August. I didn't want to sign the NDA, though, for fear it might undermine my own driver development efforts. But from what I have heard, this driver might be based on the Philips SAA7146A capture driver coupled with a separate frontend driver binary (I driver model I dislike very much). Also, this driver appears to be incompatible with Windows XP Media Center Edition right now. From the user comments found in the public MCE newsgroups, it doesn't seem to work well either... Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
|
From: Colin D. M. <li...@mi...> - 2003-11-25 22:04:12
|
Hiya I just wondered if any of you had seen this yet: http://www.technotrend.de/english/download/sdk.html Apparently if you print and fill in the licence they'll send you an SDK (one of which appears to be a BDA driver) for their budget card (and various other things too). I'm going to post one for the "TT-PCline budget and TT-PCline USB" and one for the "TT-PCline budget and the BDA-Driver" assuming they're different, and see if I get anything back. Colin Munro |
|
From: Robert S. <rob...@gm...> - 2003-05-24 00:03:24
|
Hi, I went out and bought myself a DVB-T card today, branded "Lorenzen SL DVB-T PCI". It is actually another Technotrend "budget" design, but a completely new one. The board is marked "TT2002.52", "B2T1110", "Rev1.1" and has the PCI ID PCI\VEN_1131&DEV_7146&SUBSYS_110113C2. The DVB-T frontend has been changed completely: Instead of the Grundig tuner module, there is now: 1. Philips TDM1316L Tuner Module (UHF/VHF) 2. Philips TDA9889 DVB AGC Amplifier 3. Philips TDA10045H DVB-T Demodulator The PCI chip is still the same old SAA7146A. It looks like the board is ready for a CI module connector, but this has not been equipped on my card. Anyway, the point is: Supposedly, Hauppauge is now selling _this_ card in the UK, still branded as "NOVA-T". I have seen some unhappy remarks from Linux users who found their new card will not work with any existing Linux driver. You may want to add some comment to your Nova-T BDA driver in the CVS that this will not work with the newer Nova-T incarnation... Unfortunately, the programming information for the TDM1316L and the TDA10045H do not seem to be available yet, the Linux guys are struggling to get at them as well :( If any of you come across these or know where to get them, please let me know... P.S.: I tried the card with the Technotrend software and got pretty ok results - 25 TV stations total available here, all free-to-air :) Can anyone beat that? :) Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
|
From: John A. <Jo...@ad...> - 2003-05-06 08:10:07
|
> e.g. have it check the > DirectX version and if it's still < 10.0 (or at whatever number = Microsoft > finally get their act together) apply the workaround, otherwise not. From what I've picked up so far we're going to be running on DX 9 for = some time, hopefully 9.0a is the first of many patches, some hopefully = including DVB fixes. I think our biggest probelm is the chicken and egg = situation with working BDA, no vendors are shipping BDA drivers because = it doesn't work and MS won't fix the problems because no vendors are = pressing them for fixes. I'm asuming we're well off the radar. > So I'd say let's do the "right thing" in > all the places we can do it right now, and only implement workarounds = for > missing MS BDA functionality where it's needed... OK that's a good principle. =20 John |
|
From: Robert S. <rob...@gm...> - 2003-05-02 22:42:02
|
From: "John Adcock" <Jo...@ad...>
> I'd go with what's easier and having registry settings per country
> is easier, rmeber that at the very least we are going to need to
> check the physical location of the user as part od any install
> routine and at this point we can set up things like this quite
> easily. I agree that MS have some work to do here but I think we
> can easily bypass the problems.
I agree with that, but I think we should leave the driver in a "bugfix
ready" state, so that it works right as soon as Microsoft's components
start working right. IMHO having the workaround in the application makes it
easier to remove it, or even make it "autodetect" - e.g. have it check the
DirectX version and if it's still < 10.0 (or at whatever number Microsoft
finally get their act together) apply the workaround, otherwise not.
After all, the IDVBTLocator object in the IDVBTuneRequest already holds all
the DVB-T parameters. So all we'd implement as a workaround would be
something like:
Result = Tuner->put_TuneRequest(ourDVBTuneRequest);
if (Result == S_OK)
{
if (DirectXVersion < FixedDirectXVersion)
{
// find IBDA_DigitalDemodulator node
// query DVB-T parameters from TuneRequest's Locator
// pass DVB-T parameters through IBDA_DigitalDemodulator methods
};
};
Keep in mind that even with the fixed Microsoft components, the
"country-specific" DVB-T parameters would _still_ need to be determined and
put in place in the IDVBTLocator. So I'd say let's do the "right thing" in
all the places we can do it right now, and only implement workarounds for
missing MS BDA functionality where it's needed...
Regards,
--
Robert Schlabbach
e-mail: rob...@gm...
Berlin, Germany
|
|
From: John A. <Jo...@ad...> - 2003-05-02 19:14:44
|
> Hmm, I would not go through such workarounds.=20 I'd go with what's easier and having registry settings per country is easier, rmeber that at the very least we are going to need to check the physical location of the user as part od any install routine and at this point we can set up things like this quite easily. I agree that MS have some work to do here but I think we can easily bypass the problems. John |
|
From: Robert S. <rob...@gm...> - 2003-05-02 19:02:57
|
From: "John Adcock" <Jo...@ad...> > > Thus, the driver must be HARDCODED for each area which has different > > settings for these two parameters. > > Hardcoded is a bit strong, but these have to be set via some other means, > like the registry for example. An can't simply be set via the api which > I agree with Robert is very silly. I did try adding registry access for > these parameters expecting something like this coming up. I'll try a bit > harder. Hmm, I would not go through such workarounds. IIRC, the IBDA_DigitalDemodulator device interface *does* work properly and is able to pass down the DVB-T parameters. So instead of modifying the driver, I would suggest either modifying the application to pass down these parameters through the device interface, or replacing the DVB Network Provider, whose task it is to do that in the first place (but which Microsoft's DVB-T NP apparently neglects to do). Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
|
From: John A. <Jo...@ad...> - 2003-05-02 15:50:18
|
> I thought the BDA would be a polished API, but apparently I was = wrong... The API is actually OKish, the implementation on the other hand is = terrible ;) =20 I'm hoping that with a rewritten TIF then a fairly nice TV app is at = least possible, but at a minimum we need to redo that component. =20 John |
|
From: John A. <Jo...@ad...> - 2003-05-02 15:44:47
|
> Thus, the driver must be > HARDCODED for each area which has different settings for these two >parameters. Hardcoded is a bit strong, but these have to be set via some other = means, like the registry for example. An can't simply be set via the = api which I agree with Robert is very silly. I did try adding registry = access for these parameters expecting something like this coming up. = I'll try a bit harder. =20 John =20 =20 |
|
From: Jani A. <ja...@ka...> - 2003-05-02 14:10:37
|
On Fri, 2 May 2003, Robert Schlabbach wrote: > > Does the Technotrend's software give all that information? > No, but the magic of the Internet. Once again, thanks to the Linux > community: > > http://nrg.joroinen.fi/dvb-minihowto/conf.html#AEN127 Damn, I missed that piece of information when I browsed through those pages... Is that information same for every channel? The channel listed there was subTV which will do nice when I try to test my card. :) > Note 5. and 6. - this means you will have to MODIFY and RECOMPILE the > driver, because these parameters are different for the UK (which uses 1/32 > and 2K), and these two parameter can *NOT* be autodetected by TPS, because > they influence how the TPS is transmitted, i.e. if these are wrong, the > demodulator will never get the get the TPS data with the reception > parameters. Ok, modify those values and recompile. > Now you may ask why it's not sufficient if I set these parameters in my > app - and the answer is yet another bug in the BDA: It does not pass down > *ANY* DVB-T specific parameters to the driver! Thus, the driver must be > HARDCODED for each area which has different settings for these two > parameters. Eh? That's so fucking stupid... Then there's two possibilities; different drivers for every country or some kind of setup program which will save that information into registry to be used by the driver. > Now, to the carrier frequency. Please go here: > > http://www.digita.fi/english/digita_alasivu.asp?path=1841;2080;2130;2132 > > Which of these stations are you getting your signal from? I'm using the Lapua's transmitter (A:38:610MHz, B:55:746MHz, C:37:602MHz). And that subTV channel is in the B multiplex, if that matters... > BTW, good to see that Finland is sticking to the standard European UHF > channels and not using those twisted frequencies that the UK does. :) Well, if it isn't broken, don't fix it. Right? :) > > The transmission coverage doesn't mean that there's DVB-T receivers in > > every household. At the moment, only about 50 thousand receivers has been > > sold to customers, so percentually that's quite small number of people > > who can actually watch DVB-T broadcasts. :) > Well, here in Germany, only the Berlin area has been officially switched > over to DVB-T, with only about 125.000 _potential_ users. I suppose the > number of actual DVB-T users is significantly less... How long the analog broadcast will continue in Germany? In Finland they will stop in 2006, or that's what has been planned, I think Digita will extend that time by year or two. - Jani |
|
From: Robert S. <rob...@gm...> - 2003-05-02 12:36:33
|
From: "Jani Alanen" <ja...@ka...> > On Thu, 1 May 2003, Robert Schlabbach wrote: > > 1. Carrier frequency > > 2. Inner FEC rate (e.g. 2/3) > > 3. Modulation type (e.g. QAM-64) > > 4. Channel bandwidth (e.g. 8MHz) > > 5. Guard interval (e.g. 1/32) > > 6. Transmission mode (e.g. 2K) > > Does the Technotrend's software give all that information? No, but the magic of the Internet. Once again, thanks to the Linux community: http://nrg.joroinen.fi/dvb-minihowto/conf.html#AEN127 In section 5.3. we find: 2. Inner FEC rate = 2/3 3. Modulation type = QAM-64 4. Channel bandwidth = 8 MHz 5. Guard interval = 1/8 (!!!!!!) 6. Transmission mode = 8K (!!!!!!!!) Note 5. and 6. - this means you will have to MODIFY and RECOMPILE the driver, because these parameters are different for the UK (which uses 1/32 and 2K), and these two parameter can *NOT* be autodetected by TPS, because they influence how the TPS is transmitted, i.e. if these are wrong, the demodulator will never get the get the TPS data with the reception parameters. Now you may ask why it's not sufficient if I set these parameters in my app - and the answer is yet another bug in the BDA: It does not pass down *ANY* DVB-T specific parameters to the driver! Thus, the driver must be HARDCODED for each area which has different settings for these two parameters. Now, to the carrier frequency. Please go here: http://www.digita.fi/english/digita_alasivu.asp?path=1841;2080;2130;2132 Which of these stations are you getting your signal from? BTW, good to see that Finland is sticking to the standard European UHF channels and not using those twisted frequencies that the UK does. :) > > > Currently he transmission area covers over 70 % of the Finnish > > > households. There are 9 national digital channels. > > The transmission coverage doesn't mean that there's DVB-T receivers in > every household. At the moment, only about 50 thousand receivers has been > sold to customers, so percentually that's quite small number of people > who can actually watch DVB-T broadcasts. :) Well, here in Germany, only the Berlin area has been officially switched over to DVB-T, with only about 125.000 _potential_ users. I suppose the number of actual DVB-T users is significantly less... Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
|
From: Jani A. <ja...@ka...> - 2003-05-02 08:54:46
|
On Thu, 1 May 2003, John Adcock wrote: > SimpleTV has hardcoded values for the frequency and other setup. BDAViewer > has a channel scan but doesn't work for me at least and CleverTelly is > XP only (and requires some independant setup). So as you can see it's > all a bit of a mess. I would like to try BDAViewer, but as with everything else in the CVS, I can't compile it (that's the case until I get some of my Delphi code into it)... :) I'll do some hard work this weekend and maybe then I have some code ready to submit to this project, we'll see... > I'm not quite as pessimistic as Robert on what's there but I agree with the > overall sentiment that there is a lot of work to do. I thought the BDA would be a polished API, but apparently I was wrong... > It's probably worth having a bash at getting a picture with graphedit and > then taking things from there. Yep, and that would require our own TIF, right? I can't see any other way to do TuneRequests in GraphEdit. - Jani |
|
From: Jani A. <ja...@ka...> - 2003-05-02 08:46:48
|
On Thu, 1 May 2003, Robert Schlabbach wrote: > From: "John Adcock" <Jo...@ad...> > > I'm not quite as pessimistic as Robert on what's there but I agree > > with the overall sentiment that there is a lot of work to do. > > The problem with Microsoft's (actually Intel's) BDA TIF is that it has no > means of caching anything at all - every time you turn it on _or even > change the multiplex_, it first has to receive all the necessary DVB SI > tables before it can tune in to any service - and that can take up to 30 > seconds. 30 seconds to switch the station is not bearable, IMHO. And AFAIK > there is absolutely nothing you can do about it, as there is no means to > pass it the full information it needs - it will only take the tables from > the live data stream, and no way other. That's incredibly stupid, if that's how it really works. And I thought the Technotrend's TV app was slow on channel switching... > Another thing is the Network Provider, which IMHO has an architectural > problem: It can (AFAIK) tune only into exactly _one_ service at a time. > Unfortunately, Teletext is always a _separate_ service, and not a component > of a TV service. Thus, you could only either have TV and no Teletext, or > Teletext and no TV. Stupid, eh? How about EPG, is it part of the TV service, or a separate service? I'd guess it's part of the TV feed, but knowing Microsoft's style of doing things, everything's possible... > I think one would have to implement a completely new Network Provider, > possibly even with a new interface, that allows tuning into several > services on the same multiplex at once. At least 3 simultaneous services > should be possible: TV, Teletext and IP. Is there any good documentation available of NP's internal workings? Some kind of dumper filter is needed for recording anyway, but that should be easy to implement and plug into graph before MPEG-2 splitter/demultiplexer, or after that and create AVI with MPEG-2 audio/video content. Subtitles might be quite interesting to implement, at least for recordings. Those could be saved on a separate file as .srt or something similar, and actually that looks like the only way, otherwise one must encode the audio and video again with subtitles "burned" into the picture and then save that stream to disk... Another thing is broadcasts with multiple audio streams, those and subtitles are videly used here in Finland... - Jani |
|
From: Jani A. <ja...@ka...> - 2003-05-02 07:59:41
|
On Thu, 1 May 2003, Robert Schlabbach wrote: > From: "Jani Alanen" <ja...@ka...> > > There's only one problem. As I said to John, I can't compile any of that > > code in the CVS except the driver. If you could compile and send me the > > SimpleTV that would be great. > > No problem, but since SimpleTV simply [;)] tunes in to a hardcoded service, > I need the data of the transport stream you want to tune in to, i.e. the > following parameters: > > 1. Carrier frequency > 2. Inner FEC rate (e.g. 2/3) > 3. Modulation type (e.g. QAM-64) > 4. Channel bandwidth (e.g. 8MHz) > 5. Guard interval (e.g. 1/32) > 6. Transmission mode (e.g. 2K) Does the Technotrend's software give all that information? I don't know where else to find that kind of information. > > Currently he transmission area covers over 70 % of the Finnish > > households. There are 9 national digital channels. > Wow, and I thought the UK was #1 in DVB-T :) Looks like Finland is ahead of > all the rest of us :) The transmission coverage doesn't mean that there's DVB-T receivers in every household. At the moment, only about 50 thousand receivers has been sold to customers, so percentually that's quite small number of people who can actually watch DVB-T broadcasts. :) - Jani |
|
From: Robert S. <rob...@gm...> - 2003-05-01 12:11:09
|
From: "John Adcock" <Jo...@ad...> > I'm not quite as pessimistic as Robert on what's there but I agree > with the overall sentiment that there is a lot of work to do. The problem with Microsoft's (actually Intel's) BDA TIF is that it has no means of caching anything at all - every time you turn it on _or even change the multiplex_, it first has to receive all the necessary DVB SI tables before it can tune in to any service - and that can take up to 30 seconds. 30 seconds to switch the station is not bearable, IMHO. And AFAIK there is absolutely nothing you can do about it, as there is no means to pass it the full information it needs - it will only take the tables from the live data stream, and no way other. There is a way to switch almost instantly between services on the same multiplex, but that's all you can achieve. I suppose you'd be fine if you have only one multiplex in your area ;) Another thing is the Network Provider, which IMHO has an architectural problem: It can (AFAIK) tune only into exactly _one_ service at a time. Unfortunately, Teletext is always a _separate_ service, and not a component of a TV service. Thus, you could only either have TV and no Teletext, or Teletext and no TV. Stupid, eh? Same goes for data services (TCP/IP over DVB), but that one is even uglier: For TCP/IP over DVB, one would desire to have it _always_ receive TCP/IP data, as a "background app", regardless whether the TV app is currently running or not. I suppose the only solution to that would be to have those two be the one and same application, i.e. the TV app should be able to "silently" run in the background receiving IP data... I think one would have to implement a completely new Network Provider, possibly even with a new interface, that allows tuning into several services on the same multiplex at once. At least 3 simultaneous services should be possible: TV, Teletext and IP. Regards, -- Robert Schlabbach e-mail: rob...@gm... Berlin, Germany |
