Re: [ivtv-devel] Re: ivtv PVR-350 MPEG encoding/decoding delay
Andrew Lunn wrote: Brendan Hoar wrote: On Tue, 20 Sep 2005, Chris Kennedy wrote: Rolf Kistler wrote: Hi all, We have used ivtv and two PVR-350 to successfully to stream mpeg-2 Video/Audio data over the network using on one side the analog composite input (camera) and on the other side the analog composite output (TV screen). As long as one wants to transport surveillance data or a movie, this solution just works fine. Now the problem is that if the task is to control a camera or talk to someone on the other end, the 2-3 seconds delay in our system is too much. This is from it being compressed video, encoding always will introduce a delay, in every encoding system out there. I would expect the delay to be determined my the pattern of I, B and P frames. I guess the minimum delay is that of between two I frames. What patterns of I, P and B does the PVR-350 use? How often does it repeat? Say it repeats after 10 frames. That 10/25 of a second, where as the original poster was talking about 2 to 3 seconds. Is there any way to change the pattern of I, B and P frames? It uses pretty much the standard MPEG2 spec for Standard Definition video, 15 frames per Group of Pictures, consisting of 7489690: 0x00: Picture (I-Frame) Start (2) 7544860: 0x00: Picture (B-Frame) Start (0) 7563292: 0x00: Picture (B-Frame) Start (1) 7581732: 0x00: Picture (P-Frame) Start (5) 7612444: 0x00: Picture (B-Frame) Start (3) 7630876: 0x00: Picture (B-Frame) Start (4) 7649316: 0x00: Picture (P-Frame) Start (8) 7677980: 0x00: Picture (B-Frame) Start (6) 7696412: 0x00: Picture (B-Frame) Start (7) 7714852: 0x00: Picture (P-Frame) Start (11) 7743516: 0x00: Picture (B-Frame) Start (9) 7761948: 0x00: Picture (B-Frame) Start (10) 7780388: 0x00: Picture (P-Frame) Start (14) 7811100: 0x00: Picture (B-Frame) Start (12) 7829532: 0x00: Picture (B-Frame) Start (13) This is really not something the encoding chip was designed to handle much else besides a 6/12/15/30 frame GOP (and 30 frames will corrupt at scene changes sometimes). I think 6 frame GOP testing should prove or disprove your theory, since should be half as long of a delay using that setting. Just run this `ivtvctl -c framespergop=6` command to setup 6 framespergop (when not encoding yet of course :-). Thanks, Chris Andrew --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] ivtv PVR-350 MPEG encoding/decoding delay
Rolf Kistler wrote: Hi all, We have used ivtv and two PVR-350 to successfully to stream mpeg-2 Video/Audio data over the network using on one side the analog composite input (camera) and on the other side the analog composite output (TV screen). As long as one wants to transport surveillance data or a movie, this solution just works fine. Now the problem is that if the task is to control a camera or talk to someone on the other end, the 2-3 seconds delay in our system is too much. This is from it being compressed video, encoding always will introduce a delay, in every encoding system out there. So that is with MPEG2, if you use all YUV raw video (which should work), then there will be pretty much no delay, although it takes 1 gig a minute of data traffic for YUV or so. So I suspect if compressing the video to transport it you pretty much will always have a delay? Is there anything out there you've seen that can do this, I'd be interested if so :), but I think it's not possible with any compression. Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Crash report and kernel oops
Hans Verkuil wrote: On Friday 09 September 2005 03:47, Philip Rowlands wrote: Attached are serial console logs captured by Grant Kwok (thanks Grant!) showing the kernel log during system lockup - he's having some trouble mailing the list. Anyone familiar with interrupt handler oopses? I'm among the least qualified to comment on interrupt handlers, but... is it correct that ivtv uses SA_INTERRUPT (disable all interrupts during handler), yet doesn't use a minimal top-half? In ivtv_irq_handler I see spinlocks, printks, and other fun stuff which might cause complications. The 'printk' statements in the irq handler only happen when you have debugging levels well above normal, so hence don't print during any non-debugging usage. Also the irqhandler really doesn't do much, besides wake up threads, no heavy work, so really doesn't needs a top/bottom half. The spinlock is just to keep SMP sane, in fact it's a spinlock that should only really activate on SMP. If not that, then perhaps the kfree() at ivtv-fileops.c:1494 (in ivtv_v4l2_close)? Isn't the problem simply that the YUV decoder buffers cannot be allocated? Memory allocation failures are not handled very well in the driver and if you continue regardless I'm not surprised all sorts of strange errors crop up. No, memory allocation is not horribly handled in the driver, it's not great in obscure points where you would most likely crash anyways because there's something that wouldn't work anyways beyond normal usage (but even cases like filled disk drives it seems to do fine). I have the buffers all recycle so there should never be a problem with buffer allocating that way in terms of us bailing, we just grab from our full buffers. There were alot of problems in the past and I think we are beyond those, most cases the driver won't bring your system down when something goes wrong or the driver is abused, so not seeing horrible memory handling anywhere? The dynamic allocation has one slight problem, although I agree it's better at this default, but whenever that's the default then alot of people seem to either get caught with all the memory allocated up front for streams they don't use, or can't reload the driver over and over again. So that's a problem that may crop up, seems to change the tables on peoples ivtv behavior, so some may need to try to enable it again (although probably best for those needing it to enable it, will just need to change now, since most should do alright with the new dynamic buffer setting). Thanks, Chris Hans --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Crash report and kernel oops
Tyler Trafford wrote: On Fri, Sep 09, 2005 at 01:25:51PM -0400, Paul Koster wrote: These logs are quite similar to my situation since I upgraded Sep 2 18:23:46 pvr kernel: ivtv: START INIT IVTV Sep 2 18:23:46 pvr kernel: ivtv: version 0.3.8 ((svn snapshot revision 1280)) loading Sep 2 18:23:46 pvr kernel: ivtv: Linux version: 2.6.8 preempt PENTIUMIII gcc-3.3 I don't remember if ivtv is PREEMPT-safe. Chris? Well I've heard it isn't, not first hand but seems like there's problems there for some with preemtable kernels. I think there's alot of places that we have tricky situations for SMP and preemptable kernels which is why I don't doubt there would be problems, although I really think it's just preemptable kernels and not SMP, probably we need to disable preemption in alot of parts of the driver from need of linear things for keeping this hardware happy. I think in this case of running out of memory and preemption, possibly a place we need to disable preemption or do something different, although mostly it's just a memory situation although not locking up there in *most* cases I've seen (but not on preemption, so why I think you may be exactly right in what I think your thinking about preemption causing the lockup :-). Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Crash report and kernel oops
Paul Koster wrote: Chris Kennedy wrote: The above does not really explain why this happens with recent drivers (though not that often) and never with old versions (notably 0.3.2f), using the same hardware, memory, kernel, etc. Furthermore, I cannot recall anytime that I ran out of memory in normal cases (uptimes of weeks/months). Yes, actually I think the buffer sizes have changed since then and possibly were 16k buffers before and now 32k. I suspect that since that changed, and possibly other buffer sizes, the memory allocation is more stressed and possibly bringing out preemption bugs where we need to do something in preemption mode (seem ok in SMP and normally I think). So kind of explains it, although looking at module load messages for each and checking what is being allocated would show if that's the case. Is there any relevant information we could provide to help the developers determine possible bugs in the driver if it happens again? (In the meantime I'll update to latest svn where dynbuf is turned off by default, maybe it matters?) Would be interesting to try that, mainly try and fiddle around between versions and seeing if anything helps and reporting details about the tests done and success (detailing what caused it) or failure (detailing where things break), that's the best information (and module loadup messages from each version too, often that provides all the logistics of the versions buffer and DMA setup. Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] wiki vs wiki: what to do?
Claude Meyer wrote: Quoting Hans Verkuil [EMAIL PROTECTED]: On Friday 02 September 2005 22:49, Isaac Richards wrote: On Friday 02 September 2005 04:31 pm, Claude Meyer wrote: What is happening with ivtv.tv? It looks to me like that's still the active download site. Perhaps it makes sense to redirect dl.ivtvdriver.org to Chris' ivtv.tv site? I think it makes a _lot_ more sense to have everything hosted in one place, instead of scattered on various servers around the world. Makes it easier to find things. All old archives are also available on dl.ivtvdriver.org (I've been reorganizing them, almost done), and that is also where the new releases will be placed. So ivtv.tv is sort of orphaned. Sorry Chris :-) I asked because I saw 0.3.8 was placed on ivtv.tv for download. In that case, Chris, are you ok with redirecting ivtv.tv to wiki.ivtvdriver.org? I've got notices up at the /releases/ directory to go to http://dl.ivtvdriver.org/ck/ from now on. I have the structure duplicated at /ck/ there so if it was sent to /ck/ that would be one possibility. Hopefully all the links are updated and still should leave it there since my PayPal info is there and my donation and can track stats of that there, just use it for that. Thanks, Chris Hans, there are still some things that I think you haven't migrated: http://www.ivtv.tv/cx2341X/registers.txt http://ivtv.sourceforge.net/docs.html -Claude - This mail sent through IMP: http://horde.org/imp/ --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] wiki vs wiki: what to do?
Claude Meyer wrote: Quoting Chris Kennedy [EMAIL PROTECTED]: I've got notices up at the /releases/ directory to go to http://dl.ivtvdriver.org/ck/ from now on. I have the structure duplicated at /ck/ there so if it was sent to /ck/ that would be one possibility. Hopefully all the links are updated and still should leave it there since my PayPal info is there and my donation and can track stats of that there, just use it for that. Your donation link has been on the Wiki for a long time now. Also, if any of the other active developers want theirs added, let me know. Right, but it links to http://www.ivtv.tv/paypal.html so if www.ivtv.tv was redirected it would loop to itself, just would have to make sure that is moved when that's done and works right still, all I was concerned with. Besides that everything looks fine with redirecting it. Thanks, Chris If you're interested in stats, you should also have a look at: http://sourceforge.net/project/showfiles.php?group_id=73219 You can see that 0.1.9 has been download 32,020 times ;) 0.2.0rc3i,j have a few thousand and I've only just uploaded k. The general project statistics are interesting, as well: https://sourceforge.net/project/stats/?group_id=73219ugn=ivtvtype=mode=alltime -Claude - This mail sent through IMP: http://horde.org/imp/ --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] organisation
Hans Verkuil wrote: On Thursday 01 September 2005 09:20, Simon Kenyon wrote: kevin wrote the driver, way back when (i first started using in in 03) chris just sort of just took over from kevin, but in now looks like hans has done so. am i correct? just me being curious Sort of, yeah. At least for a while. I really want to get this better organized and on the way to inclusion in the kernel. Once that's on the road I probably won't spend as much time on it as I do now, knowing myself :-) Well I haven't went anywhere exactly :-), Hans is just doing so much great work right now on the driver and getting things setup a bit better. I've never said I was more than doing raw work on the driver anyways and have really been satisfied lately with the core of the driver with DMA and general research of the chip to get all the possibilities and ways to configure it discovered. So with my current work load and feelings of having really taken the driver beyond the original schemes of DMA and driver models to redesign the way it works for my needs with past jobs and wanting a production quality driver, I'm happy and fortunately Hans is taking up maintaining for the time being. Now the real question is long term maintaining, I of course always will have a big interest in this driver and be doing many things in the future. I doubt that many are going to want to long term maintain it totally close up and once in the kernel it will save us alot of work, but then again will need someone to go to possibly still for some things unique to the encoder chip. One cool thing would be possibly adding real V4L2 buffer support unless someone beats me to it (although have mostly engineered the current buffering and DMA system so probably partly responsible to get that since most familiar with the drivers inner workings), I did this working for Conexant in their Linux driver for the newer cx23418 chips so can say I know the general things needing to be done, but of course have to do it from scratch again and not enough time right now to do so with needing real work to survive and make money just like Kevin went off to do originally :-). Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Xdriver and Xmame
Brendan Hoar wrote: On Thu, 1 Sep 2005, Lucas Meijer wrote: this is a known issue with the driver. do a quick cat /dev/video0 /dev/video16 and abort it before trying to use Xv. hopefully this won't be necissery later on. That begs the question: what's the smallest valid mpeg-2 datastream that can be embedded in the driver? I would suspect the chip very likely has valid mpeg already somewhere in the memory space and we'd just have to alocate a buffer and copy from the chip to buffer and send that for the DMA xfers and initialize the decoder. Maybe the encoder could be ran and we could collect mpeg and loop it to the decoder ourselves for a second before doing YUV display (or upon driver load, maybe a module load option). Passthrough mode seemed not to trigger it so seems we would have to do passthrough manually to force it, must not init the decoder in passthrough mode, funny how YUV runs decoding in passthrough mode inside the chips firmware but won't init the decoder like MPEG2 will, an interesting observation. Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] static vs. dynamic buffer alloc (was Random system freezing help requested)
Graeme Wilford wrote:
On 31/08/05, Tyler Trafford [EMAIL PROTECTED] wrote:
Lucas Meijer wrote:
Graeme Wilford wrote:
Use the ivtv_dynbuf=0 driver option as mentioned below.
Should we perhaps change the *default* to static buffer allocation?
This problem appears to crop up time and again...
Sounds like a good idea to me. I've not used the .3 series for months
and months because of freezups I didn't know how to get rid of, untill
recently a kind soul here suggested the ivtv_dynbuf=0 setting.
IIRC, the dynamic buffer alocation is preferable if you are loading the
newer firmware.
I thought it was frame rather than block DMA transfers that were
preferrable with newer firmware (from ivtv-driver.c):
/* If daring to use newer firmware, then change to frame based mode */
if (retval 0x02040011) {
itv-dma_cfg.enc_buf_size = 0x8000; /* 32k */
itv-dma_cfg.fw_enc_dma_xfer = 1; /* frame based */
itv-dma_cfg.fw_enc_dma_type = 1;
} else if (itv-options.dynbuf) {
itv-dma_cfg.enc_buf_size = 0x8000;
}
Wouldn't have thought dynamic buffer allocation made any difference to
driver performance...
Chris?
The newer firmware only uses frame based DMA, it can't do byte based DMA
in same sized chunks per transfer. There's alot of different variables
there and they fit different situations, some find older firmware more
stable and some find newer firmware better performing and stable enough,
others find newer firmware unstable. So still something people could
test, the safe road is older firmware, that ensures things will be
mostly stable as they can for either decision.
Thanks,
Chris
Cheers,
WIlf.
--
===
Chris Kennedy
[EMAIL PROTECTED]
---
SF.Net email is Sponsored by the Better Software Conference EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
Agile Plan-Driven Development * Managing Projects Teams * Testing QA
Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf
___
ivtv-devel mailing list
ivtv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] ivtv tarball archives moved to http://dl.ivtvdriver.org/ck/releases/
The releases directory where the snapshot type tarballs and archives of those have been kept has moved from http://www.ivtv.tv/releases to http://dl.ivtvdriver.org/ck/releases/, please update links accordingly. So http://dl.ivtvdriver.org/ck/releases/ivtv-0.3/ would be where the current snapshot is, and of course the way that is done or if it's done there will change soon with subversion being used, but for right now this is a change to be aware of that the new url is where the entire archives are. Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Question about interrupts (semi long)
Hans Verkuil wrote: On Sunday 28 August 2005 17:49, Harry Orenstein wrote: 3) Captured the following from my kernel log (the only entries after loading ivtv once I did ivtvctl -D 64): Aug 28 11:32:38 gallifrey kernel: ivtv irq: === valid IRQ bits: 0x0400 == Aug 28 11:33:09 gallifrey last message repeated 2013 times Aug 28 11:34:10 gallifrey last message repeated 3985 times Ah! This is the cause: ivtv: Autodetected WinTV PVR 250 card (iTVC15 based) iTVC15 is used for the PVR350 but apparently you also have one. The interrupt that is active is the IVTV_IRQ_DEC_VSYNC interrupt, which should only arrive on a PVR350 (with a decoder chip). Also odd is this: tveeprom: Hauppauge: model = 48012, rev = G310, serial# = 2600478 tveeprom: tuner = Philips FI1236 MK2 (idx = 10, type = 2) tveeprom: tuner fmt = NTSC(M) (eeprom = 0x08, v4l2 = 0x1000) tveeprom: audio processor = MSP3445 (type = c) tveeprom: decoder processor = Type 0x00 (type = 0) The decoder processor (unrelated to the mpeg decoder on a PVR350) is 0. What chip is on your board? AFAIK it should be an SAA7115. Can you edit ivtv-driver.c: search for IVTV_IRQ_DEC_VSYNC and remove it from the mask. Now try again and let me know if the problem is fixed. Chances are that you still get interrupts in, but the errors should hopefully be gone. Hans --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel There are 250 cards known to have itvc15 chips, the early ones, I have one of these, they should be checked for in the driver, but sounds like somethings odd there. Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Question about interrupts (semi long)
Harry Orenstein wrote: On Sunday 28 August 2005 12:56 pm, Hans Verkuil wrote: On Sunday 28 August 2005 17:49, Harry Orenstein wrote: 3) Captured the following from my kernel log (the only entries after loading ivtv once I did ivtvctl -D 64): Aug 28 11:32:38 gallifrey kernel: ivtv irq: === valid IRQ bits: 0x0400 == Aug 28 11:33:09 gallifrey last message repeated 2013 times Aug 28 11:34:10 gallifrey last message repeated 3985 times Ah! This is the cause: ivtv: Autodetected WinTV PVR 250 card (iTVC15 based) iTVC15 is used for the PVR350 but apparently you also have one. The interrupt that is active is the IVTV_IRQ_DEC_VSYNC interrupt, which should only arrive on a PVR350 (with a decoder chip). Also odd is this: tveeprom: Hauppauge: model = 48012, rev = G310, serial# = 2600478 tveeprom: tuner = Philips FI1236 MK2 (idx = 10, type = 2) tveeprom: tuner fmt = NTSC(M) (eeprom = 0x08, v4l2 = 0x1000) tveeprom: audio processor = MSP3445 (type = c) tveeprom: decoder processor = Type 0x00 (type = 0) The decoder processor (unrelated to the mpeg decoder on a PVR350) is 0. What chip is on your board? AFAIK it should be an SAA7115. Can you edit ivtv-driver.c: search for IVTV_IRQ_DEC_VSYNC and remove it from the mask. Now try again and let me know if the problem is fixed. Chances are that you still get interrupts in, but the errors should hopefully be gone. Hans BRILLIANT!! That worked!! Eliminates the ERR interrupts altogether as well as the ivtv interrupts prior to starting a capture. When I start a capture, only the ivtv interrupts increase, which is as it should be. The change I made in ivtv-driver.c was to revert the check from if (ivtv-has_itvc15) to if ((itv-card-type == IVTV_CARD_PVR_350)). Can I submit a patch for 0.3 and 0.2 branches to correct this, or is this a solution too specific to my problem (i.e.: would it cause problems for other card types)? This is a great solution :), I can see how that was most likely the better variable to follow even though technically we were adjusting to the chip type it is really practically only a 350 anyway that will ever actually decode too (although when using an itvc15 for encoding, it uses the decoder firmware for some stuff like audio, even on a 250 without decoding functionality, so that's why the firmware has to still load for both dec/enc on those). Thanks, Chris As far as the chip is concerned - I have an SAA7115. The driver doesn't seem to have any problem loading the driver for it when I just do a modprobe ivtv. Thanks again for all your help. If there is any other info you need please let me know. This was really bugging me for a long time and I'm glad I finally decided to pursue it. -- Harry O. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] TV-out ghosting w/low-res Recordings
Mark Cooke wrote: On Sat, 2005-08-27 at 03:03 -0500, Adam Forsyth wrote: Try setting options ivtv dnr_temporal=0 in your modprobe.conf. That fixed it for me. Yes. The temporal noise reduction only appears to work correctly when recording at width = 720. Does anyone have temporal noise reduction working with recording widths other than 720 ? Should the driver switch off this option automatically for non-720-wide resolutions ? Mark Yes, I think that may be the answer to what is going on, why the Windows driver sets that, and possibly turns it off with non 720 width resolutions (or should). Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] ivtv-0.3.7h.tgz: needs testing
Hans Verkuil wrote: I've made a new release (available from www.xs4all.nl/~hverkuil until added to the regular archive). This one might be less stable than 0.3.7g since I've added sliced VBI for the PVR150/500/PG600 cards, and it hasn't been tested very well. Especially NTSC is basically untested. This seems to look good on raw VBI output from what I can tell so far. The sliced VBI on the pvr150 for CC NTSC doesn't seem to work though, and the pvr350/250 seem to show a bunch of junk characters randomly (strings of dtdtdtdtdtdtd over and over, or spaces oddly set, was always clean in the past). The pass through VBI to the TV and maybe either that or the VBI CC embedding it not working, nothing is output and seems not to activate it in the logs. I get nothing on the vbi scanner utilities output for line 21, or anyother line. So that's my report, seems to have killed most NTSC VBI besides raw here, should have time to do any tests, wondering if it's just me, are others in NTSC CC areas seeing similar results Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Re: Subversion repository: options?
Hans Verkuil wrote: On Monday 22 August 2005 23:55, Axel Thimm wrote: On Mon, Aug 22, 2005 at 10:13:08PM +0200, Hans Verkuil wrote: I've seen a few offers to setup a subversion repository for ivtv. It is my opinion that we should move quickly in that direction. I've seen offers from Isaac Richards and Axel Thimm. How quickly can it be setup and be ready for use? Basically we need a place to put up datasheets (they are now all over the place), have a svn and a bugtracking thing is also handy. And you need to be able to download periodic releases and perhaps snapshots. I will certainly not be involved in setting it up or maintaining it. I have neither time nor interest in that part of the operation. One reason for doing this fast is that I want to keep the momentum. I especially want to move on from 0.3 to 0.4 and do some major cleanups, and svn is ideal for tracking that. I can set this all up till the end of the week. I just need some decisions like trac vs mediawiki/bugzilla. I wouldn't like to come forward with something the developers wouldn't like. If noone comes with aclear direction, I'll opt for trac. This doesn't preclude the use of mediawiki for non-developer related content. I've taken a quick look at trac and it seems OK. No-nonsense and simple. A quick question on the CVS-SVN conversion: do you need the actual CVS repository to do this? Or do you only need access to the CVS server? In the first case: who has access to the sourceforge ivtv CVS repository? Hans --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel I would go along with trac, since sounds like what is prefered and I have no experience with either trac or the mediawiki interfaces. Will work with any resource setup that I have access to (just not knowledgeable on how to get this all going from the get-go), sounds great. Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] ivtv-0.3.7g
Hans Verkuil wrote: Until Chris uploads it to the usual site it is available from: www.xs4all.nl/~hverkuil Please test, esp. NTSC VBI! Also look at the new vbi-detect test tool. It programs the sliced VBI registers for the various supported VBI types and then checks what is actually transmitted on each line. If you see the result MULT, then multiple standards are detected. Of course, only one is correct. Until now the slicer often wrongly detects teletext. I'll have to see if that can be fixed. This version is the basis for adding sliced VBI to the PVR150. Changelog: #0.3.7g - added ivtv-radio patch from Adam Forsyth: -It speeds up the station searching by skipping the range below where stations are if you don't want to see all strong frequencies. -It closes the file handle for the radio device - added small patch from Kevin Ruland to export the module device table. - cleanup QuickSetup - prepare for sliced VBI for cx25840. - make VBI specification more detailed to allow sliced VBI autodetection. - split itv struct initialization to allow for changing the card type pending on the tveeprom data. - fixed a NULL deferenced in ivtv_reset_digitizer. - add new (internal) ioctls: IVTV_IOC_G_VBI_FMT, IVTV_IOC_S_VBI_FMT, IVTV_IOC_TRY_VBI_FMT and IVTV_IOC_G_VBI_CAP. This will be used as the proof-of-concept for a V4L2 sliced VBI standard. This API is for now internal and may change. - allow changing the sliced VBI settings while capturing. This used to return EBUSY. - fixed inadvertently removed tuners from tveeprom.c - added vbi-detect test utility. This scans the VBI lines and tries to detect which VBI types are transmitted. - fix compile error for ivtv-detect.c. - removed hack in radio.c. Doesn't seem to be needed anymore, at least, I can no longer reproduce the problem. --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel Hans, This looks great so far on NTSC CC through my pvr350, captions are timed perfect and *so far* no mistakes. Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.7e f Hans versions on ivtv site
I've uploaded the versions e f Hans released so they are now also on the ivtv site... e/f: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.7d Hans patches added
This addes all Hans recent patches to the driver. #0.3.7d: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] #0.3.7d Hans patches added
Hans Verkuil wrote: On Sunday 14 August 2005 22:31, Chris Kennedy wrote: This addes all Hans recent patches to the driver. #0.3.7d: http://www.ivtv.tv/releases/ivtv-0.3/ You also accidentally reverted some of the later ivtv-0.3.7c patches for a clean compile and some cx25840 audio patches. Hans --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel Ah, that last one hadn't gotten here yet for some reason when I applied all of them. Oh I just applied them in the order they arrived in my email, can add that last to them or send me a patch possibly with all applied together. Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] 0.3.7c Build Errors...
This is all fixed, added the cleanup patch and fixed the compile error, and re-uploaded 0.3.7c. Thanks, Chris Darren Black wrote: Hi there, Just tried building 0.3.7c and ran into some trouble... Here's the compiler output: [EMAIL PROTECTED] driver]# make make CONFIG_VIDEO_IVTV=m -C /lib/modules/2.6.10-1.770_FC3/build M=/home/mythtv/Desktop/ivtv-0.3.7c/driver modules make[1]: Entering directory `/lib/modules/2.6.10-1.770_FC3/build' CC [M] /home/mythtv/Desktop/ivtv-0.3.7c/driver/ivtv-osd.o In file included from /home/mythtv/Desktop/ivtv-0.3.7c/driver/ivtv-driver.h:92, from /home/mythtv/Desktop/ivtv-0.3.7c/driver/ivtv-osd.c:176: /home/mythtv/Desktop/ivtv-0.3.7c/driver/tuner.h:112: error: `V4L2_TUNER_DIGITAL_TV' undeclared here (not in a function) /home/mythtv/Desktop/ivtv-0.3.7c/driver/tuner.h:112: error: enumerator value for `T_DIGITAL_TV' not integer constant make[2]: *** [/home/mythtv/Desktop/ivtv-0.3.7c/driver/ivtv-osd.o] Error 1 make[1]: *** [_module_/home/mythtv/Desktop/ivtv-0.3.7c/driver] Error 2 make[1]: Leaving directory `/lib/modules/2.6.10-1.770_FC3/build' make: *** [all] Error 2 /drdaz --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.7c Hans VBI fixes, other patches
This updates the driver with all the latest patches for the most part (please remake and conglomerate all patches against this version as one patch per person, separate attachments, for any I missed). It includes Hans VBI fixes and other fixes, also Brians volume control patch I think, although part of another patch didn't apply which had to do with volume stuff. #0.3.7c: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] [PATCH]: Fix for alevt nxtvepg
Hans, This was commented out becasue upon further inspection of the raw VBI data I found that the stop/start codes it is trying to overwrite are not always there, basically the raw VBI alignment in the chips buffers are *not* perfectly aligned to the stop/start codes. It's as if we really have to parse the start/stop of each packet and fixup the raw VBI data ourselves. If you check the Windows drivers output of raw VBI it is trimmed and clean for each packet, sets the Firmware API size to 1456 while gets 17280 bytes per packet (for NTSC mode) of 12 lines each line being 1440 in length. So in the Windows driver they go into the raw packet and take each line and chop it up to 1440 and put the whole packet back together without stop/start codes and what seems to be 4 extra bytes of data. I dont' know enough about raw VBI formats and how it should be to know the proper trimming, but do know the current method is like russian roulette and we just are throwing in a 4 byte chunk of data randomly into the VBI stream (had code checking if we were really overwriting the stop/start codes and showed this fact too, although also just reading the buffers you see it get's offset sometimes in-stream and then every data read is off and not exactly upon packet boundrys, and seems to vary by 16 bytes when it does this). Thanks,. Chris Hans Verkuil wrote: (Sourceforge seems to have eaten this mail, so I'm mailing it again) This patch fixes alevt nxtvepg support: alevt expects a sequence number at the end of the raw VBI data. This was commented out by someone and has been reinstated at the proper place. Also, the alevt patch now also fixes an alignment problem for 64-bit systems. Regards, Hans --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] [PATCH]: Fix for alevt nxtvepg
Hans, Ah, that's a good thing then, although you hadn't included the patch :). One question then is if it loses characters ever in teletext mode like in CC mode, I thought the missing characters were from this timestamp insert, maybe part of it at least, although I see what your saying and it brings up the question of what is going on (is it just CC and line 21 corruption, bad signals, low signals, affecting all services for any lines). So sounds like the patch should be no problem then, I think I had made it able to split up the buffers and still insert those right still, so I think that problem should be solved, but interested in seeing the patch to make sure and apply it :). Also if you have any links to sources of slicing raw VBI, stuff I could look into this with to know more about the sliced and raw, getting it from raw to sliced, and able to get a better grip on how the raw data could be missing chunks and understanding of exactly what we are doing to convert lines to the 2 bytes or however big of payload for the data service. I would be interested in any information you may have or where to look for that, would be very helpful in understanding it more. Thanks, Chris Hans Verkuil wrote: Chris, This really isn't a problem. The raw VBI parsers don't care if the VBI lines are offset by a random amount of bytes (within limits, of course. If it's off by more than 100 bytes you might get into trouble). The start-stop codes are ignored anyway. At least alevt and nxtvepg rely on the frame counter being part of the raw VBI data and will fail to work if it is absent. So it really must be present. Hans On Tuesday 09 August 2005 21:06, Chris Kennedy wrote: Hans, This was commented out becasue upon further inspection of the raw VBI data I found that the stop/start codes it is trying to overwrite are not always there, basically the raw VBI alignment in the chips buffers are *not* perfectly aligned to the stop/start codes. It's as if we really have to parse the start/stop of each packet and fixup the raw VBI data ourselves. If you check the Windows drivers output of raw VBI it is trimmed and clean for each packet, sets the Firmware API size to 1456 while gets 17280 bytes per packet (for NTSC mode) of 12 lines each line being 1440 in length. So in the Windows driver they go into the raw packet and take each line and chop it up to 1440 and put the whole packet back together without stop/start codes and what seems to be 4 extra bytes of data. I dont' know enough about raw VBI formats and how it should be to know the proper trimming, but do know the current method is like russian roulette and we just are throwing in a 4 byte chunk of data randomly into the VBI stream (had code checking if we were really overwriting the stop/start codes and showed this fact too, although also just reading the buffers you see it get's offset sometimes in-stream and then every data read is off and not exactly upon packet boundrys, and seems to vary by 16 bytes when it does this). Thanks,. Chris Hans Verkuil wrote: (Sourceforge seems to have eaten this mail, so I'm mailing it again) This patch fixes alevt nxtvepg support: alevt expects a sequence number at the end of the raw VBI data. This was commented out by someone and has been reinstated at the proper place. Also, the alevt patch now also fixes an alignment problem for 64-bit systems. Regards, Hans --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https
Re: [ivtv-devel] [PATCH]: Fix VBI passthrough improve WSS behavior
This is something wrong with the firmware I believe, when we go into ff/rw mode seems to re-init the VBI decoder, so we probably need to re-setup that when coming out of ff/rw. I hopefully can get around to that here sooner or later and put some code in to fix that, have been thinking about that as being a problem but haven't had time to focus on it. Thanks, Chris Daniel Segel wrote: Hi - I'm not Graeme, but I'm having a similar problem with CC data - it works fine if I start watching a recorded show from the beginning, but the moment I skip around it stops. This is with: MythTV 0.18.1-r2 (Gentoo) NTSC I set the following ivtv options at boot (fairly late in the boot process): /usr/local/bin/ivtvctl -x 1 -w cc -b cc Thanks, Daniel Hans Verkuil wrote: (Sourceforge seems to have eaten this mail, so I'm mailing it again) Hi Graeme, I have three essential questions for you: - What version of MythTV are you using? - Are you in PAL or NTSC country? - Do you set some vbi-related options using ivtvctl before running MythTV? I looked at MythTV 0.18.1 and I see NO setting for vbi_passthrough, so I fail to see how MythTV can ever passthrough CC or WSS data. Can you also make a test run for me that demonstrates the problem, preferably after a fresh boot of your PC, and mail me the kernel messages (dmesg output). Hans On Monday 08 August 2005 19:16, Graeme Wilford wrote: Hans, Apologies, I think the preempt-enabled kernel I built was screwing with the driver. The results I'm now seeing using a stock FC3 kernel are identical with and without the patch, ie. at the beginning of a wide-signal capture, my TV will flip to wide mode. This also works while switching between wide and narrow channels in Myth. If it's a wide signal - I get 16:9, if not, I get 4:3. However, skipping around a wide recording immediately loses the wide mode and I'm unable to get it back again within that particular recording. It's like the wss signal is only embedded at the start of a recording or when a wide-mode change occurs in the signal. During a skip-forward, Myth (or my TV) reverts back to 4:3 and permanently 'forgets' that the stream was wide rather than defaulting to the previous VBI mode. If this is indeed the way VBI wss works, perhaps MythTV should be caching the most recent wss mode and using that as the default until it's overriden by another mode-switch..? --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Currently outstanding patches
Bryan Mayland wrote: Hi Chris, just wanted to help out by aggregating a list of patches that I know are still in limbo currently: -- cx25840-volume4.diff - Change the volume range on the PVR150 again to match the PVR250/350. http://www.gossamer-threads.com/lists/ivtv/devel/22276 I found the one below, but can't seem to find this patch in the archive, could you send that to me again. The others are in the queue, must have missed the tda fix. Thanks, Chris -- tda9887.patch - Peter Gunderson's patch to remove my code to force both ports active on the tda9887. My change broke more people than it fixed. http://www.gossamer-threads.com/lists/ivtv/devel/22272 -- wm8775-only-ivtv.diff - Changes the wolfson module to only probe ivtv adapters, since there is a chip on some Via chipset motherboards at that same address on the Via SMBus. http://www.gossamer-threads.com/lists/ivtv/devel/22505 Oh I guess that's it. I thought there were more but I was wrong. :) Did I miss anyone? Bry --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] state of raw/YUV support
Yes, YUV capture is exactly the same for the 150 as the 350, and only broke for a very short period of time when rewriting all the DMA code, and all the methods we use to run interrupts and work queue threads. It is also interesting the Windows drivers take out YUV capture support for pvr150/500 cards yet support it for pvr250/350 cards (I *think* it does for the 250). This is absurd since absolutely NOTHING is different in the firmware or hardware or interface to get YUV capture from the card, so that's something I'm really curious about, why did they pull YUV support for the newer cards in Windows Of course that's all capture, now sending YUV to the card and bypassing the mpeg2 decoding unit (essentially doing the decoders function and plugging into the hardware inbetween the two units, mpeg2-YUV decoder and YUV display), is that even done in Windows???, I don't think it is, and not done in Linux either, there's no success that I know of anywhere else for sending YUV to these cards display directly (although one of those 'features' supposidly possible, although it's one of those phantom features we see so often for products now days, something iCompression-Conexant kinda wanted to eventually do and as we are seeing is *possible* but not engineered into firmware or done before). Thanks, Chris John Harvey wrote: It does work for a PVR 350 but the question (if i remember correctly) was about a 150 and i have no idea whether that works or not. mplayer has a decoder that understands the format coming out of the 350 and can play it directly (with the correct command line options). John --- Cory Papenfuss [EMAIL PROTECTED] wrote: What were the answers? I didn't see any responses to your e-mail. I asked this question a while back, and I got no response. With mplayer it does not work (yet). On the other (dark) side of the world, the windows drives do not support to read raw data, so it would be amazing if these hacker guys manage it. Chris Awhile back (ivtv-0.1.9 IIRC) it could be made to work. The biggest problem is that the data format isn't quite normal. It's structured slightly strangely and it took a patched player to play it. Nothing inherently bad, just a slight massaging of the data required. I remember hearing of it breaking as the driver evolved, and I have no idea what the current status is. Doesn't appear to be any reason why it *couldn't* work. -- * * Cory Papenfuss * * Electrical Engineering candidate Ph.D. graduate student * * Virginia Polytechnic Institute and State University * * --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] state of raw/YUV support
Also if capture of YUV is desired, and you want normal YUV, then add the yuv_fixup=1 ivtv module option, this converts YUV, and is only a module option and off by default since it's something not supposed to be done at the driver level (so an application could be modeled after this code to make an easy i/o prog to pipe to/from and convert the YUV of the driver output and then yank the code and include the program with the driver, probably one of the many things needed before getting included in the Linux kernel). Thanks, Chris John Harvey wrote: It does work for a PVR 350 but the question (if i remember correctly) was about a 150 and i have no idea whether that works or not. mplayer has a decoder that understands the format coming out of the 350 and can play it directly (with the correct command line options). John --- Cory Papenfuss [EMAIL PROTECTED] wrote: What were the answers? I didn't see any responses to your e-mail. I asked this question a while back, and I got no response. With mplayer it does not work (yet). On the other (dark) side of the world, the windows drives do not support to read raw data, so it would be amazing if these hacker guys manage it. Chris Awhile back (ivtv-0.1.9 IIRC) it could be made to work. The biggest problem is that the data format isn't quite normal. It's structured slightly strangely and it took a patched player to play it. Nothing inherently bad, just a slight massaging of the data required. I remember hearing of it breaking as the driver evolved, and I have no idea what the current status is. Doesn't appear to be any reason why it *couldn't* work. -- * * Cory Papenfuss * * Electrical Engineering candidate Ph.D. graduate student * * Virginia Polytechnic Institute and State University * * --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] state of raw/YUV support
Also I would suggest using the options 'ivtv_dynbuf=0 yuv_buffers=16' if really wanting strong stable YUV capture. This tunes the buffers to work hardest at YUV allocation and ability to startup capture quickest and without stress. Thanks, Chris John Harvey wrote: It does work for a PVR 350 but the question (if i remember correctly) was about a 150 and i have no idea whether that works or not. mplayer has a decoder that understands the format coming out of the 350 and can play it directly (with the correct command line options). John --- Cory Papenfuss [EMAIL PROTECTED] wrote: What were the answers? I didn't see any responses to your e-mail. I asked this question a while back, and I got no response. With mplayer it does not work (yet). On the other (dark) side of the world, the windows drives do not support to read raw data, so it would be amazing if these hacker guys manage it. Chris Awhile back (ivtv-0.1.9 IIRC) it could be made to work. The biggest problem is that the data format isn't quite normal. It's structured slightly strangely and it took a patched player to play it. Nothing inherently bad, just a slight massaging of the data required. I remember hearing of it breaking as the driver evolved, and I have no idea what the current status is. Doesn't appear to be any reason why it *couldn't* work. -- * * Cory Papenfuss * * Electrical Engineering candidate Ph.D. graduate student * * Virginia Polytechnic Institute and State University * * --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.6y added recent patches
This adds the recent patches for module auto load fixes and the chroma key ioctl. #0.3.6y: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] pvr-350 amd64 Call trace 0.3.6-w+
Add dynbuff=0 as a module param to ivtv, this should fix the problem, in
0.3 we dynamically allocate memory per capture startup, this seems to be
hard on some heavily loaded systems, also there's a sysctl param in the
doc install files under troubleshooting showing a param to the kernel to
keep memory reserved, either fix or both would help.
Thanks,
Chris
Fredrik Trotzig wrote:
Hi.
With (regular) basis i had some lockups usually with 24-36 hour peridos.
Prolly some recordning,watching,recording,watching and then it happens.
It\'s been for some time now with latest unstable. Here is whats left in the
log after reboot.
The problem is not, with stable drivers.
vtv-0.3.6w-fix-normal-i2c-range-usage_v3.patch is also included.
But of course it happens without also.
Please let me know if more information is needed.
Br Fredrik
---
Jul 6 16:56:53 tux ivtv: Allocate DMA encoder MPEG stream: 128 x 32768 buffers
(4096KB total)
Jul 6 16:56:53 tux ivtv: Setup VBI API header 0xbd0d pkts 1 buffs 4 ln 36
sz 1444
Jul 6 16:56:53 tux ivtv: Setup VBI start 0x0018ea04 frames 4 fpi 1 lines
0x00f1
Jul 6 16:56:54 tux saa7115: decoder disable output
Jul 6 16:56:54 tux saa7115: decoder enable output
Jul 6 16:56:55 tux ivtv: Allocate DMA decoder MPEG stream: 16 x 65536 buffers
(1024KB total)
Jul 6 16:56:55 tux printk: 6 messages suppressed.
Jul 6 16:56:55 tux mythfrontend: page allocation failure. order:4, mode:0xd0
Jul 6 16:56:55 tux
Jul 6 16:56:55 tux Call Trace:8015456e{__alloc_pages+878} 8015714b{cache_alloc_refill+587}
Jul 6 16:56:55 tux 80156d23{__kmalloc+83} 88058c63{:ivtv:ivtv_init_buffer+67}
Jul 6 16:56:55 tux 88058e0b{:ivtv:ivtv_init_queues_nolock+107}
Jul 6 16:56:55 tux 8805a923{:ivtv:ivtv_stream_alloc+419} 8805ce22{:ivtv:ivtv_claim_stream+98}
Jul 6 16:56:55 tux 8805e6bc{:ivtv:ivtv_v4l2_write+172} 801542c2{__alloc_pages+194}
Jul 6 16:56:55 tux 8015459f{__get_free_pages+31} 8017f513{poll_freewait+67}
Jul 6 16:56:55 tux 8016db27{vfs_write+199} 8016dcb3{sys_write+83}
Jul 6 16:56:55 tux 8010e1fa{system_call+126}
Jul 6 16:56:55 tux ivtv: No memory on buffer alloc!
Jul 6 16:56:55 tux ivtv: Buffer alloc failed!
Jul 6 16:56:55 tux ivtv: Couldn\'t allocate buffers for decoder MPEG stream
-
http://www.Poker.se - Sveriges nya pokerportal!
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click
___
ivtv-devel mailing list
ivtv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
--
===
Chris Kennedy
[EMAIL PROTECTED]
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
ivtv-devel mailing list
ivtv-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.6s yuv and audio patches
This includes the YUV Decoding patch and the audio mixer/volume patch for the cx25840. #0.3.6s: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.6r module parameters for buffer sizes
This allows changing the default amount and max amount of memory allocated per stream, basically use modinfo ivtv to find out the new options, but have this syntax... mpg_buffers=4 (4 megs default) max_mpg_buffers=16 (16 megs max memory allocated). So with that the driver would allocated 4 megs immediately (upon stream start, or module load if ivtv_dynbuf=0), and allocated up to 16 megs if needed. Also right now the allocated buffers are 32k by default (using dynamic buffers) or if using newer firmware, else if static buffers and older more stable firmware, then they are 128k (this is the most stable size). Also we now steal buffers for encoding when memory isn't able to be allocated for more buffers, so as not to cause encoding problems past the point of buffers being short in supply, otherwise the encoder can get odd results if we don't empty it out. So now you can tune the buffers alot easier, and maybe better settings can be derived, or those with custom needs can do that, like if needing alot more default encoder memory allocated since a machine may be heavily used and need more buffers reserved. #0.3.6r: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] VBI (again)
To get VBI working do this... run... ivtvctl -w cc,wss; ivtvctl -b cc,wss; ivtvctl -x 1 then turn on CC support in your TV set, so CC is displayed on output, check normal TV to confirm this is on. Then cat /dev/video0 /dev/video16 or any other form of encoding from the card and decoding that video with the card should produce CC. Thanks, Chris Daniel Segel wrote: I have no answers, but I wanted to chime in and let the developers know that I am yet another user who is very interested in Closed Caption support via the PVR-350 as well. I'm willing to wait if it's coming, but if there's no indication that it's at least being worked on then I'll have to either switch video cards (capture cards? Where exactly is the problem?) or give up on MythTV altogether (which is what I bought the PVR-350 for.) Daniel GREG AMY LINDLEY wrote: Hi, I have looked at the README.vbi and installed the latest ivtv drivers. I have the following line in my /etc/rc.local: /usr/bin/ivtvctl -w wss,cc,vps I believe from reading this that the CC data should be going to the TV out on my PVR350 at this point. Unfortunately, I don't seem to see anything. I am not sure what else I may be missing. I have tried using mplayer and xine, but neither seems to help. I tried different DVDs/VOBs so I don't believe that to be the issue. I see that the VBI threads do get initialized in the /var/log/messages file. Not sure what I am missing. I am certainly willing to run tests or help out however I can to get this working. Is there anyone willing to help me out? Thanks, Greg --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.6q added recent patch
This adds the recent patch which unifys the call for the digitizer function, but it does produce compiler warnings which would be good for someone to help fix, not sure yet why it's complaining, but the warning doesn't hurt anything functionally. #0.3.6q: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] dma error in 0.3.6p
, itv = 0xe0f5cda0 ivtv: ivtv_dec_thread: pid = 1338, itv = 0xe0f5cda0 ivtv: ivtv_dec_vbi_thread: pid = 1339, itv = 0xe0f5cda0 saa7115: decoder set norm NTSC saa7115: set audio: 0x01 saa7115: decoder set input (4) saa7115: now setting Composite input ivtv: Setting audio matrix to input 3, output 1 ivtv: Switching standard to NTSC. saa7115: decoder set norm NTSC saa7115: set audio: 0x01 saa7127: Setting Encoder Video Standard saa7127: Set NTSC Video Mode saa7127: Selecting NTSC video Standard ivtv: Initialized WinTV PVR 350, card #0 ivtv: Autodetected WinTV PVR 150 card ivtv: Found an iTVC16 based chip ACPI: PCI interrupt :01:0a.0[A] - GSI 16 (level, high) - IRQ 16 ivtv: Unreasonably low latency timer, setting to 64 (was 32) ivtv: XXX PCI device: 0x01e0 vendor: 0x10de cx25840: starting probe for adapter ivtv i2c driver #1 (0x10005) cx25840: detecting cx25840 client on address 0x88 cx25840: cx25843-23 found. Initializing... cx25840: requesting /lib/modules/HcwMakoA.ROM cx25840: firmware loaded ivtv: i2c attach [client=cx25840[50],ok] tuner: chip found at addr 0xc2 i2c-bus ivtv i2c driver #1 ivtv: i2c attach [client=(tuner unset),ok] tuner: type set to 47 (LG NTSC (TAPE series)) by insmod option tuner: The type=n insmod option will go away soon. tuner: Please use the tuner=n option provided by tuner: tv aard core driver (bttv, saa7134, ...) instead. saa7115: starting probe for adapter ivtv i2c driver #1 (0x10005) tveeprom: Hauppauge: model = 26552, rev = B268, serial# = 7864903 tveeprom: tuner = LG TAPE H001F MK3 (idx = 68, type = 47) tveeprom: tuner fmt = NTSC(M) (eeprom = 0x08, v4l2 = 0x1000) tveeprom: audio_processor = MSP3410D (type = 5) ivtv: i2c attach [client=tveeprom[50],ok] ivtv: Tuner Type 47, Tuner formats 0x1000, Radio: yes, Model 0x00892598, Revision 0x0001 ivtv: Radio detected ivtv: i2c attach [client=wm8775[50],ok] ivtv: Encoder revision: 0x02040011 ivtv: Configuring WinTV PVR 150 card with 5 streams ivtv: Registered v4l2 device for encoder MPEG minor 1 ivtv: Create DMA encoder MPEG stream: 128 x 32768 buffers (4096KB total) ivtv: Registered v4l2 device for encoder YUV minor 33 ivtv: Create DMA encoder YUV stream: 194 x 10800 buffers (2048KB total) ivtv: Registered v4l2 device for encoder VBI minor 225 ivtv: Create DMA encoder VBI stream: 240 x 8736 buffers (2048KB total) ivtv: Registered v4l2 device for encoder PCM audio minor 25 ivtv: Create DMA encoder PCM audio stream: 455 x 4608 buffers (2048KB total) ivtv: Registered v4l2 device for encoder radio minor 65 ivtv: Create encoder radio stream ivtv: Setting Tuner 47 cx25840: decoder set norm NTSC cx25840: decoder set input (6) cx25840: now setting Tuner input cx25840: set audio input (0) ivtv: ivtv_enc_thread: pid = 1400, itv = 0xe0f800fc ivtv: ivtv_enc_vbi_thread: pid = 1401, itv = 0xe0f800fc ivtv: Switching standard to NTSC. cx25840: decoder set norm NTSC ivtv: Initialized WinTV PVR 150, card #1 ivtv: END INIT IVTV ivtv-osd: Framebuffer module loaded (attached to ivtv card id 0) ivtv-osd: Framebuffer is at decoder-relative address 0x0051 and has 1704960 bytes. ivtv-osd: screen coords: [0 0] - [720 480] ivtv-osd: original global alpha = 208 ivtv-osd: current OSD state = 39 ivtv-osd: new global alpha = 208 (1 255 0) ivtv-osd: framebuffer at 0xd551, mapped to 0xe1e1, size 1350k ivtv-osd: mode is 720x480x32, linelength=2880 ivtv-osd: fb1: iTVC15 TV out frame buffer device ivtv: Allocate DMA decoder OSD stream: 32 x 65536 buffers (2048KB total) --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Many PVR350 cards
It's not allocated yet, just shows how much memory is allocated to begin with, so when dynamic buffers are used (the default) that's what it'll say. Thanks, Chris Bryan Mayland wrote: Bryan Mayland wrote: Shouldn't those last 2 lines be more like buffers, buffsize, buffers * buffsize); I take this part back. Buffers is the whole size. However, this is still true s-buf_min shouldn't be defined until right after the print statement, unless this functuion is called multiple times per streamtype, right? --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Many PVR350 cards
Ah, very possibly true, that line is more of a hacked up status line from the old original one, so really could just be redone, I haven't looked at it too closely besides just generally seeing it kinda makes sense in the messages still, but sounds like an oddity there which needs to be changed most likely. Thanks, Chris Bryan Mayland wrote: What I was saying was that on line 96, s-buf_min isn't set, since the initialization of the buffer limits starts right below that, doesn't it? ivtv_stream_init() is only called from ivtv_stream_setup() which is only called from ivtv_streams_setup(), which looks to only happen when the card is first pci probed. I'm not all that familar with the streams setup, but that's how it looks to me. In either case, the value should be 10, since the printf says kbytes but the value for both buf_min and buffers is in bytes, no? Chris Kennedy wrote: It's not allocated yet, just shows how much memory is allocated to begin with, so when dynamic buffers are used (the default) that's what it'll say. --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.6p recent patches, digitizer reset improvements
This addes the recent YUV patches and prints out cleaner information about DMA stream allocation. Also did some work on the digitizer reset when no data is given from the encoder, where now we also go through the init again to make sure things are working right. #0.3.6p: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] #0.3.6p recent patches, digitizer reset improvements
Now that's really odd, try a reboot and see if that fixes it, shouldn't be any changes to really anything affecting this, which is decoding. Maybe some other bug that's been there before, but possibly oddities triggered it, seems strange :-). Thanks, Chris Nick Rosier wrote: Chris, after upgrading from 0.3.6o to 0.3.6p I get these messages; the cards seem to work though: Jun 20 23:55:31 [kernel] ivtv: Allocate DMA decoder MPEG stream: 16 x 65536 buffers (1024KB total) Jun 20 23:55:31 [kernel] ivtv: Allocate DMA decoder VBI stream: 512 x 2048 buffers (1024KB total) Jun 20 23:55:31 [kernel] ivtv: Decoder VBI RE-Insert start 0x0019ac00 size 0xbe00 type 0 Jun 20 23:55:36 [kernel] ivtv: DEC: full_q: 0 elements Jun 20 23:55:36 [kernel] ivtv: DEC: now 0 Dec buffers left, were 65536 left. Jun 20 23:55:36 [kernel] ivtv: DEC: needed 65536 bytes for stream 5, received 0 differ by (65536) bytes Jun 20 23:55:36 [kernel] ivtv: DEC: free_q: 16 elements Jun 20 23:55:36 [kernel] ivtv: DEC: dma_q: 0 elements Jun 20 23:55:36 [kernel] ivtv: DEC: full_q: 0 elements Jun 20 23:55:36 [kernel] ivtv: DEC: now 0 Dec buffers left, were 65536 left. Jun 20 23:55:36 [kernel] ivtv: DEC: needed 65536 bytes for stream 5, received 0 differ by (65536) bytes Jun 20 23:55:36 [kernel] ivtv: DEC: free_q: 16 elements Jun 20 23:55:36 [kernel] ivtv: DEC: dma_q: 0 elements Jun 20 23:55:36 [kernel] ivtv: DEC: full_q: 0 elements Jun 20 23:55:36 [kernel] ivtv: DEC: now 0 Dec buffers left, were 65536 left. Jun 20 23:55:36 [kernel] ivtv: DEC: needed 65536 bytes for stream 5, received 0 differ by (65536) bytes Jun 20 23:55:36 [kernel] ivtv: DEC: free_q: 16 elements Jun 20 23:55:36 [kernel] ivtv: DEC: dma_q: 0 elements Jun 20 23:55:36 [kernel] ivtv: DEC: full_q: 0 elements Jun 20 23:55:36 [kernel] ivtv: DEC: now 0 Dec buffers left, were 65536 left. Jun 20 23:55:36 [kernel] ivtv: DEC: needed 65536 bytes for stream 5, received 0 differ by (65536) bytes Jun 20 23:55:36 [kernel] ivtv: DEC: free_q: 16 elements Jun 20 23:55:36 [kernel] ivtv: DEC: dma_q: 0 elements Jun 20 23:55:36 [kernel] ivtv: DEC: full_q: 0 elements Jun 20 23:55:36 [kernel] ivtv: DEC: now 0 Dec buffers left, were 65536 left. Jun 20 23:55:36 [kernel] ivtv: DEC: needed 65536 bytes for stream 5, received 0 differ by (65536) bytes Jun 20 23:55:36 [kernel] ivtv: DEC: free_q: 16 elements Jun 20 23:55:36 [kernel] ivtv: DEC: dma_q: 0 elements Jun 20 23:55:36 [kernel] ivtv: DEC: full_q: 0 elements Jun 20 23:55:36 [kernel] ivtv: DEC: now 0 Dec buffers left, were 65536 left. Jun 20 23:55:36 [kernel] ivtv: DEC: needed 65536 bytes for stream 5, received 0 differ by (65536) bytes Jun 20 23:55:36 [kernel] ivtv: DEC: free_q: 16 elements Jun 20 23:55:36 [kernel] ivtv: DEC: dma_q: 0 elements Jun 20 23:55:36 [kernel] ivtv: DEC: full_q: 0 elements Jun 20 23:55:36 [kernel] ivtv: DEC: now 0 Dec buffers left, were 65536 left. Jun 20 23:55:36 [kernel] ivtv: DEC: needed 65536 bytes for stream 5, received 0 differ by (65536) bytes Jun 20 23:55:36 [kernel] ivtv: DEC: free_q: 16 elements Jun 20 23:55:36 [kernel] ivtv: DEC: dma_q: 0 elements Jun 20 23:55:36 [kernel] ivtv: DEC: full_q: 0 elements Jun 20 23:55:36 [kernel] ivtv: DEC: now 0 Dec buffers left, were 65536 left. Jun 20 23:55:36 [kernel] ivtv: DEC: needed 65536 bytes for stream 5, received 0 differ by (65536) bytes Jun 20 23:55:36 [kernel] ivtv: DEC: free_q: 16 elements Jun 20 23:55:36 [kernel] ivtv: DEC: dma_q: 0 elements Jun 20 23:55:36 [kernel] ivtv: DEC: full_q: 0 elements On 6/20/05, Chris Kennedy [EMAIL PROTECTED] wrote: This addes the recent YUV patches and prints out cleaner information about DMA stream allocation. Also did some work on the digitizer reset when no data is given from the encoder, where now we also go through the init again to make sure things are working right. #0.3.6p: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED
[ivtv-devel] #0.2.0-rck i2c fixes
This adds the patch from Anduin Withers fixing i2c in newer kernels. #0.2.0-rck: http://www.ivtv.tv/releases/ivtv-0.2/ Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] Sound on cx25840, pvr500, long-term
When running an encoding for a very long time, like 1+ days, I'm seeing the cx25840 suddenly/randomly lose sound, get a fuzzy odd type sound like the input is shifting for some reason. Is this something others have seen, what could this possibly be, autodetection still doing something odd. I think running long-term just gives more of a chance of happening, but it's probably something that can spring up at anytime, seems like something could be done to fix it, still trying to figure out where it could be. I swore this stopped happening for a few versions, or it may have just been luck, something to look at since seems like something going on there. Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] #0.3.6n
Oops, that's 0.3.6o, well should notice that anyways, got behind on which version I released there :-). Thanks, Chris Chris Kennedy wrote: This has all the recent patches plus fixes to encoder buffering, I hope, trying to make that more stable, added more buffers when statically allocated or to keep around by startup default, also bigger buffers if statically allocated on module load to ease encoder DMA and reading from the buffers. #0.3.6n: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] I2C level transfers not supported
Is it still working, those mean the fast fw load isn't working, it's supposed to fall back onto the slow firmware load though, and set that so it doesn't waste time trying, maybe something else needed to kick it into slow gear there, but is at least a good thing if it's failing over to normal firmware load and working after that. Thanks, Chris Chris Baumgartner wrote: Hi All, On system startup, I am getting hundreds of the following in dmesg: i2c_adapter i2c-1: I2C level transfers not supported Is this ivtv related? What do these messages mean? System Specs: ABit AS8 3.0GHz P4 (800Mhz FSB) PVR-150 (Non-MSC) NVida FX5200 MythTV 0.18.1 (Jarods Howto) Ivtv 0.3.6 e RH-FC 3 NTSC Thanks for you help! --Chris -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Video quality differences between PVR-150 / 250
The main thing about the cx25840 is that it's cheaper, includes the audio and video in one chip, and comes from Conexant too so get a package deal on the cx23416 and cx25840 together. So it's very likely this is true, the chip is probably exactly what you get for the cheaper price, just like the newer tuners they are using compared with the old ones (could even be the tuner difference your seeing? have you tried this with composite?). It's sad but expected for the price of these cards, although really think they'd keep the 250 cards available for those wanting a higher quality encoding still. Thanks, Chris Bryan Mayland wrote: I was under the impression that the cx25840 used in the PVR-150 was a better digitizer than the sa7115 used in the PVR-250. If that's true, then something is up because it looks the opposite to me: http://capnbry.net/~bmayland/fi/pvr150/pvr150-250.jpg (This is tuner input with dnr_mode=3,temporal=0,spatial=0. I've also tried switching cables between the two cards) Thinking it might be something we're doing wrong, I installed windows on a spare hard drive, then spent 15 minutes trying to figure out how to switch between cards in WinTV2000 (you can't), it looks like I get the same picture quality under windows too. So were my assumptions about the cx25840 incorrect, or are both the drivers not getting the best picture quality from the card? --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- === Chris Kennedy [EMAIL PROTECTED] --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.6a added cx25840 fw load patch, msleep patch
This adds all the recent patches... #0.3.6a: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] [PATCH] Incorrect valuemap used fo AFD_FMT_STAT
Merging them would be fine, or separate, either one works, I'll wait for both till I include them so either way. Thanks, Chris On Mon, Jun 06, 2005 at 11:40:08AM -0400, Bryan Mayland wrote: Bryan Mayland wrote: I was going to change the FIXME in cx25840-driver.c... I've also got a patch for this. Chris, do you want to do a revision that includes just AFD_FMT_STAT_value_fixup.diff, verify it doesn't mess anything up, and then I'll submit a patch for the FIXME to be included in the following revison? Or is it ok just to merge those two changes together into one? --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Newer firmware
I always use hexedit and view it that way, it's right at the top of the firmware files, so quick way to tell for sure what exact version, have now idea why some of the newer ones have all the extra crap at the end (which is unused and nothing except that, crap, and throws off our md5 checksumming of course). Thanks, Chris On Mon, Jun 06, 2005 at 08:40:27PM +0100, Ian Campbell wrote: On Sun, 2005-06-05 at 21:28 -0500, William Powers wrote: This may be useful: http://ivtv.writeme.ch/tiki-index.php?page=FirmwareVersions I've noticed that strings ivtv-fw-dec.bin | grep Version shows a version string embedded in each binary file, at least in all the files I've got. Perhaps this could be something which might usefully be incorporated into the page? Ian. -- Ian Campbell Prizes are for children. -- Charles Ives, upon being given, but refusing, the Pulitzer prize -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by: NEC IT Guy Games. How far can you shotput a projector? How fast can you ride your desk chair down the office luge track? If you want to score the big prize, get to know the little guy. Play to win an NEC 61 plasma display: http://www.necitguy.com/?r=20 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.5x autodetection really fixed now
Found that autodetection still had some bugs, I went through and re-ordered it right, and should be even better at either detecting or else forcing the standard on module cmd line options. This was breaking YUV for NTSC under certain circumstances. #0.3.5x: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.5u fixes vsync interrupt
This hasn't gotten the newest patches in it yet, but I did fix vsync interrupts to work better, use less dangerous interruptible sleeps, now doing ivtvctl -k will show perfect per frame vsync interrupts. #0.3.5u: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] #0.3.5u fixes vsync interrupt
Hmm, interesting, not sure what is riding on the vsync interrupt there being more than a vsync in frequency :-), but have to check more later tonight, sounds like somethings odd there. Thanks, Chris On Thu, Jun 02, 2005 at 10:45:45AM -0700, Louie Ilievski wrote: On Thursday 02 June 2005 06:28 am, Chris Kennedy wrote: This hasn't gotten the newest patches in it yet, but I did fix vsync interrupts to work better, use less dangerous interruptible sleeps, now doing ivtvctl -k will show perfect per frame vsync interrupts. #0.3.5u: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris This version causes my playback to be jittery - not very badly as in a choppy picture, but almost like a small vibration in the image. I only tested this in LiveTV mode, but I don't see why it wouldn't produce the same results with watching a recording as well. Nothing in the logs shows up. Thanks, ~Lou -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.5v fixes to vsync, patches added, vbi setup uses fmt
This fixes hopefully the vsync problem for now, but still has the improvements to that mostly. Also patches were added and the vbi setup now uses the fmt register if norm not already set. #0.3.5v: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.5w fixes to VBI buffers
This removed the code which seems to mess up VBI, splitting the buffers smaller. Also some other changes to YUV which are similar, anad trying the vsync interrupt a little different, seems the wait_event_interruptible functions are not acting as good as the old interruptible_sleep_on ones. #0.3.5w: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] People in PAL translate vbi/vblank register setup
I've got the info in a FIXME commented out section in cx25840-driver.c for the vblank picture setup like done in PAL, translated the NTSC one but hoping a person can do the same and test it (plus figure out what the 2 different ones are? possible SECAM???). Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] cx25840 digitizer always left runningj
It's meant to turn it off, then run the input init api, and then turn the digitizer back on, this is the way the encoder is recommended to be setup before a capture. So anything else there, power down, probably doesn't belong because that function is really specific to just the disable of the digitizer (to keep it from having any video output) during that input init API call. I'd make a new ioctl call possibly for that I guess, don't think it'd be good to do anything else during that process since it's in the middle of capture setup and possibly should be an ioctl to use by applications to shut it down (since probably would add to delay of starting a capture). Thanks, Chris On Thu, Jun 02, 2005 at 05:31:50PM -0400, Bryan Mayland wrote: I went in this afternoon and added code to power down unused AFE channels (by input), and power down everything when not encoding. I was curious if this was safely doable, because logically it should be (why run the ADCs if we're not capturing? etc) I came across something else though and I was wondering if it was supposed to be that way. I added my code to the DECODER_ENABLE_OUTPUT ioctl, but it wasn't getting called when I thought it would be (as indicated by cx25840: decoder disable/enable output log messages). Module load: Decoder disabled then enabled Capture: I believe in the VBI DMA init, decoder disabled then enabled. I was thinking that cx25840's DECODER_ENABLE_OUTPUT was supposed to be turning on and off the digitizer when needed for capture. Is this not the case? PS - I hacked in setting DECODER_ENABLE_OUTPUT as needed in ivtv-fileops.c and it looks like we can power down all 3 AFE channels, both ADCs and their DLLs, as well as the filter tuning circuitry while not doing a capture with no adverse affects! I'd love to get this in once I resolve where is should be. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.5t added NTSC vbi setup changes from i2c dumps
Thanks to the i2c dumps for NTSC vbi setup, this now has the method the windows driver uses to set the registers for that, which may help the picture centered problem. #0.3.5t: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] #0.3.5t added NTSC vbi setup changes from i2c dumps
Ben, You welcome, that was a great help, also the variable it's checking for the different values would be the Luma Comb Filter by the way. Thanks, Chris On Wed, Jun 01, 2005 at 03:12:28PM -0400, Ben Lancki wrote: On my setup the picture looks great, it is very well centered now. If you need any other i2c dumps, let me know. Thanks for all your work Chris. On 6/1/05, Chris Kennedy [EMAIL PROTECTED] wrote: Thanks to the i2c dumps for NTSC vbi setup, this now has the method the windows driver uses to set the registers for that, which may help the picture centered problem. #0.3.5t: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.5p fixes autodetection, encoder setup
This fixes autodetection so it works correctly again, and still sets the variables for NTSC or PAL that are different for buffer sizes. Also the encoder setup is now done even when we have another capture open for vbi or such, to rerun the API commands once again. #0.3.5p: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Which version for PVR-150?
Try 0.3.5p, should be better than that version, especially for NTSC, at least can know from mine working it does. Thanks, Chris On Tue, May 31, 2005 at 07:02:11AM -0700, Mark Knecht wrote: Hi, What would be the most recommended driver for using a PVR-150 in the U.S.? I'm currently using 0.3.3k, probably incorrctly I think, and am having some problems. I'm pretty available for testing if that would help. Thanks, Mark --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] 0.3.5m: PAL teletxt and CX25840_VBI_RAW_SIZE
Cool, interesting about the line size, from what I can tell the hauppauge drivers may set this an extra 12 bytes to make up for missing data and the VBI buffers drifting, and it may just be for CC, a mystery still why the do it in even teletext mode, must be something odd they are doing. It looks like I need to specify it for just CC again. Are the people disassemling the windows driver able to check into this and see what they are doing exactly for VBI, I have one clue of where you can find the code, look for the start/stop codes we use for VBI setup in ivtv-streams.c (0x20602060, 0x30703070), that leads you right to the VBI setup. Thanks, Chris On Sun, May 29, 2005 at 03:52:37PM +0200, Ulrich Mayer wrote: Chris, 0.3.5m is the first version I used since two weeks ago. Someone set the VBI_RAW_SIZE to 1444+12. This breaks teletext for me. After fixing that back to 1444 I see an improvement: I can now watch tv and browse teletext at the same time without seeing blocking artefacts in the video. Great! Audio on composite is missing, on line in/svideo it has a crackling noise. Uli tveeprom: Hauppauge: model = 26034, rev = C197, serial# = 7702916 tveeprom: tuner = LG PAL (TAPE Series) (idx = 97, type = 55) tveeprom: tuner fmt = PAL(B/G) PAL(D/K) (eeprom = 0x44, v4l2 = 0x0e07) tveeprom: audio_processor = MSP3400C (type = 4) pal=G --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] 0.3.5m: PAL teletxt and CX25840_VBI_RAW_SIZE
Try 0.3.5n, I changed this for it. Thanks, Chris On Sun, May 29, 2005 at 03:52:37PM +0200, Ulrich Mayer wrote: Chris, 0.3.5m is the first version I used since two weeks ago. Someone set the VBI_RAW_SIZE to 1444+12. This breaks teletext for me. After fixing that back to 1444 I see an improvement: I can now watch tv and browse teletext at the same time without seeing blocking artefacts in the video. Great! Audio on composite is missing, on line in/svideo it has a crackling noise. Uli tveeprom: Hauppauge: model = 26034, rev = C197, serial# = 7702916 tveeprom: tuner = LG PAL (TAPE Series) (idx = 97, type = 55) tveeprom: tuner fmt = PAL(B/G) PAL(D/K) (eeprom = 0x44, v4l2 = 0x0e07) tveeprom: audio_processor = MSP3400C (type = 4) pal=G --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Reboots with PVR500MCE on 0.3.5m on Via Apollo Pro 133?
PVR 150, card #0 ivtv: Autodetected WinTV PVR 150 card ivtv: Found an iTVC16 based chip ivtv: ivtv_enc_thread: pid = 5412, itv = 0xf08eb620 ivtv: ivtv_enc_vbi_thread: pid = 5413, itv = 0xf08eb620 ACPI: PCI interrupt :02:09.0[A] - GSI 11 (level, low) - IRQ 11 ivtv: VIA PCI device: 0x0691 vendor: 0x1106 tveeprom: Hauppauge: model = 23559, rev = D591, serial# = 2989873 tveeprom: tuner = Philips FQ1216AME MK4 (idx = 91, type = 56) tveeprom: tuner fmt = PAL(B/G) PAL(I) SECAM(L/L) PAL(D/K) (eeprom = 0x74, v4l2 = 0x00400e17) tveeprom: audio_processor = MSP3410D (type = 5) ivtv: i2c attach [client=tveeprom[50],ok] tuner: chip found at addr 0xc2 i2c-bus ivtv i2c driver #1 ivtv: i2c attach [client=(tuner unset),ok] cx25840: starting probe for adapter ivtv i2c driver #1 (0x10005) cx25840: detecting cx25840 client on address 0x88 cx25840: writing init values cx25840: FW image '/lib/modules/HcwMakoA.ROM' of size 13883 loaded. cx25840: FW image md5 digest: a6f6a90a3be338cdb89d59e835798408 cx25840: FW image sha1 digest: ad2872fb98ad43b6c4afa45d239a57010edebe84 cx25840: Status: cx258433 (DEVICE_ID) ivtv: i2c attach [client=cx25840[50],ok] ivtv: i2c attach [client=wm8775[50],ok] tda9885/6/7: chip found @ 0x86 ivtv: i2c attach [client=tda9887,ok] ivtv: Tuner Type 56, Tuner formats 0x00400e17, Radio: yes, Model 0x00915651, Revision 0x ivtv: Radio detected ivtv: Encoder revision: 0x02040011 ivtv: Configuring WinTV PVR 150 card with 5 streams ivtv: Registered v4l2 device, streamtype 0 minor 1 ivtv: Create DMA stream 0 using 128 16384 byte buffers 0 kbytes total ivtv: Registered v4l2 device, streamtype 1 minor 33 ivtv: Create DMA stream 1 using 80 25920 byte buffers 0 kbytes total ivtv: Registered v4l2 device, streamtype 2 minor 225 ivtv: Create DMA stream 2 using 41 50540 byte buffers 0 kbytes total ivtv: Registered v4l2 device, streamtype 3 minor 25 ivtv: Create DMA stream 3 using 455 4608 byte buffers 0 kbytes total ivtv: Registered v4l2 device, streamtype 4 minor 65 ivtv: Create stream 4 ivtv: Setting Tuner 56 tuner: type set to 56 (Philips PAL/SECAM multi (FQ1216AME MK4)) by ivtv i2c driver #1 cx25840: decoder set norm PAL cx25840: decoder set input (6) cx25840: now setting Tuner input cx25840: set audio input (0) ivtv: Switching standard to PAL. ivtv: Initialized WinTV PVR 150, card #1 ivtv: END INIT IVTV ivtv: ivtv_enc_thread: pid = 5481, itv = 0xf090e890 ivtv: ivtv_enc_vbi_thread: pid = 5482, itv = 0xf090e890 --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] #0.3.5m vbi buffer offset more exact
This is probably from a bad module parameter, what are yours, possibly remove the black_magic or audiofmt ones from cx25840, or maybe another one, the Unknown parameter line looks suspicious. Thanks, Chris On Sat, May 28, 2005 at 09:14:18PM +0200, Patrick de Brabander [mythtv] wrote: After upadting form 0.3.5f - 0.3.5m the follow errors appear in the log. May 28 21:02:35 localhost kernel: ivtv: Unknown parameter `' May 28 21:02:35 localhost kernel: ivtv: START INIT IVTV May 28 21:02:35 localhost kernel: ivtv: version 0.3.5 (m) loading May 28 21:02:35 localhost kernel: ivtv: Linux version: 2.6.10-1.771_FC2 686 REGPARM 4KSTACKS gcc-3.3 May 28 21:02:35 localhost kernel: ivtv: In case of problems please include the debug info May 28 21:02:35 localhost kernel: ivtv: between the START INIT IVTV and END INIT IVTV lines when May 28 21:02:35 localhost kernel: ivtv: mailing the ivtv-devel mailinglist. May 28 21:02:35 localhost kernel: ivtv: Autodetected WinTV PVR 350 card May 28 21:02:35 localhost kernel: ivtv: Found an iTVC15 based chip May 28 21:02:35 localhost kernel: PCI: Found IRQ 10 for device :02:0a.0 May 28 21:02:35 localhost kernel: ivtv: XXX PCI device: 0x1130 vendor: 0x8086 May 28 21:02:37 localhost modprobe: FATAL: Error inserting ivtv_fb (/lib/modules/2.6.10-1.771_FC2/ivtv/ivtv-fb.ko): Unknown symbol in module, or unknown parameter (see dmesg) May 28 21:02:38 localhost kernel: ivtv_fb: Unknown symbol ivtv_cards_active May 28 21:02:38 localhost modprobe: FATAL: Error running install command for ivtv May 28 21:02:39 localhost kernel: ivtv_fb: Unknown symbol ivtv_debug May 28 21:02:40 localhost kernel: ivtv_fb: Unknown symbol ivtv_vapi May 28 21:02:40 localhost kernel: ivtv_fb: Unknown symbol ivtv_cards May 28 21:02:40 localhost kernel: ivtv_fb: Unknown symbol ivtv_api May 28 21:02:40 localhost kernel: tveeprom: Hauppauge: model = 48139, rev = K257, serial# = 7596027 May 28 21:02:40 localhost kernel: tveeprom: tuner = Philips FM1216 ME MK3 (idx = 57, type = 38) May 28 21:02:40 localhost kernel: tveeprom: tuner fmt = PAL(B/G) PAL(I) SECAM(L/L) PAL(D/K) (eeprom = 0x74, v4l2 = 0x00400e17) May 28 21:02:40 localhost kernel: tveeprom: audio_processor = CS5331 (type = 9) May 28 21:02:40 localhost kernel: ivtv: i2c attach [client=tveeprom[50],ok] May 28 21:02:40 localhost kernel: ivtv: Tuner Type 38, Tuner formats 0x00400e17, Radio: yes, Model 0x00ad2557, Revision 0x0001 May 28 21:02:40 localhost kernel: ivtv: Radio detected May 28 21:02:40 localhost kernel: tuner: Ignoring new-style parameters in presence of obsolete ones gr. patrick This uses a register containing the VBI buffer offset to be exact about buffer grabbing, seems much better than the old method and so far seems to not miss characters in vbi insertion etc... Please check this in PAL for teletext, still trying to get it working right and not missing characters in raw mode, hopefully this buffer offset thing makes that happen, or closer. #0.3.5m: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- gr. patrick --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] #0.3.5m Audio out of sync for PVR-350
Is this just using cat? I doubt out of sync audio would ever be the drivers fault because there's really nothing we do to alter the mpeg stream and it's all hardware muxed, no settings to change that besides an audio/video delay API we don't touch in the driver. Try cat and/or dd to see if it really is the hardware doing this that way, or if already done that then it is really odd, I'm not sure what could have caused this, maybe someone else can think of something? Thanks, Chris On Sat, May 28, 2005 at 10:12:06PM +0200, Michel Verbraak wrote: I do not know if this happened in a previous version of 0.3.5 but with the m version I have out of sync audio on my pvr-350 and on my pvr-150 I sometimes have audio and sometimes not. When I have audio on the PVR-150 it is not out of sync. When I have audio on the PVR-150 and I change to another channel the audio is lost again. I use the following to get the drivers loaded (PVR-150 is first and PVR-350 is second) options saa7127 i2c_enable=-1,-1,1 options cx25840 i2c_enable=1,1,-1 fw_file_name=/lib/modules/HcwMakoA.ROM modprobe ivtv ivtv_std=2 tda9887=0,0 Regards, Michel Verbraak. But the worst is the out of sync audio on the pvr-350. Chris Kennedy wrote: This uses a register containing the VBI buffer offset to be exact about buffer grabbing, seems much better than the old method and so far seems to not miss characters in vbi insertion etc... Please check this in PAL for teletext, still trying to get it working right and not missing characters in raw mode, hopefully this buffer offset thing makes that happen, or closer. #0.3.5m: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Card left in SOFT_RESET 0.3.5j
On Fri, May 27, 2005 at 08:26:41AM -0400, Bryan Mayland wrote: In the 0.3.5j patch this morning, the DECODER_ENABLE_OUTPUT ioctl has two CX25840_SET_SOFT_RESET(0x0001) calls and none that turn it off, leaving the card in soft reset at the exit of the function. Is that intentional? Ah, thanks for seeing that, didn't do that right :-). Also, did you see my post yesterday about what are those cx25840_write() calls doing there? They turn up the brightness and luma boost during capture? Why? Those are not supposed to be brightness and luma boost, actually are they are supposed to be the chip on/off control of pixel output and supposed to turn it off/on. It seems somewhere in the changing register functions those got switched accidently to 4XX instead of 1XX i2c values. I just re-uploaded 0.3.5j and fixed that, thanks alot for finding that. Thanks, Chris --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.5j s-vid patch, fixes from Bryan Mayland, re-init cx25840 input
This addes the s-video patch from Tyler, will re-init the cx25840 input upon each capture and thanks to Bryan Mayland actually properly turns the digitzer on/off again. #0.3.5j: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] [PATCH] more cx25840 cleanup
Actually one problem I see with this patch, and it's a recent change which I'm still trying to figure out the reasons for needing. There seems to be a problem running the pvr500/150 over extended periods of time for audio, will just stop working eventually, after a day or so. It seems that if you switch inputs, or reinit the input, things begin working once again. So it seems like each time we start an encoding we need to redo that input register setup, makes sense since each input init the chip autodetects the audio standard and so on. I think this patch, although usually would be a good thing, makes it not happen which my last 0.3.5j actually made it force an input init each capture startup. So something for people to see if they too have this problem, if the last version fixes it, and what should we do for this to work properly, I'm still looking closer at this to see if your patch actually undoes that forced input init, just maybe remove the part which checks if it's already the input, or maybe what I did won't change with this patch and it's fine (I think I void the input to -1, so more I think about it, more it seems like your patch should be just fine). Let me know what you think, if you've had this odd audio drop out problem too, or anyone else seeing it and thoughts on what we can do, or if I've hopefully fixed it already :-). Thanks, Chris On Fri, May 27, 2005 at 02:29:35PM -0400, Tyler Trafford wrote: Straight forward patch, does the following: * During initialization, instead of iteratively copying the array values for cx25840_input_layout, just the set a pointer to the proper array. * In DECODER_SET_INPUT, assign state-input after performing operation successfully. Also tried to make debug messages more like the saa7115. * Move log_status() call to bottom of ioctl command function, since it's way more useful _after_ we've done something than before. * Rearrange DECODER_SET_AUDIO* so that they only return on an error, just like the others. * No reason for functions only called from a single place not to be 'inline', so I made them so. -- Tyler Trafford -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] [PATCH] more cx25840 cleanup
Yeah, that is strange, I was wondering how it fixed it too, maybe the chip just saw the video re-init and does something about audio automatically? I'll know within a day or so if it really fixed it, I'll look at the audio re-init too, sounds interesting to do that too. Thanks, Chris On Fri, May 27, 2005 at 03:05:48PM -0400, Tyler Trafford wrote: Oh, I forgot to mention that I made SET_NORM check to see if it was already set, and not do anything if it was... i can't see how that could break what you did, though. Your force of state-input should still make the input reinitialize correctly. You may want to reinit the audio_input too though. That is very odd though, SET_INPUT no longer has anything in it that should effect the audio. -Tyler On 5/27/05, Chris Kennedy [EMAIL PROTECTED] wrote: Actually one problem I see with this patch, and it's a recent change which I'm still trying to figure out the reasons for needing. There seems to be a problem running the pvr500/150 over extended periods of time for audio, will just stop working eventually, after a day or so. It seems that if you switch inputs, or reinit the input, things begin working once again. So it seems like each time we start an encoding we need to redo that input register setup, makes sense since each input init the chip autodetects the audio standard and so on. I think this patch, although usually would be a good thing, makes it not happen which my last 0.3.5j actually made it force an input init each capture startup. So something for people to see if they too have this problem, if the last version fixes it, and what should we do for this to work properly, I'm still looking closer at this to see if your patch actually undoes that forced input init, just maybe remove the part which checks if it's already the input, or maybe what I did won't change with this patch and it's fine (I think I void the input to -1, so more I think about it, more it seems like your patch should be just fine). Let me know what you think, if you've had this odd audio drop out problem too, or anyone else seeing it and thoughts on what we can do, or if I've hopefully fixed it already :-). Thanks, Chris On Fri, May 27, 2005 at 02:29:35PM -0400, Tyler Trafford wrote: Straight forward patch, does the following: * During initialization, instead of iteratively copying the array values for cx25840_input_layout, just the set a pointer to the proper array. * In DECODER_SET_INPUT, assign state-input after performing operation successfully. Also tried to make debug messages more like the saa7115. * Move log_status() call to bottom of ioctl command function, since it's way more useful _after_ we've done something than before. * Rearrange DECODER_SET_AUDIO* so that they only return on an error, just like the others. * No reason for functions only called from a single place not to be 'inline', so I made them so. -- Tyler Trafford -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- Tyler Trafford --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.5k patches and re-init audio/video/vbi/norm each capture
This adds Tylers patches and also does a re-init on the cx25840 for not only the input for video but also the norm/audio and vbi now. #0.3.5k: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] [PATCH] VBLANK adjustment
Actually without that VBI won't work, the Hauppauge driver sets that up exactly as we do for PAL and NTSC, odd but a fact, without that setup VBI doesn't work (actually the last 4 registers set in there, but all in a bundle, and improves picture quality too, seems to override the trigger tolerances for certain things) Thanks, Chris On Thu, May 26, 2005 at 04:04:14PM -0400, Ben Lancki wrote: According to the docs VBLANK should be set to 22/34 in autoconfig, but according to the register definitions, it defaults to 20. If disable setting the register, it does in fact get set to 20 rather than 22. I think if this value was manually set to ~24 the vbi data at the top would no longer be visible and the picture would line up with what I normally see on my tv. I also noticed that VACTIVE was set to 580 and when I let this autoconfig, it sets it to 487 (I'm not sure if that adversely affects anything). Actually, everything in the vbi_reg_setup (0x474-0x477) probably doesn't belong there and could be setup through autoconfig. On 5/26/05, Bryan Mayland [EMAIL PROTECTED] wrote: The datasheet also says: In autoconfiguration mode, the default value for the vertical blanking delay, VBLANK (0x474 an 0x475) is set to 22 and 34, respectively, for each video standard. So maybe we should just let it autoconfigure. Also, I've never noticed this before, but why does vbi_reg_setup write to 0x474 and 0x475? These are only VBLANK and VACTIVE, so those should be set up when setting the standard, right? Granted, VBLANK controls the size of the VBI region, but I don't think this is the place to set it, especially considering it doesn't currently take video standard into account. Ben Lancki wrote: This was one of the last visual things bugging me with the driver. The screen always appeared vertically offset by 10-15 pixels from the broadcast video. According to the cx25840 documentation, VBLANK should be 22 for NTSC and 34 for PAL/SECAM. This patch sets it to 22 or 34 depending on the card region (although I can only test NTSC). It was originally set to 36 so probably NTSC people will be the only ones to notice any big difference. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] [PATCH] VBLANK adjustment
And this patch does break VBI on the pvr150/500, plus you have to set the other register 0x476 to the same value, and they have to be offset of another register too which hasn't been changed. Well basically it seems this isn't what the Windows driver is doing, maybe there's another way to do this, but right now this way breaks VBI and offshoots form what we know the windows driver is setting the register (does 0x24 for both PAL and NTSC). Thanks, Chris On Thu, May 26, 2005 at 03:13:59PM -0500, Chris Kennedy wrote: Actually without that VBI won't work, the Hauppauge driver sets that up exactly as we do for PAL and NTSC, odd but a fact, without that setup VBI doesn't work (actually the last 4 registers set in there, but all in a bundle, and improves picture quality too, seems to override the trigger tolerances for certain things) Thanks, Chris On Thu, May 26, 2005 at 04:04:14PM -0400, Ben Lancki wrote: According to the docs VBLANK should be set to 22/34 in autoconfig, but according to the register definitions, it defaults to 20. If disable setting the register, it does in fact get set to 20 rather than 22. I think if this value was manually set to ~24 the vbi data at the top would no longer be visible and the picture would line up with what I normally see on my tv. I also noticed that VACTIVE was set to 580 and when I let this autoconfig, it sets it to 487 (I'm not sure if that adversely affects anything). Actually, everything in the vbi_reg_setup (0x474-0x477) probably doesn't belong there and could be setup through autoconfig. On 5/26/05, Bryan Mayland [EMAIL PROTECTED] wrote: The datasheet also says: In autoconfiguration mode, the default value for the vertical blanking delay, VBLANK (0x474 an 0x475) is set to 22 and 34, respectively, for each video standard. So maybe we should just let it autoconfigure. Also, I've never noticed this before, but why does vbi_reg_setup write to 0x474 and 0x475? These are only VBLANK and VACTIVE, so those should be set up when setting the standard, right? Granted, VBLANK controls the size of the VBI region, but I don't think this is the place to set it, especially considering it doesn't currently take video standard into account. Ben Lancki wrote: This was one of the last visual things bugging me with the driver. The screen always appeared vertically offset by 10-15 pixels from the broadcast video. According to the cx25840 documentation, VBLANK should be 22 for NTSC and 34 for PAL/SECAM. This patch sets it to 22 or 34 depending on the card region (although I can only test NTSC). It was originally set to 36 so probably NTSC people will be the only ones to notice any big difference. --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net
[ivtv-devel] #0.3.5i encoder work queue fixes, decoder DMA error fixes
I suspect this will fix the decoder DMA errors seen recently, and also fix some obscure bugs in the encoder work queues with stopping the work queues and clearing the DMAP flag properly. #0.3.5i: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.5h fixes for pvr350/500/150 conflicts
There seems to have been some bugs in incrementing the cx25840 module counting for the fix to conflicting i2c addresses for saa7127 and cx25840 address skipping. This fixes that. #0.3.5h: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- SF.Net email is sponsored by: GoToMeeting - the easiest way to collaborate online with coworkers and clients while avoiding the high cost of travel and communications. There is no equipment to buy and you can meet as often as you want. Try it free.http://ads.osdn.com/?ad_id=7402alloc_id=16135op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] SuSE 9.3 - error when modprobing IVTV
I think the firmware isn't under /lib/modules/ Thanks, Chris On Tue, May 24, 2005 at 09:07:26AM -0400, Hilary L Hertzoff wrote: I've been running IVTV on SuSE 9.2 for about 6-8 months. Now on a new install of 9.3 on a new harddrive, I'm running into problems. None of the other hardware has changed. I've tried using the included IVTV package, reinstalling the package, upgrading to the latest tarball, reinstalling the firmware, copying over my modprobe files from the old installation, replacing the firmware files with newly extracted ones and with the ones from the old installation. None of this has fixed the problem. When I run modprobe IVTV I get the following messages. Everything seems to be fine, but it's not finding the firmware (which is in the same place as it was in the old install). Any thoughts? Thanks Hilary May 24 09:05:59 linux kernel: ivtv: START INIT IVTV May 24 09:05:59 linux kernel: ivtv: version 0.3.2 (c) loading May 24 09:05:59 linux kernel: ivtv: Linux version: 2.6.11.4-20a-default gcc-3.3 May 24 09:05:59 linux kernel: ivtv: In case of problems please include the debug info May 24 09:05:59 linux kernel: ivtv: between the START INIT IVTV and END INIT IVTV lines when May 24 09:05:59 linux kernel: ivtv: mailing the ivtv-devel mailinglist. May 24 09:05:59 linux kernel: ivtv: Autodetected WinTV PVR 250 card May 24 09:05:59 linux kernel: ivtv: Found an iTVC16 based chip May 24 09:05:59 linux kernel: ACPI: PCI interrupt :00:08.0[A] - GSI 19 (level, low) - IRQ 185 May 24 09:05:59 linux kernel: ivtv: VIA PCI device: 0x3188 vendor: 0x1106 May 24 09:05:59 linux kernel: i2c-algo-bit.o: (0) scl=1, sda=1 May 24 09:05:59 linux kernel: i2c-algo-bit.o: (1) scl=1, sda=0 May 24 09:05:59 linux kernel: i2c-algo-bit.o: (2) scl=1, sda=1 May 24 09:05:59 linux kernel: i2c-algo-bit.o: (3) scl=0, sda=1 May 24 09:05:59 linux kernel: i2c-algo-bit.o: (4) scl=1, sda=1 May 24 09:05:59 linux kernel: i2c-algo-bit.o: ivtv i2c driver #0 passed test. May 24 09:05:59 linux kernel: ivtv: i2c attach [client=tveeprom,ok] May 24 09:05:59 linux kernel: tuner: chip found at addr 0xc2 i2c-bus ivtv i2c driver #0 May 24 09:05:59 linux kernel: ivtv: i2c attach [client=(tuner unset),ok] May 24 09:05:59 linux kernel: saa7115: starting probe for adapter ivtv i2c driver #0 (0x10005) May 24 09:05:59 linux kernel: saa7115: detecting saa7115 client on address 0x42 May 24 09:05:59 linux kernel: saa7115: writing init values May 24 09:05:59 linux kernel: ivtv: i2c attach [client=saa7115[6],ok] May 24 09:05:59 linux kernel: saa7115: status: (1E) 0x48, (1F) 0xc0 May 24 09:05:59 linux kernel: msp34xx: init: chip=MSP3445G-B8 +nicam +simple +simpler +radio mode=simple May 24 09:05:59 linux kernel: ivtv: i2c attach [client=MSP3445G-B8,ok] May 24 09:05:59 linux kernel: msp3410: daemon started May 24 09:05:59 linux kernel: tveeprom: Hauppauge: model = 32062, rev = B185, serial# = 7363116 May 24 09:05:59 linux kernel: tveeprom: tuner = TCL 2002N 6A (idx = 85, type = 50) May 24 09:05:59 linux kernel: tveeprom: tuner fmt = NTSC(M) (eeprom = 0x08, v4l2 = 0x1000) May 24 09:05:59 linux kernel: tveeprom: audio_processor = MSP3445 (type = 12) May 24 09:05:59 linux kernel: ivtv: Tuner Type 50, Tuner formats 0x1000, Radio: yes, Model 0x00891615, Revision 0x80344736 May 24 09:05:59 linux kernel: ivtv: NTSC tuner detected May 24 09:05:59 linux kernel: ivtv: Radio detected May 24 09:05:59 linux udevd[2303]: move seq 1129 with timeout 10 to exec queue May 24 09:05:59 linux kernel: ivtv: requesting firmware May 24 09:06:00 linux udevd[2303]: move seq 1130 with timeout 10 to exec queue May 24 09:06:00 linux kernel: ivtv: firmware load failed May 24 09:06:00 linux kernel: ivtv: failed loading encoder firmware May 24 09:06:00 linux kernel: ivtv: Error loading firmware -3! May 24 09:06:00 linux kernel: ivtv: Error -3 initializing firmware. May 24 09:06:00 linux kernel: ivtv: Error -12 on initialization May 24 09:06:00 linux kernel: ivtv-iTVC15_16_mpg2_encoder_card: probe of :00:08.0 failed with error -12 May 24 09:06:00 linux kernel: ivtv: END INIT IVTV --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network
[ivtv-devel] #0.3.5g added cx25840 cleanup patch
This adds the cleanup patch for the cx25840 module. #0.3.5g: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] [PATCH] yuv close fixup
ivtv: Decoder VBI RE-Insert start 0x0019ac00 size 0xbe00 type 0 Unable to handle kernel NULL pointer dereference at virtual address 0013 printing eip: df85c179 *pde = Oops: [#1] PREEMPT SMP Modules linked in: ivtv_fb msp3400 saa7127 saa7115 tuner tveeprom ivtv i2c_algo_bit i2c_core videodev button CPU:0 EIP:0060:[df85c179]Not tainted VLI EFLAGS: 00010202 (2.6.10) EIP is at video_open+0x59/0x250 [videodev] eax: 0013 ebx: df85e080 ecx: cbfb1050 edx: c463f180 esi: ded34480 edi: c463f180 ebp: d5fcb4cc esp: d30e9ee4 ds: 007b es: 007b ss: 0068 Process foo (pid: 25155, threadinfo=d30e8000 task=de38e020) Stack: dc218880 c022f8ca dc218898 df85e100 dc218880 df85c120 d5fcb4cc c0162e46 d5fcb4cc c463f180 0002 c463f180 c463f180 d5fcb4cc c1496880 0001 c0158dba d5fcb4cc c463f180 003f 0002 08085820 Call Trace: [c022f8ca] kobject_get+0x1a/0x30 [df85c120] video_open+0x0/0x250 [videodev] [c0162e46] chrdev_open+0xf6/0x1c0 [c0158dba] dentry_open+0x16a/0x260 [c0158c48] filp_open+0x68/0x70 [c0159c32] vfs_write+0xd2/0x130 [c0158f3c] get_unused_fd+0x8c/0xe0 [c0159089] sys_open+0x49/0x90 [c010318f] syscall_call+0x7/0xb Code: 00 f0 ff 0d 60 e0 85 df 0f 88 77 06 00 00 8b 34 9d 80 e6 85 df 85 f6 0f 84 a7 01 00 00 8b 46 34 8b 5f 10 85 c0 0f 84 7d 01 00 00 8b 10 b8 01 00 00 00 89 44 24 0c 85 d2 74 43 b8 00 e0 ff ff 21 cheers; M. -- __ Matthew Hodgson [EMAIL PROTECTED] Tel: +44 845 6667778 Systems Analyst, MX Telecom Ltd. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.5e patches for YUV, smaller buffers
This allocates smaller buffers for YUV to reduce memory stress, also has Johns recent patch for YUV close, and some VBI changes to not do the byteswap for raw data in the work queue. #0.3.5e: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.5f vbi buffer size change, check for teletext
Please check this in teletext mode in PAL land, see if it fixes the problem there, anyone who can. Also this fixes raw mode when mpeg-insert is set to still use DMA. #0.3.5f: http://www.ivtv.tv/releases/ivtv-0.3.5f.tgz Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] #0.3.5c fixed YUV decoding problems for /dev/video48, alias oddity
Ah, need to do this actually, for the time being... modprobe ivtv ivtv_std=2 This should allow alot of logic in the ivtv driver itself to work for PAL/NTSC switching, which has never really been active because we have alot of logic well before the autodetection which checks the tv standard. Also the digitizer startup can be given the tv standard this way, otherwise we don't know the tv standard yet. It was always 'assumed' the ivtv drvier defaulted to NTSC settings and PAL would either be set or autodetected, but oddly it just didn't do that or autodetect smoothly. This change was mainly for the YUV buffers size checks, the VBI buffer and line size checks (for some reason we need this extra bit in CC else we miss characters, it's odd, but seems to be a problem), and also I force the digitizer cx25840 now into NTSC audio manually instead of autodetect mode, so it needs to know the tv standard in the digitizer, and that is set now from the ivtv module from it knowing the standard from the startup when it sets up things like the digitizer. It needs work and is more of an invitation and example of where we need to do the work to get the digitizer setup improved and module standard properly detected early on instead of later, and get things to work as expected. I think the cx25840 part is not right yet, but was a quick way to get audio to be setup properly for NTSC and give a path for PAL to do the same thing (didn't know the value for PAL or totally how we need to check and set the audio register). So it's good to use that module option, I always expected it to be used by people using PAL since that's how it originally was, but I think autodetection support was implemented and no one looked closely to see if it was really totally 'right', and seems it has pitfals which may need some major logic overhaul to make it allow decisions to be made upon the tv standard early in module load. Thanks, Chris On Sun, May 22, 2005 at 10:24:33AM +0200, Sigurd Nes wrote: The sound is very poor in 0.3.5.c compared to 0.3.5 I have not tested 0.3.5.b I live in a PALcountry, is the the black_magic stuff related to this? Regards Sigurd Chris Kennedy wrote: This should fix a couple problems with YUV decoding, especially /dev/video48, now works really nice (uses the vsync interrupt). Also I think the alias oddity of the other field seen for NTSC is now fixed. It also fixes Myth ff/rw over 3x speed image not advancing, I *think*, please test and see. #0.3.5c: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Re: #0.3.5c
Actually try ivtvctl -c dnr_temporal=0, see if that fixes the ghost. Thanks, Chris On Sun, May 22, 2005 at 02:37:41PM -0700, Johan Reinalda wrote: Chris et al., 0.3.5c works (almost) fine here, on pvr-150mce, ntsc tuner 47, on AMD64 2800+, on FC3 x86_64 but with following observations: -svideo input still has ghosting (composite is fine) -switching from tuner to svid/comp back to tuner, picture now has additional scan line on top (using simple mplayer from /dev/video0 On the svideo ghosting, I went and looked through my 'ivtv observations' doc (see partially below), and found that the ghosting started from 0.3.4m - 0.3.4m, ie when the patches from Hauppauge were added. Don't know if that helps...I'll look through the diff and see if there is something obvious... I'm going to see if I can find when the extra lines appeared in the tuner after switch back/from svideo or composite. Johan 0.3.4m tuner vid okay, audio scratchy, sqeeky comp vid okay, no audio svideo video has ghosting, no audio switching from tuner-svid-tuner add extra lines on top 0.3.4l tuner aud/vid okay comp vid okay, audio crackling svideo vid okay, audio crackling switching from tuner-svid-tuner add extra lines on top --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.5d audio patch, YUV patch
This includes the recent patches for audio and YUV, also the hotplug firmware patch. #0.3.5d: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] #0.3.5b audio patch, misc raw vbi fixes
Very interesting, try this patch, main change in VBI was this, wondering if this would be the problem... diff -ru ivtv-0.3.5d/driver/ivtv-irq.c ivtv-0.3.5e/driver/ivtv-irq.c --- ivtv-0.3.5d/driver/ivtv-irq.c 2005-05-22 00:07:02.0 -0500 +++ ivtv-0.3.5e/driver/ivtv-irq.c 2005-05-22 23:47:12.417110744 -0500 @@ -797,6 +797,10 @@ x, offset, itv-vbi_index, itv-vbi_total_frames); } + + /* Skip first start code */ + if (itv-vbi_service_set_in == 0) +offset+=4; IVTV_DEBUG(IVTV_DEBUG_DMA, DMA/VBI type 0x%08x, size 0x%08x, offset 0x%08x, There's some other things I'm curious about trying, but this is the first main thing I can see (also are you setting ivtv_std on the module command line, and what are your messages saying for the vbi setup?). Send me your dmesg output of after a VBI capture, and possibly if not already done set the ivtv_std module option for ivtv and see if those make any difference. Thanks, Chris On Sun, May 22, 2005 at 05:45:08PM +0200, Simon Zwahlen wrote: Hi Chris, more raw vbi fixes for CC I just tested with 0.3.5c, raw vbi (PAL) seems broken again. I get about 90kBaud TTX and no EPG data at all. 0.3.5 was working more or less, but nxtvepg reported some packets (about 10%) lost. Looks like this needs more work still. Regards, Simon --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.5b audio patch, misc raw vbi fixes
This has the audio patch, works well with pvr500 cards again, and has more raw vbi fixes for CC. Also it has the black magic parameter set to 1 by default now, seems like the right thing to do from the patch which Jean-Francois Thibert sent (hopefully include that soon with information on it working for pvr500 cards or a new one just doing the critical fixes, haven't had time to go through it by hand yet). This also has the ir remote re-init stuff in ivtvctl too by the way. #0.3.5b: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.5c fixed YUV decoding problems for /dev/video48, alias oddity
This should fix a couple problems with YUV decoding, especially /dev/video48, now works really nice (uses the vsync interrupt). Also I think the alias oddity of the other field seen for NTSC is now fixed. It also fixes Myth ff/rw over 3x speed image not advancing, I *think*, please test and see. #0.3.5c: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.5 actually fixing pvr500, right release
This is the actual fixes there, last version was not the right one. Also please go back and check the cx25840 driver patch and people need to figure out what is wrong there so we can get the improvements from it, but right now it breaks everything quite badly so can't include it till people report success. #0.3.5: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] #0.3.4z pvr500 broken/fixed, vbi raw changes
Yeah, I just noticed that, bad revisioning there, I need to release something with the actual changes :-), am working on that right now, just checking to see if anything else is in the queue to include. Thanks, Chris On Fri, May 20, 2005 at 10:05:30AM -0400, Tyler Trafford wrote: Chris Kennedy wrote: I have replaced the cx25840-driver.c file with the one from 3.4s since Err, no you didn't. -- Tyler Trafford --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] #0.3.5 actually fixing pvr500, right release
On a pvr500 it shows no video, and the audio is totally noisy and goes from low pitch to high pitch, just wrecks it basically. So seems it needs some different logic for those, and don't want to break them. If you can make a patch with just those settings I'll test them on the pvr500 and include them, but seems we need some more research into what is going on since it breaks the pvr500 so badly. Thanks, Chris On Fri, May 20, 2005 at 11:00:28AM -0400, Jean-Francois Thibert (SageTV) wrote: May I ask why you are going back to the old cx25840? I'd like to hear about any problems it caused...At the very least I think you should keep the adc sets to 3 when disabled and force no_black_magic to 1 (or remove that code since it's doing tda settings inside the cx25840 module) Thanks Jean-Francois Thibert On May 20, 2005 10:24 am, Chris Kennedy wrote: This is the actual fixes there, last version was not the right one. Also please go back and check the cx25840 driver patch and people need to figure out what is wrong there so we can get the improvements from it, but right now it breaks everything quite badly so can't include it till people report success. #0.3.5: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] #0.3.5 actually fixing pvr500, right release
The first input doesn't have video, second does. The audio probem happens on both from what I can tell, and here's the lspci -vn output for them... 11:08.0 Class 0400: :0016 (rev 01) Subsystem: 0070:e807 Flags: bus master, medium devsel, latency 64, IRQ 233 Memory at b400 (32-bit, prefetchable) [size=64M] Capabilities: [44] Power Management version 2 11:09.0 Class 0400: :0016 (rev 01) Subsystem: 0070:e817 Flags: bus master, medium devsel, latency 64, IRQ 50 Memory at b800 (32-bit, prefetchable) [size=64M] Capabilities: [44] Power Management version 2 Thanks, Chris On Fri, May 20, 2005 at 11:23:08AM -0400, Jean-Francois Thibert (SageTV) wrote: That's interesting, on which input does this problem happen? Also what model # of pvr500 is it? Thanks Jean-Francois Thibert On May 20, 2005 11:08 am, Chris Kennedy wrote: On a pvr500 it shows no video, and the audio is totally noisy and goes from low pitch to high pitch, just wrecks it basically. So seems it needs some different logic for those, and don't want to break them. If you can make a patch with just those settings I'll test them on the pvr500 and include them, but seems we need some more research into what is going on since it breaks the pvr500 so badly. Thanks, Chris On Fri, May 20, 2005 at 11:00:28AM -0400, Jean-Francois Thibert (SageTV) wrote: May I ask why you are going back to the old cx25840? I'd like to hear about any problems it caused...At the very least I think you should keep the adc sets to 3 when disabled and force no_black_magic to 1 (or remove that code since it's doing tda settings inside the cx25840 module) Thanks Jean-Francois Thibert On May 20, 2005 10:24 am, Chris Kennedy wrote: This is the actual fixes there, last version was not the right one. Also please go back and check the cx25840 driver patch and people need to figure out what is wrong there so we can get the improvements from it, but right now it breaks everything quite badly so can't include it till people report success. #0.3.5: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] pvr150/500 long term sound going out, quality
Has anyone seen this, where the pvr150/500 eventually gets bad or loses audio completely, and possibly degrading images. I've seen this and wondering if anyone knows more details so it can be fixed, sounds like possibly something needs to be reset when starting new captures or some tv standard detection is going wrong. Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] #0.3.5 actually fixing pvr500, right release
Here's the tveeprom output... tveeprom: Hauppauge: model = 23552, rev = D492, serial# = 7894833 tveeprom: tuner = Philips FQ1236A MK4 (idx = 92, type = 57) tveeprom: tuner fmt = NTSC(M) (eeprom = 0x08, v4l2 = 0x1000) tveeprom: audio_processor = MSP3410D (type = 5) Thanks, Chris On Fri, May 20, 2005 at 11:45:10AM -0400, Jean-Francois Thibert (SageTV) wrote: What is the tveeprom output? What tuner do they have and are you loading the tda module? NTSC or PAL? Thanks Jean-Francois Thibert On May 20, 2005 11:28 am, Chris Kennedy wrote: The first input doesn't have video, second does. The audio probem happens on both from what I can tell, and here's the lspci -vn output for them... 11:08.0 Class 0400: :0016 (rev 01) Subsystem: 0070:e807 Flags: bus master, medium devsel, latency 64, IRQ 233 Memory at b400 (32-bit, prefetchable) [size=64M] Capabilities: [44] Power Management version 2 11:09.0 Class 0400: :0016 (rev 01) Subsystem: 0070:e817 Flags: bus master, medium devsel, latency 64, IRQ 50 Memory at b800 (32-bit, prefetchable) [size=64M] Capabilities: [44] Power Management version 2 Thanks, Chris On Fri, May 20, 2005 at 11:23:08AM -0400, Jean-Francois Thibert (SageTV) wrote: That's interesting, on which input does this problem happen? Also what model # of pvr500 is it? Thanks Jean-Francois Thibert On May 20, 2005 11:08 am, Chris Kennedy wrote: On a pvr500 it shows no video, and the audio is totally noisy and goes from low pitch to high pitch, just wrecks it basically. So seems it needs some different logic for those, and don't want to break them. If you can make a patch with just those settings I'll test them on the pvr500 and include them, but seems we need some more research into what is going on since it breaks the pvr500 so badly. Thanks, Chris On Fri, May 20, 2005 at 11:00:28AM -0400, Jean-Francois Thibert (SageTV) wrote: May I ask why you are going back to the old cx25840? I'd like to hear about any problems it caused...At the very least I think you should keep the adc sets to 3 when disabled and force no_black_magic to 1 (or remove that code since it's doing tda settings inside the cx25840 module) Thanks Jean-Francois Thibert On May 20, 2005 10:24 am, Chris Kennedy wrote: This is the actual fixes there, last version was not the right one. Also please go back and check the cx25840 driver patch and people need to figure out what is wrong there so we can get the improvements from it, but right now it breaks everything quite badly so can't include it till people report success. #0.3.5: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Fast forward/rewind is broken...
Odd, my Myth setup doesn't do this, and I don't know what it means exactly by 'timed out waiting for free video buffers', very strange since it's nothing to do with the drivers video buffers I would think. Will have to investigate, but is this the newest version of Myth from CVS, since that's what I'm using and seems to not do this. Thanks, Chris On Fri, May 20, 2005 at 06:15:19PM +0200, Morten Rønseth wrote: OK - so at least I'm not the only one! Here's what is output from mythfrontend when it happens: prebuffering pause prebuffering pause prebuffering pause prebuffering pause timed out waiting for free video buffers prebuffering pause prebuffering pause . . . /var/tmp/mythbackend.log shows nothing related. Anyone got a clue whats happening? Is it fixable? Cheers, -Morten Min Idzelis wrote: I've also noticed this problem. I have an Athlon XP 2100, a 160GB Maxtor 6Y160P4, 512 MB RAM, PVR-500 NTSC. Please let me know if you find anything out. Thanks --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- WEB-fx http://www.webfx.no Morten Lerskau Rønseth mailto:[EMAIL PROTECTED] Odinsvei 15c +47 6680 9191 1413 Tårnåsen+47 9343 4357 Norway --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] #0.3.4z pvr500 broken/fixed, vbi raw changes
It's very likely version t, that's where the pvr500 cards broke, then more on past that too. Thanks, Chris On Fri, May 20, 2005 at 12:15:30PM +0200, Michel Verbraak wrote: The latest two versions y and z do not work for my PVR-150 (PAL non MCE) The driver loads fine but the tuner does not tune to the specified channel. I only get static. The latest working version for me is p. If needed I can test the versions between p and y to see where the bug shows up. Regards Michel Verbraak. Chris Kennedy wrote: I have replaced the cx25840-driver.c file with the one from 3.4s since the pvr500 broke around that time, also some fixes to make raw vbi not miss characters, seems to work, needs testing. #0.3.4z: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.4x misc audio fixes for pvr150/500, vbi size change
This included the recent sugested audio changes in cx25840, also has an change to the VBI line size to fix PAL. #0.3.4y: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Patch for internal connector on PVR150
Sounds great to me. Thanks, Chris On Thu, May 19, 2005 at 07:07:25AM -0400, Bryan Mayland wrote: Daniel Hyams wrote: I can't seem to figure out exactly how the ivtv_reset_ir_gpio routine is called, ever. Is there some magic that I need to do with ivtvctl at the command line to trigger this one? Yeah, the patch only added the ability to reset it, not to automatically reset it (since I don't think the driver actually knows when it goes bad). To actually do the reset, you need to call the ioctl with something like: fd = open(/dev/video, O_RDWR); ioctl(fd, IVTV_IOC_RESET_IR, null); close(fd); I can submit a patch to either ivtvctl or cx28540ctl to add this function if Chris says it is ok. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] YUV decoding fun games
I'm also wondering about an oddity I'm seeing where when using the /dev/video48 device, video looks like we are missing frames, it's jerky on playback. It didn't do this originally when I first was getting it to work, suspect we need to possibly really program all the buffer registers to make it work smooth, although I think I didn't have to do that, something seems wrong (not sure if the ioctl is doing this, suspect it isn't). Also the ghosting image over the top of playback, never happened originally, was perfect pictures, now it's doing that, I don't know, maybe again the buffers needing to be all programmed or something. So that's my current thing I'm seeing and trying to figure out, can't see where the code changed enough to switch behavior, but hard to tell since YUV decoding is just tricky and still setup/teardown is so hackish. Thanks, Chris On Wed, May 18, 2005 at 01:50:31PM +0100, Matthew Hodgson wrote: So, I decided to give John Harvey's exciting YUV decoding patch a go on 0.3.4p - and so far it's all working fairly well :) I've had a few problems, though, which I thought I'd share: a) I'm feeding the decoder 25fps progressive PAL video to /dev/video48. However, the YUV decoder renders both fields of each frame using only the odd field's buffer (i.e. lines 1,3,5.. counting from the topmost line being 1). This obviously halves the vertical resolution of the luminance, which makes the visual quality considerably worse than the OSD - especially noticeable on aliasing artefacts in animation. This occurs after initialiasing the MPEG decoder with a typical MPEG2 recording sent to /dev/video0. b) For the first time after being initialised with a bit of MPEG stream, the YUV decoder works otherwise fine - but after another MPEG stream is decoded YUV decoding subsequently only displays a black screen until the next module/firmware reload. The IVTV_IOC_PREP_FRAME_YUV returns without errors, however, and the kernel log debugging at ivtv_debug=63 reads the same before after. c) If you initialise with half-resolution MPEG-1 content, the YUV stream is also displayed at the same scale, so you only see the top-left quadrant of the screen. Any ideas on how to get both YUV fields displayed by the decoder, or confirmation of these problems with other people's setups would be of great interest :) M. --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] #0.3.4v fixes to VBI raw missing characters, insertion Myth clash
Try to change the RAW_SIZE to 1444 on w and see if it fixes it, I'm really curious about that, need to know if that works on it still, just changing that. Thanks, Chris On Wed, May 18, 2005 at 11:19:06PM +0200, Simon Zwahlen wrote: Hi Chris, Also does some major overhauls of VBI size, seems to have fixed the missing characters in raw mode, please test. This one breaks raw vbi for my PVR-350. The bitrate of TXT is about 17k (normal: ~200k), and I receive no EPG at all. I'm using 0.3.4u now, with SAA7115_VBI_RAW_SIZE 1444 instead of 1443 + 13, which is still working best for me. I also tried 0.3.4w, without success. Let me know if you need more information. Regards, Simon --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.4x fixes VBI line size, less buffer size for raw VBI, pvr150 reg
This hopefully fixes VBI for PAL, changes the line size back, seems to still do VBI well without missing characters in raw mode too. Also now VBI no longer takes as big of buffers for raw mode, or sliced, since it can split it up because I do the parsing different. Also commented out the register default setup for the pvr150 that was added with the last patch till a better solution is found and to test that and see if it's causing the problems there, also need to look at all the recent discoveries that, a patch including them all would be niced :-), but I will have to look at that closer, things are working great on my pvr150 here, even with the register thing. #0.3.4x: http://www.ivtv.tv/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.4x fixes VBI line size, less buffer size for raw VBI, pvr150 reg
I just re-uploaded this, had a nasty raw VBI bug that I just fixed. Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
[ivtv-devel] #0.3.4u vbi insertion and display improvements
This makes vbi output to the saa7127 yet more correct, and may help timing and vsync things like YUV decoder output too. Please test the VBI and report the results, also I have setup two modes of embedding more than before, 2 gets insertion of User Data packets, and 3 gets private packets, done by the firmware. The User Data packets don't disrupt the video but are not able to be decoded yet, while the private packets corrupt the mpeg video badly. This is there to further that development since the way we do vbi re-insertion requires parsing just about every byte of the mpeg stream (hence the jittery video when using Myth for some, it's CPU intensive and just inefficient, but best way we can for now). #0.3.4u: http://www.ivtv.tv/data/releases/ivtv-0.3/ Thanks, Chris -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
Re: [ivtv-devel] Patch for internal connector on PVR150
Also I'm concerned because this patch goes though again and sets all the registers to the defaults, which may not be correct as we saw in the past? Not sure, maybe good, but something to point out and see how it works for everyone. Thanks, Chris On Tue, May 17, 2005 at 03:07:24PM -0400, Tyler Trafford wrote: I'm of the opinion that black magic code should be removed. It seems as though, as the driver now exists, it either breaks things badly, or does nothing. -Tyler Per Jönsson [EMAIL PROTECTED] wrote: I just noticed that this patch sets no_black_magic to 1 by default. Any particular reason for that? Per -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Jean-Francois Thibert (SageTV) Sent: den 16 maj 2005 19:33 To: ivtv-devel@lists.sourceforge.net Subject: [ivtv-devel] Patch for internal connector on PVR150 This patch adds support for the PVR150 internal connector and exposes the 4 choices of inputs from the wm8775. Jean-Francois Thibert --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_id=7412alloc_id=16344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- Tyler Trafford --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel -- --- Chris Kennedy / [EMAIL PROTECTED] Engineer KMOS-TV/KTBG-FM Broadcasting Services Department Central Missouri State University --- This SF.Net email is sponsored by Oracle Space Sweepstakes Want to be the first software developer in space? Enter now for the Oracle Space Sweepstakes! http://ads.osdn.com/?ad_idt12alloc_id344op=click ___ ivtv-devel mailing list ivtv-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ivtv-devel
