Re: [linux-dvb] Problem using mplayer.
kevin liu wrote: Dear Nicola Mplayer can give a perfect HDTV effects, but after a period of time, it gives such complaints: Too many video packets in the buffer: (148 in 8421326 bytes). Maybe you are playing a non-interleaved stream/file or the codec failed? For AVI files, try to force non-interleaved mode with the -ni option. A:69414.9 V:69410.6 A-V: 4.281 ct: 8.984 14445/14445 44% 0% 3.6% 130 0 Too many video packets in the buffer: (148 in 8402931 bytes). Maybe you are playing a non-interleaved stream/file or the codec failed? For AVI files, try to force non-interleaved mode with the -ni option. What's the problem? maybe your system is really too slow to play that content. how is it configured? what if you use lowres=2 instead of lowres=1 ? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Mantis (vp-2033) Remote Controller
Hi, Marko asked me to provide copyright notice for the patch I sent earlier: http://www.linuxtv.org/pipermail/linux-dvb/2007-April/017403.html Here's the notice: /* Mantis RC Driver Copyright (C) 2007 Kristian Slavov ([EMAIL PROTECTED]) This program is free software; you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation; either version 2 of the License, or (at your option) any later version. This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details. You should have received a copy of the GNU General Public License along with this program; if not, write to the Free Software Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA. */ -- Kristian ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Subject: Re: Nova-T 500: Loading Firmware failed
Have you tried to download the firmware again? Maybe you've got a corrupted one so it's failing to load. Best regards, Eduard Huguet -- Missatge reenviat -- From: Tobias Hovorka [EMAIL PROTECTED] To: linux-dvb@linuxtv.org Date: Mon, 27 Aug 2007 20:53:23 +0200 Subject: Re: [linux-dvb] Nova-T 500: Loading Firmware failed On Mo, 2007-08-27 at 00:19 +0200, Christophe Thommeret wrote: Nevertheless, Im allways getting this firmware error, whether the file exists or not. ln -s /lib/firmware/2.6.20-15-generic/dvb-usb-dib0700-03-pre1.fw /lib/firmware/2.6.20-15-generic/dvb-usb-dib0700-01.fw Does not work dmesg: [428298.863237] dib0700: loaded with support for 5 different device-types [428298.948494] dvb-usb: found a 'Hauppauge Nova-T 500 Dual DVB-T' in cold state, will try to load a firmware [428298.997106] dvb-usb: downloading firmware from file 'dvb-usb-dib0700-03-pre1.fw' [428298.997118] dib0700: firmware download failed at 7 with -22 [428298.997542] usbcore: registered new interface driver dvb_usb_dib0700 Regards Tobias ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem using mplayer.
On 08/28/2007 04:47 AM, kevin liu wrote: Dear Nicola Mplayer can give a perfect HDTV effects, but after a period of time, it gives such complaints: Too many video packets in the buffer: (148 in 8421326 bytes). Maybe you are playing a non-interleaved stream/file or the codec failed? For AVI files, try to force non-interleaved mode with the -ni option. A:69414.9 V:69410.6 A-V: 4.281 ct: 8.984 14445/14445 44% 0% 3.6% 130 0 Too many video packets in the buffer: (148 in 8402931 bytes). Maybe you are playing a non-interleaved stream/file or the codec failed? For AVI files, try to force non-interleaved mode with the -ni option. What's the problem? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Your system is probably too slow. If the video looks smooth, try running mplayer with the -framedrop option. What CPU do you have and are you trying to watch MPEG2 of MPEG4 AVC? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Large arrays
On Tue, 28 Aug 2007, Manu Abraham wrote: * use integer math calculations * precompute the values where double precision is needed. That said, the first option i tried for a while, after a few days (i almost gave up ?) got really irritated with it. The second option seemed a bit more comfortable, to precalculate the values. The disadvantage in such a case is that the array which holds the precomputed value is quite large in size, with that in mind, a different question arose in my mind, whether such large arrays would be frowned upon in kernel The precomputed array is here http://www.jusst.de/manu/mc44s80x_array.c Any thoughts ? That's really inefficient. You've got about 250k of table there. I don't think a 250k+ module is going to be very popular. The table could be packed a lot better. None of the fields need to be 64-bit, so don't use unsigned long which is 64 bits on 64 bit platforms. Most of those fields don't even have 32 bits that change. For example, I can see that the last 12-bits of the refdiv field are always 0x9b2. You could put that field in 8-bits (or less, it looks like only 5 bits change). The freq field looks like it's just every 1/6th MHz from 50 Mhz to 1 GHz. Why do you need to store that? It should be trivial to calculate. unsigned int x; /* must be unsigned! Good to x=8589 1.4815 GHz*/ tuner_step_166k[x].freq = (x * 50 + 1)/3 + 5000; Or the other way around, table index from frequency: unsigned int freq, x; x = ((freq - 5000) * 3 + 25) / 50; ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Problem using mplayer.
On Tue, 28 Aug 2007, kevin liu wrote: Dear Nicola Mplayer can give a perfect HDTV effects, but after a period of time, it gives such complaints: Too many video packets in the buffer: (148 in 8421326 bytes). Maybe you are playing a non-interleaved stream/file or the codec failed? For AVI files, try to force non-interleaved mode with the -ni option. A:69414.9 V:69410.6 A-V: 4.281 ct: 8.984 14445/14445 44% 0% 3.6% 130 0 Too many video packets in the buffer: (148 in 8402931 bytes). Maybe you are playing a non-interleaved stream/file or the codec failed? For AVI files, try to force non-interleaved mode with the -ni option. What's the problem? mplayer has a very had time if there are any errors in mpeg TS streams. If your reception is 100% not perfect, it's difficult to watch with mplayer. When it gets an error, mplayer somehow gets confused and starts playing the video back slowly. The audio and video get out of sync and you get that error. You can sometimes fix it by telling mplayer to do a short seek, i.e. push the left arrow key. When you do this there is a random chance that mplayer will un-confuse itself and start playing ok again. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Tuning Regression on Hauppauge Nova-T Stick for just one channel
On Wed, 2007-08-22 at 14:43 +0200, Matthias Schwarzott wrote: Hi there! My Hauppauge Nova-T Stick works for all but one frequency now. And this did also work some time ago. Interesting, I also see this behaviour with mine... it works with all but ZDF (!) ... Soeren ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Large arrays
Trent Piepho wrote: On Tue, 28 Aug 2007, Manu Abraham wrote: * use integer math calculations * precompute the values where double precision is needed. That said, the first option i tried for a while, after a few days (i almost gave up ?) got really irritated with it. The second option seemed a bit more comfortable, to precalculate the values. The disadvantage in such a case is that the array which holds the precomputed value is quite large in size, with that in mind, a different question arose in my mind, whether such large arrays would be frowned upon in kernel The precomputed array is here http://www.jusst.de/manu/mc44s80x_array.c Any thoughts ? That's really inefficient. You've got about 250k of table there. I don't think a 250k+ module is going to be very popular. I do agree that's not the most effecient way. But given the short time span and lack of FP operations, the quick way that came to my mind was precomputed values. That said, the popularity of a module is not defined by it's size. as an eg: the nVidia module is over 1 Meg. Considering the quality/performance of the tuners in the tree we have, i don't think there would even be a popularity contest, coming anywhere near. That said, if it can be optimized, there is no reason why it shouldn't be done. I had a comment from Andrew Morton as well on it: It's large, but heck, it's not a lot of memory. The nvidia driver is a meg or something. The table could be packed a lot better. None of the fields need to be 64-bit, so don't use unsigned long which is 64 bits on 64 bit platforms. Most of those fields don't even have 32 bits that change. For example, I can see that the last 12-bits of the refdiv field are always 0x9b2. You could put that field in 8-bits (or less, it looks like only 5 bits change). True. Darren Salt did some optimizations. The optimized version is here http://zap.tartarus.org/~ds/mc44s80x_test_packed_more.c If anyone's interested, the original version with FP is here: http://paste.debian.net/35554 It 's a userspace application with which i did some crude tests. The tables are here http://jusst.de/manu/1086M_36.125M.c http://jusst.de/manu/1086M_36.166M.c The freq field looks like it's just every 1/6th MHz from 50 Mhz to 1 GHz. Why do you need to store that? It should be trivial to calculate. The 166k increment is the step size, the step size would vary with different use cases. No need to store it, but the quick way (had just 2 days with me for completing it) was that. unsigned int x; /* must be unsigned! Good to x=8589 1.4815 GHz*/ tuner_step_166k[x].freq = (x * 50 + 1)/3 + 5000; Or the other way around, table index from frequency: unsigned int freq, x; x = ((freq - 5000) * 3 + 25) / 50; Cool. Is there anything better still possible ? A thing also to note is accuracy is also important, which will decide on the time taken to Phase Lock. Thanks ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Large arrays
Henk Vergonet wrote: On Tue, Aug 28, 2007 at 12:19:57AM +0400, Manu Abraham wrote: Hi all While working on a tuner, i stumbled upon one of the usual problems (floating point operations) in kernel The options what i had were: * use integer math calculations * precompute the values where double precision is needed. That said, the first option i tried for a while, after a few days (i almost gave up ?) got really irritated with it. The second option seemed a bit more comfortable, to precalculate the values. The disadvantage in such a case is that the array which holds the precomputed value is quite large in size, with that in mind, a different question arose in my mind, whether such large arrays would be frowned upon in kernel The precomputed array is here http://www.jusst.de/manu/mc44s80x_array.c Hi Manu, What kind of calculations are we talking about? There must be a more space efficient way... The calculations what i based it upon is here: http://paste.debian.net/35554 http://jusst.de/manu/1086M_36.125M.c http://jusst.de/manu/1086M_36.166M.c Thanks ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1
Michael Krufky wrote: For the past few months, I've been working on refactoring the analog tuner.ko module, such that all hardware-specific code can be separated into dvb_frontend style tuner modules. This allows for a single module to be used by both the v4l2 tuner interface via the tuner.ko i2c_client driver, and directly by the dvb subsystem's tuning system. This refactoring process has zero impact to the way that v4l and dvb functions. I have completed phase one of the refactoring process, and now it is ready for testing and review. http://linuxtv.org/hg/~mkrufky/tuner-refactor-phase-1 Acked-by: Steven Toth [EMAIL PROTECTED] ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Subject: Re: Nova-T 500: Loading Firmware failed
On Di, 2007-08-28 at 12:41 +0200, Eduard Huguet wrote: Have you tried to download the firmware again? Maybe you've got a corrupted one so it's failing to load. Best regards, Eduard Huguet Yes. I have download this file for about 4 or 5 times, via wget and firefox. Do you have an idea where to get an older version of the firmware? ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1
Hi Michael, Em Seg, 2007-08-27 às 10:02 -0300, Mauro Carvalho Chehab escreveu: I should review the source code later today. Ok. Almost everything looked fine to my eyes. I have just one comment, about the changesets that added the MODULE_DESCRIPTION and MODULE_LICENSE macros, like on this changeset: http://linuxtv.org/hg/~mkrufky/tuner-refactor-phase-1/rev/ff52de4a4da1 This is required at the moment those files will be converted to modules. However, as, currently, they are still part of tuner, you shouldn't add those lines. On a future changeset where those drivers will be splat, you should also add MODULE_AUTHOR macro. So, I have some comments about that future patch: For tea5767 and tea5761, please add: MODULE_AUTHOR(Mauro Carvalho Chehab [EMAIL PROTECTED]) For tuner-simple, mt20xx and tda8290, I did some research. Those files started when Gerd split tuner into smaller drivers, removing tuner.c file, at -hg changeset 1578: http://linuxtv.org/hg/v4l-dvb/file/c9083c80e2f0/linux/drivers/media/video/mt20xx.c Unfortunately, -hg migration didn't preserved the full history (the tuner.c removal changeset is not there). However, we can see the other side of the history at CVS: http://linuxtv.org/cgi-bin/viewcvs.cgi/video4linux/Attic/tuner.c?root=v4lview=markup The original module author for tuner.c is marked there as: MODULE_AUTHOR(Ralph Metzler, Gerd Knorr, Gunther Mayer); This authorship line were preserved at tuner-core.c. The splitting work, however, were done by Gerd. So, IANAL, but, to respect GPL, I can see some ways: a) Preserve the original tuner.c author at the splat drivers; b) Add just Gerd Knorr to the splat drivers, and adding a comment, at the header, stating that mt20xx and tuner-simple are splat drivers originated from tuner.c, originally written by Ralph Metzler, Gerd Knorr, Gunther Mayer. c) Ask the authors for their wishes (as both Gerd and Ralph are likely subscribed at the ML, probably they'll let us know if they opt for an specific way. I'm not sure if Gunther is subscribed). For tda8290, maybe Hartmut should also be added, since he reworked some major parts of the driver logic: http://linuxtv.org/hg/v4l-dvb/rev/399222ddb2d9 -- Cheers, Mauro ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1
Mauro Carvalho Chehab wrote: Hi Michael, Em Seg, 2007-08-27 às 10:02 -0300, Mauro Carvalho Chehab escreveu: I should review the source code later today. Ok. Almost everything looked fine to my eyes. I have just one comment, about the changesets that added the MODULE_DESCRIPTION and MODULE_LICENSE macros, like on this changeset: http://linuxtv.org/hg/~mkrufky/tuner-refactor-phase-1/rev/ff52de4a4da1 This is required at the moment those files will be converted to modules. However, as, currently, they are still part of tuner, you shouldn't add those lines. Actually, the driver is split into separate modules as of the changeset entitled, tuner: alter build to produce separate modules I could have made those MODULE_DESCRIPTION and MODULE_LICENSE changes later on, but it has the same outcome, either way. On a future changeset where those drivers will be splat, you should also add MODULE_AUTHOR macro. Will add this right now. So, I have some comments about that future patch: For tea5767 and tea5761, please add: MODULE_AUTHOR(Mauro Carvalho Chehab [EMAIL PROTECTED]) OK. For tuner-simple, mt20xx and tda8290, I did some research. Those files started when Gerd split tuner into smaller drivers, removing tuner.c file, at -hg changeset 1578: http://linuxtv.org/hg/v4l-dvb/file/c9083c80e2f0/linux/drivers/media/video/mt20xx.c Unfortunately, -hg migration didn't preserved the full history (the tuner.c removal changeset is not there). However, we can see the other side of the history at CVS: http://linuxtv.org/cgi-bin/viewcvs.cgi/video4linux/Attic/tuner.c?root=v4lview=markup The original module author for tuner.c is marked there as: MODULE_AUTHOR(Ralph Metzler, Gerd Knorr, Gunther Mayer); This authorship line were preserved at tuner-core.c. The splitting work, however, were done by Gerd. So, IANAL, but, to respect GPL, I can see some ways: a) Preserve the original tuner.c author at the splat drivers; b) Add just Gerd Knorr to the splat drivers, and adding a comment, at the header, stating that mt20xx and tuner-simple are splat drivers originated from tuner.c, originally written by Ralph Metzler, Gerd Knorr, Gunther Mayer. c) Ask the authors for their wishes (as both Gerd and Ralph are likely subscribed at the ML, probably they'll let us know if they opt for an specific way. I'm not sure if Gunther is subscribed). For tda8290, maybe Hartmut should also be added, since he reworked some major parts of the driver logic: http://linuxtv.org/hg/v4l-dvb/rev/399222ddb2d9 OK -- I have taken care of the above, and pushed the changesets into my tree, along with the warning of obsolete i2c address usage. I will issue a pull request tomorrow. Thanks for your review and testing. Regards, Mike ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Subject: Re: Nova-T 500: Loading Firmware failed
I demand that Tobias Hovorka may or may not have written... On Di, 2007-08-28 at 12:41 +0200, Eduard Huguet wrote: Have you tried to download the firmware again? Maybe you've got a corrupted one so it's failing to load. Yes. I have download this file for about 4 or 5 times, via wget and firefox. Do you have an idea where to get an older version of the firmware? Should be from thadathil.net, but that's down. However, there's this: http://vaasa.wi-bw.tfh-wildau.de/~pboettch/home/files/dvb-usb-dib0700-01.fw You're probably better off using newer drivers with the new firmware, though. -- | Darren Salt| linux or ds at | nr. Ashington, | Toon | RISC OS, Linux | youmustbejoking,demon,co,uk | Northumberland | Army | + Buy less and make it last longer. INDUSTRY CAUSES GLOBAL WARMING. Jack the Ripper excused himself on the grounds that it was human nature. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1
On Monday 27 August 2007 11:01:21 am Steven Toth wrote:
Johannes Stezenbach wrote:
On Mon, Aug 20, 2007, Manu Abraham wrote:
Michael Krufky wrote:
-- this is a system-wide addition to the
dvb_frontend structure, because we are adding analog tuning
functionality to the dvb_frontend.
Analog tuning is public to DVB core ? I don't think so. It would've been
correct, if DVB core does analog operations, but DVB core doesn't do any
Analog operations.
Well, supporting hybrid tuners means that analog and digital
worlds have to touch somewhere...
I agree that elegance is very important, and that is why I disagree
with the extra layers of complexity that you are proposing here.
Every DVB demodulator driver that you write does this.
struct dvb_frontend {
struct dvb_frontend_ops ops;
struct dvb_adapter *dvb;
void* demodulator_priv;
void* tuner_priv;
void* frontend_priv;
void* sec_priv;
void* hybrid_priv;
};
So whatever that which dvb_core doesn't handle is private. I don't
understand what you mean by extra complex layer.
I think the rule of thumb is to use void* only when it points
to different things for each driver (e.g. struct tda8083_state*,
struct ves1820_state* etc.). If we know it will always point to
struct analog_parameters (or set_analog_params) then using
void* is IMHO wrong.
Using a forward decl for struct analog_parameters and putting
struct analog_parameters somewhere else like Hans suggested
would be OK, but doesn't seem that important to me. I mean the
whole separation of analog and digital tuning APIs is artificial
and is just a result of how development happend in two distinct
communities historically. Why spent any effort to keep them
completely seperate instead of letting them grow together?
I'm glad someone else also raised this. The legacy of two different
video/tv frameworks has been biting for a long time, and will continue
to do so. Issues like a forward declaration vs anything else feels
irrelevant and trivial to me, especially when I look at the overall
problems with having one concept (tv/video) in two distinct frameworks.
We should be striving for a unified tuning API which abstracts all
frontend types, regardless of the underlying hardware. I know we cannot
make that leap quickly, it's going to take constant refinement over a
series of years. That being said, knowing how difficult it can be to get
things accepted, these patches are a net gain to the project and I have
no immediate objections.
... I'm still reading, more later.
Anyway, I think it's not a fundamental issue and could be
changed at any time without affecting the basic approach
this proposal takes to implement hybrid tuners.
I'm a bit late to the party... I concur with Steven and Johannes here, its not
a huge deal exactly where the analog tuning bits land. But between the choice
of Mike's current tree and something with forward declarations, I'd take
Mike's approach. Ultimately, I suppose it'd be nice if they weren't in
dvb_frontend.h, since the d in dvb is digital, but with more and more hybrid
analog/digital cards, it just makes sense to put 'em all in one convenient
place. The less obfuscation the better.
I'm all for the changes too, feel free to add:
Acked-by: Jarod Wilson [EMAIL PROTECTED]
--
Jarod Wilson
[EMAIL PROTECTED]
___
linux-dvb mailing list
linux-dvb@linuxtv.org
http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1
Am Dienstag, den 28.08.2007, 16:25 -0400 schrieb Michael Krufky: Mauro Carvalho Chehab wrote: Hi Michael, Em Seg, 2007-08-27 às 10:02 -0300, Mauro Carvalho Chehab escreveu: I should review the source code later today. Ok. Almost everything looked fine to my eyes. I have just one comment, about the changesets that added the MODULE_DESCRIPTION and MODULE_LICENSE macros, like on this changeset: http://linuxtv.org/hg/~mkrufky/tuner-refactor-phase-1/rev/ff52de4a4da1 This is required at the moment those files will be converted to modules. However, as, currently, they are still part of tuner, you shouldn't add those lines. Actually, the driver is split into separate modules as of the changeset entitled, tuner: alter build to produce separate modules I could have made those MODULE_DESCRIPTION and MODULE_LICENSE changes later on, but it has the same outcome, either way. On a future changeset where those drivers will be splat, you should also add MODULE_AUTHOR macro. Will add this right now. So, I have some comments about that future patch: For tea5767 and tea5761, please add: MODULE_AUTHOR(Mauro Carvalho Chehab [EMAIL PROTECTED]) OK. For tuner-simple, mt20xx and tda8290, I did some research. Those files started when Gerd split tuner into smaller drivers, removing tuner.c file, at -hg changeset 1578: http://linuxtv.org/hg/v4l-dvb/file/c9083c80e2f0/linux/drivers/media/video/mt20xx.c Unfortunately, -hg migration didn't preserved the full history (the tuner.c removal changeset is not there). However, we can see the other side of the history at CVS: http://linuxtv.org/cgi-bin/viewcvs.cgi/video4linux/Attic/tuner.c?root=v4lview=markup The original module author for tuner.c is marked there as: MODULE_AUTHOR(Ralph Metzler, Gerd Knorr, Gunther Mayer); This authorship line were preserved at tuner-core.c. The splitting work, however, were done by Gerd. So, IANAL, but, to respect GPL, I can see some ways: a) Preserve the original tuner.c author at the splat drivers; b) Add just Gerd Knorr to the splat drivers, and adding a comment, at the header, stating that mt20xx and tuner-simple are splat drivers originated from tuner.c, originally written by Ralph Metzler, Gerd Knorr, Gunther Mayer. c) Ask the authors for their wishes (as both Gerd and Ralph are likely subscribed at the ML, probably they'll let us know if they opt for an specific way. I'm not sure if Gunther is subscribed). For tda8290, maybe Hartmut should also be added, since he reworked some major parts of the driver logic: http://linuxtv.org/hg/v4l-dvb/rev/399222ddb2d9 OK -- I have taken care of the above, and pushed the changesets into my tree, along with the warning of obsolete i2c address usage. I will issue a pull request tomorrow. Try to preserve it from the beginning, like pointed already to Manu. Gerd has at least a early bttv snapshot at cvs.bytesex.org. There have been archives on the web with all bttv releases, lost the links. http://dl.bytesex.org/releases/video4linux The oldest bttv release for tuner stuff. We don't steal code and have full respect to the early hackers, without anything in their hands, but also to latest with something, which often is not enough. Hermann ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Looking for hybrid/combo USB tuner for UK.
Hi all, I'm moving to an area of Ipswich where I've heard mixed reports about the quality/availability of digital TV, so I'd like to get a TV tuner that handles analogue as well as DVB-T. For various reasons I've opted for USB instead of PCI/PCMCIA, however finding a tuner that meets both these criteria and will work with Linux is proving rather hard - everything I've found either isn't mentioned in linuxtv's wiki or only has experimental support with Em2880 - and I can't find out what people's experience with this has been. Does anyone have any recommendations for UK-available USB hybrid or combo devices, or experiences of using such that they're willing to share? Thanks, James McLaughlin. Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos more. http://mobile.yahoo.com/go?refer=1GNXIC ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] Technotrend S-1500 with CI: common interface is not detected
On 04/06/2007 09:09 PM, Will Tatam wrote: I had similar issues with this board until i used the current development tree of linux-dvb rather than a stock kernel. I could then get apps like Myth to see I had a cam, but I never worked out know to setup my dragon cam properly to work with my legal viewing card Will Tatam P. van Gaans wrote: I'll try to keep it short. I've got a TT S-1500 and the CAM can not be seen in /dev/dvb/adapter. It doesn't work either, no encrypted channel lights up. FTA channels do. However, on my KNC1 DVB-C with Cineview, there is a ca0 in /dev/dvb/adapter and in Kaffeine I can watch encrypted channels. In dmesg I see info for the KNC1 card when ejecting/inserting CAMs, not a single line with info about the CI on the TT. I don't see in what other way I could possibly connect the TT budget CI to the card (the hardware). The CAM is not upside-down. The CAM was tested in another receiver and works. I have the latest v4l-dvb drivers. Ubuntu 6.10 Edgy. Any help is appreciated. ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb Late reply, but I figured it out. The cable is OK. The v4l-dvb code is OK. The CI daughterboard is OK. I replaced the S-1500 card itself with a spankin' new S-1500 and the problems were gone. So my first Technotrend S-1500 is broken, at least it's CI-connector. I felt I should post the solution now that I solved it. And by the way, made a big update to the CAM tests at http://linuxtv.org/wiki/index.php/TechnoTrend_TT-budget_S-1500 ;). ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
Re: [linux-dvb] [RFC] Hybrid tuner refactoring, phase 1
Michael Krufky wrote: For the past few months, I've been working on refactoring the analog tuner.ko module, such that all hardware-specific code can be separated into dvb_frontend style tuner modules. This allows for a single module to be used by both the v4l2 tuner interface via the tuner.ko i2c_client driver, and directly by the dvb subsystem's tuning system. This refactoring process has zero impact to the way that v4l and dvb functions. I have completed phase one of the refactoring process, and now it is ready for testing and review. http://linuxtv.org/hg/~mkrufky/tuner-refactor-phase-1 A brief description of the individual changesets follows: - tuner: kill i2c_client interface to tuner sub-drivers This changeset removes the i2c_client interface between tuner.ko and the tuner sub-drivers. The i2c_client interface to tuner.ko, itself, remains the same as it has been -- this is only an internal change that affects the interaction between tuner.ko and the hardware-specific code. Some helper functions and macros were added in this changeset, in order to ease the conversion process, without causing headaches or breakage. (see tuner-i2c.c) We can remove these extra structs and helper functions after the refactoring process is complete. - hybrid tuner refactoring core changes, phase 1 This changeset contains the more interesting work, where tuner-core is altered to support attachment of dvb_frontend style tuner modules. An additional method set_analog_params was added to struct dvb_tuner_ops, so as to avoid altering the DVB subsystem userspace API headers. This change does not create any dependency of the DVB subsystem on V4L, nor does it create any dependency of the V4L subsystem on DVB. - tda8290: convert from tuner sub-driver into dvb_frontend module - mt20xx: convert from tuner sub-driver into dvb_frontend module - tea5761: convert from tuner sub-driver into dvb_frontend module - tea5767: convert from tuner sub-driver into dvb_frontend module - tuner-simple: convert from tuner sub-driver into dvb_frontend module These changesets handle the conversions of the individual tuner sub-drivers into dvb_frontend style tuner modules. - tuner: alter Makefile to produce separate modules This changeset makes the changes to the build system, required for building the tuner sub-drivers as separate modules, and the ability to deselect undesired tuner sub-drivers via Kconfig. -- What comes next? After phase 1 of hybrid tuner refactoring is merged into the master branch, there is no change to the behavior of the drivers, apart from the fact that users will now have the ability to deselect undesired tuner sub-drivers via Kconfig. I have the following changes planned for hybrid tuner refactoring, phases 2, 3 and 4: - analog if demodulator refactoring In this step, an internal api for analog IF demods will be created, allowing us to refactor the tda9887 module, and also to handle tda8290 separately from the tda8275 and tda8275a tuners. - tda8290 refactoring In addition to the analog if demodulator refactoring, duplicated code for the tda8275 and tda8275a tuners between tda8290.ko and tda827x.ko shall be consolidated. In addition, support for the tda8295 and tda18271 devices will be added. - tuner-simple refactoring Tuner-simple will be cleaned up to take on more of an object-oriented approach, and duplicated code for certain tuners present in both tuner-simple and dvb-pll shall be consolidated. - miscellaneous work and additional cleanups mt20xx shall be cleaned up to properly handle tuning requests from the DVB subsystem, rather that going through tuner.ko -- this is a very small change, but I decided to wait on this until after phase 1 is merged into master. Support for new hybrid tuner hardware will now be _much_ easier to develop and add into the v4l-dvb codebase. -- I'd like to thank all of the people that have looked this over thus far, whom have given suggestions on how I can make this better and easier to review. If there are any other questions, comments or concerns, I would love to hear them. Please don't be shy -- feel free to let me know if you like or dislike this approach. I'd like to have this merged as soon as possible, so that I may continue to work on the items mentioned about in the What comes next? section. Now, it's time to go out and party! I will be able to respond to any comments tomorrow afternoon. While I currently don't have the time to completely review all changesets, the proposal looks fine to me. The dvb_frontend extensions are ok. Acked-by: Oliver Endriss [EMAIL PROTECTED] CU Oliver -- VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/
Re: [linux-dvb] [PATCH] add device node locking possibility to dvbcore
Johannes Stezenbach wrote: On Sun, Aug 19, 2007, Oliver Endriss wrote: Questions: - Why should dvb_shutdown_timeout==0 disable sleep mode? The use case was to watch video without any software running. Just program the hardware once and let it do it's job. Some people want that although I don't think it's really useful. (Works for FF cards only, of course.) - Does it make any sense to have LNB power 'on' and the frontend in sleep mode? No. Imho these should be controlled by dvb_powerdown_on_sleep alone, for example: Sounds good to me. Ok. Default value for dvb_shutdown_timeout set to 0: http://linuxtv.org/hg/v4l-dvb/rev/56556c094e04 dvb_powerdown_on_sleep controls fe sleep _and_ LNB power: http://linuxtv.org/hg/v4l-dvb/rev/9b00ad43d7f3 ts_bus_ctrl fixed: http://linuxtv.org/hg/v4l-dvb/rev/e09c063c28dd Afaics fe locking can be done using ts_bus_ctrl now (iff dvb_shutdown_timeout == 0). CU Oliver -- VDR Remote Plugin 0.3.9: http://www.escape-edv.de/endriss/vdr/ ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
[linux-dvb] Hauppauge WINTV Nova-T 500 PCI
I am trying to setup a MythTV backend with two Hauppauge WINTV Nova-T 500 PCI, which means in total 4 adapters (2 per card). The system are running Kubuntu 7.04 (64 bit) with kernel 2.6.20-16. The cards are installed and dmesg shows that the cards are found correctly. When scanning for channels, I can not receive all channels on all adapters and the signal strength is about 50-65%. When testing the antenna cables connected to a regular DVB-T box I get signal strength about 91%. On 2 and sometimes 3 adapters I can get all channels but have not succeeded on all adapters. I have set options dvb-usb-dib0700 force_lna_activation=1 in /etc/modprobe.d/options The firmware I am using is dvb-usb-dib0700-03-pre1.fw and yesterday I tried to downgrade to dvb-usb-dib0700-01.fw but I was not able to load that, always tried to load the previous one (which I deleted to avoid conflicts). - What should I investigate to get this working? - What firmware should I use? - How can I do a firmware upgrade/downgrade? The cards is installed according to this guide: http://mythtv.org/wiki/index.php/Hauppauge_WinTV_Nova-T_500_PCI I would really appreciate any help on this. BR Joacim ___ linux-dvb mailing list linux-dvb@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/linux-dvb
