For grins, I expanded on the same theme to set the values for 0x474,
0x475, 0x476, and 0x477 to the defaults listed in the datasheet
appropriate for the required video mode. I did this against an old
version of the driver, so there's no sense patchifying it, but this is
what it looks like:
i
This allows one to force input init of the pvr150/500 digitizer,and does so
each capture right before start capture, even if it isn't the first and only
capture running, so when running vbi for instance long-term and start/stop
mpeg captures, this will re-initialize the input each time.
Also con
Greetings,
I'm trying to get a dual-tuner system going.
Everything works if I have either the PVR 350 or the
150 in the box by themselves. But if I put in the
second card, the 350 works fine and the 150 appears to
be recognized by ivtv, but captures from it are empty
files.
The 350 is recogni
On Fri, May 27, 2005 at 10:36:05PM +0200, Martin Barnasconi wrote:
> > Thanks for the info. Unfortunately, I'm currently running a much
> > earlier version of ivtv (0.19, I think). Correct me if I'm wrong, but
> > I don't think that that version embeds CC info.
>
> Guess not...
>
> > Maybe this i
> Thanks for the info. Unfortunately, I'm currently running a much
> earlier version of ivtv (0.19, I think). Correct me if I'm wrong, but
> I don't think that that version embeds CC info.
Guess not...
> Maybe this is a naive question, but is the CC data that is gathered by
> ivtv just plain text
For what it's worth I didn't have any audio issues in 0.3.5h but that's
most likely because I'm not using tda9887. My guess is there's some
signal crossing between the radio and tv tuners. I'll try enabling
tda9887 when I get back from vacation on the 7th and I'll let you know
if I have the s
Just tried 0.3.5k. So far no DMA errors. To get audio I need to add
qss=0 to the tda9887 options. Audio quality depends on the channel and
ranges from pretty good, to acceptable (light crackling, ticks) to bad
(constant humming).
On YUV-playback I get these:
ivtv: pci_map_sg dma->page_count 154 dm
Bryan Mayland wrote:
> Before that I don't see any occurance of anything similar. I'd like to
> thank whoever it is that has the SVN repository, without which this
> would have been a pain to track. That you Tyler Trafford?
Yeah, that's mine (assuming you mean the one at relyt.dyndns.org). I
f
Chris Kennedy wrote:
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.
Tha
I am using PVR-150 with Mythtv.
with version 0.3.5j
Tuner 0 works great.
Svideo input 0 has strange ghost images in it.
Svideo input 1 has strange ghost images and no color.
Both seem to use the same audio.
with version 0.3.5f
Svideo 0 and 1 video are great , but Audio studders bad.
Any advise?
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 Departm
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 2
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
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
Hi all,
I'm working on getting a PVR250 setup - I'm running into a situation
where if I compile a new kernel to get working cx88 drivers, my bttv
stops working -
Using FC3 on a custombuilt 2.6.11 kernel -
After kernel compile, the cx driver loads but bttv fails -
If I grab the source for video4
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
Long time user of 0.3.2l driver, I've tried a (too big?) jump to
0.3.5f on my mythtv box.
This didn't work out. Image was pausing for long times and getting
delayed (like taking 1s to display 10s), sound holes, etc...
I will try again with random versions in between and/or update with
newer relea
William Powers wrote:
I have gained a greater understanding of the audio problem in versions
since (at least) 0.3.4p, referred to here:
http://www.gossamer-threads.com/lists/ivtv/devel/20342?#20342
and here:
http://www.gossamer-threads.com/lists/ivtv/devel/20678?#20678
The audio recording f
Nick,
Are you still getting these?
Nick Rosier wrote:
Chris,
drivers seem to be getting worse for me. The best for me so far is still 0.3.4s.
Problems I encounter with this one:
- no audio on my 150MCE (PAL, tuner 58), started with 0.3.4w
- live-tv in myth hangs after a couple of seconds, I
What are your module-options? Make sure you don't have duplicate
modules (like tuner, tveeprom).
N.
On 5/27/05, Marcel Pol <[EMAIL PROTECTED]> wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
>
> Hello,
> Some time ago I bought an ivtv based card, but couldn't get it to work.
> Now I'
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Hello,
Some time ago I bought an ivtv based card, but couldn't get it to work.
Now I'm willing to put in some time, and see if I can get it to work.
Problem is, it's not doing anything, no video or audio, it's just dead
as a rock.
I have pasted the d
On 5/27/05, William Powers <[EMAIL PROTECTED]> wrote:
> I have gained a greater understanding of the audio problem in versions
> since (at least) 0.3.4p, referred to here:
>
> http://www.gossamer-threads.com/lists/ivtv/devel/20342?#20342
>
> and here:
>
> http://www.gossamer-threads.com/lists/iv
I have gained a greater understanding of the audio problem in versions
since (at least) 0.3.4p, referred to here:
http://www.gossamer-threads.com/lists/ivtv/devel/20342?#20342
and here:
http://www.gossamer-threads.com/lists/ivtv/devel/20678?#20678
The audio recording from a PVR-500 is being s
I'm resending this gzipped since my patch was 28k and the list max is
20k. Sorry about that!
This patch is just some silly stuff. I've reordered the usage() output
so it is in alphabetic order by short option letter (I put the uppercase
before the lowercase when equal so they follow a get/set
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/KT
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,
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?
Also, did you see my post yesterday about what are those cx25840_write()
27 matches
Mail list logo
