Scott, Can you mention what hw you have? Gees, don't keep us in the dark man!
On 6/6/05, Scott Harris <[EMAIL PROTECTED]> wrote:
> This is BY FAR the best I've seen it. Not only is my video awesome in live
> TV and recordings, it is superb in dvd and ripped dvd playback. As an added
> benefit t
This is BY FAR the best I've seen it. Not only is my video awesome in live
TV and recordings, it is superb in dvd and ripped dvd playback. As an added
benefit the audio seems far much better as well. Before it seemed to only
be mono, but now there is definite stereo.
Thanks everyone!
--
This adds a new module option called ivtv_dynbuf which allows the
dynamic buffer allocation to easily be turned off with ivtv_dynbuf=0 as
a module option to ivtv. I don't think that is needed though, because I
reduced the decoder buffer size/ osd buffer size, and also found a bug
when the bu
Actually try 0.3.6d, and don't change anything, I hopefully fixed this
so it won't be needed, although if still a problem, there's a new module
parameter ivtv_dynbuf which you can set to '0' and turn that off (plus
fixed a bug which I think made things crash when dynamic buffer
allocation fai
On Jun 6, 2005, at 9:37 PM, ivtv wrote:
Try changing the DYNAMIC buffer define in ivtv-driver.h to 0, just
search for DYNAMIC and you'll find it in there, it seems dynamic
memory allocation is failing in heavy usage situations and things
aren't coping very well.
Thanks,
Chris
mrwester wrot
Try changing the DYNAMIC buffer define in ivtv-driver.h to 0, just
search for DYNAMIC and you'll find it in there, it seems dynamic memory
allocation is failing in heavy usage situations and things aren't coping
very well.
Thanks,
Chris
mrwester wrote:
Hi-
I've got a 350 and 500mce in same
Hi-
I've got a 350 and 500mce in same box with a via KT400 based mobo. I
can capture all 3 tuners at same time, generally no probem, but I get
occasional lock ups, sometimes during playback on 350 tv-out, just
watching, sometimes associated with commercial skip activity. Often
the box is hard fr
Brian Litzinger wrote:
On Sun, Jun 05, 2005 at 09:36:29PM -0500, ckennedy wrote:
Harry Orenstein wrote:
How new? Could you post MD5 sums or some other indication of the versions
you want people to try? Probably would be best to compare apples to
apples.
It's version 2.05.
This contains the recent patches for scaling and vblank fixes...
#0.3.6c: http://www.ivtv.tv/releases/ivtv-0.3/
Thanks,
Chris
--
===
Chris Kennedy
[EMAIL PROTECTED]
---
This SF.Net email is sponsored by: NEC IT Guy Games. How far can you s
The driver doesn't know which type of card you have, as you have
mentioned. You can either try the latest 0.3 development version, or I
believe you can force the card type by adding:
options ivtv cardtype=1
to your modprobe.conf
mythtv wrote:
Just done a fresh install of FC3 and followed t
Anyone else out there with a PVR150MCE (Pal, LG TAPE tuner type 58)
who lost audio somewhere around 0.3.5?
I can get audio when I specify tda9887 qss=0 module option but with a
clicking sound on most of the channels (some are strangely enough
good).
Sample capture: http://users.skynet.be/nickshome/
Just done a fresh install of FC3 and followed the instructions from Jarod
Wilson's site.
Using ivtv 1:0.2.0-68_rc3j.rhfc3.at
The card is definitely a Hauppauge PVR 250
When I try a capture I get zero byte files.
What might be wrong.
Many many thanks
Dave
Jun 6 20:04:32 mythtv kernel: i
unsubscribe
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Dan H Orlic
Sent: Monday, June 06, 2005 2:29 PM
To: ivtv-devel@lists.sourceforge.net
Subject: [ivtv-devel] pvr-150 video issues
Ok, I feel that I am so close and yet so far away
I have th
Ok, I feel that I am so close and yet so far away
I have the pvr-150 that auto detects tuner 47 however when i allow the
tuner to be 47 it is pure static... however when i switch it to either
55 or 51... I get an almost good picture and perfect sound. Does this
make any sense?
how do i fi
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 o
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.
ckennedy wrote:
ivtv: Encoder revision: 0x02050032
In addition to the pvr_2.0.24.23035.zip version, this is also
available from:
http://hauppauge.lightpath.net/software/pvr150/pvr150_inf.zip
Although they are of different sizes (and subsequently have different
md5sums), the first 256k a
Great,
I also have perfect sound and picture now with this patch.
PAL PVR-350 and PVR-500 combination. I also upgraded the firmware.
Thanks everybody for the good work.
Tor Arne
On Mon, 2005-06-06 at 20:54 +0200, Ulrich Mayer wrote:
> This patch fixes the picture quality probem with 0.3.6b fo
Brian Litzinger wrote:
On Sun, Jun 05, 2005 at 09:36:29PM -0500, ckennedy wrote:
Harry Orenstein wrote:
How new? Could you post MD5 sums or some other indication of the versions
you want people to try? Probably would be best to compare apples to
apples.
It's version 2.05.
Ulrich Mayer wrote:
0.3.6b gives me really bad picture quality. False colors, basically
b&w and ~30° blue and red stripes moving, (dis)appearing, quite
unsteady - for all inputs, tuner, composite, and svideo
Yeah, I really F-ed up PAL and SECAM in 0.3.6b by modifying the
"Chroma subcarrie
This patch fixes the picture quality probem with 0.3.6b for me. Please
ignore my comment on that in the thread on composite and s-video audio.
Uli
Bryan Mayland wrote:
Make that two typos.
Bryan Mayland wrote:
Dammit, I'm really bad with the typos. Register 0x047d, 0x047e,
what's t
Bryan Mayland wrote:
[...]
Picture quality for composite is also good, s-video is b&w.
If you go to cx24850-driver.c around line 723, for the SX25840_SVIDEO
case, if you change
CX25840_SET_PWR_DN_CH3(0x01);
to set it 0x00, do you get color on the svideo input? If not, did you
have colo
ckennedy <[EMAIL PROTECTED]> writes:
> It's version 2.05.32 or greater, I think that's the newest version
> though. It's included on
> every new pvr150/500 CDROM, basically the newest one available on the
> shpvr website
> from the wiki page for firmware. It reports this line in the driver...
Make that two typos.
Bryan Mayland wrote:
Dammit, I'm really bad with the typos. Register 0x047d, 0x047e,
what's the difference?
Try this patch.
Sigurd Nes wrote:
The video got worse with 0.3.6.b than with 0.3.6.a
--- driver/cx25840-driver.c.orig2005-06-06 13:50:50.381904848 -0400
Dammit, I'm really bad with the typos. Register 0x047d, 0x047e, what's
the difference?
Try this patch.
Sigurd Nes wrote:
The video got worse with 0.3.6.b than with 0.3.6.a
--- driver/cx25840-driver.c.orig2005-06-06 13:50:50.381904848 -0400
+++ driver/cx25840-driver.c 2005-06-06 1
The video got worse with 0.3.6.b than with 0.3.6.a
Regards
Sigurd
---
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
Tyler Trafford wrote:
> I went with the least complicated way of doing this that didn't
> involve a floating point calculation- for NTSC I add 7 (480 = 487
> lines), for anything else I add 4 (576 = 580 lines). Certainly not
> anything precise, but it shouldn't cause any problems.
Actually, this
[Resending, since the attachments made it too big. I've replaced
one of the attachments with a URL. Also forgot to mention that
I'm running Matt Zimmerman's deb's for myth 0.18.]
I've just tried version 0.3.5z of the ivtv driver, which is the latest
one I found on the website, along with a versi
This is a short fix to the scaling code... Pretty self explanatory.
It just takes into account the chip thinks of height in terms of
lines, while we request a resolution based on pixels, so some
conversion has to be made.
I went with the least complicated way of doing this that didn't
involve a
On Monday 06 June 2005 04:35 am, ckennedy wrote:
> Louie Ilievski wrote:
> >I think this is some kind of joke or something. Not at all consistent
> > with every single other email I've seen from Chris as far as signature,
> > email address, etc.
> >
> :) nah, just using my new/old email address wh
Chris Kennedy wrote:
Merging them would be fine, or separate, either one works, I'll wait
for both till I include them so either way.
I've attached the merged version.
Have I mentioned how easy you make it to work on this project? So many
other open source projects I've got to chase revis
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
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
Great video and sound on all tuners.
pvr350 + pvr500mce
ivtv-0.3.6a
Encoder revision: 0x02050032
PAL
Regards
Sigurd
ivtv wrote:
I have been experimenting and have found that the newest firmware is
working ok during my tests now, it seems we have possibly gotten the
driver to the point of work
Tyler Trafford wrote:
That should also be changed in "DECODER_GET_STATUS:".
Right you are. New patch supersedes previous.
Index: driver/cx25840-driver.c
===
--- driver/cx25840-driver.c (revision 287)
+++ driver/cx25840-driv
Bryan Mayland wrote:
> I was going to change the FIXME in cx25840-driver.c, when I realized
> that it was using completely whacked constants when checking the return
> value of AFD_FMT_STAT. AFD_FMT_STAT is 4 bits, so even the first PAL
> entry is out of bounds, and only NTSC-M uses the right valu
I was going to change the FIXME in cx25840-driver.c, when I realized
that it was using completely whacked constants when checking the return
value of AFD_FMT_STAT. AFD_FMT_STAT is 4 bits, so even the first PAL
entry is out of bounds, and only NTSC-M uses the right value. This
patch fixes up b
I don't know what I was thinking when I wrote this, but the doioctl() I
added in a previous patch will write failure messages to stderr even
though the decription of the ioctl it went to stdout. This patch fixes
that so you won't see:
failed: Invalid argument
ioctl IVTV_IOC_S_VBI_EMBED [EMAIL
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
---
Louie Ilievski wrote:
I think this is some kind of joke or something. Not at all consistent with
every single other email I've seen from Chris as far as signature, email
address, etc.
:) nah, just using my new/old email address which isn't work related,
parting from my kmos.org email ad
Per Jönsson wrote:
Hi,
Help me understand something.
In ivtv-firmware.c, there is a check that the firmware size isn't greater
than IVTV_FIRM_IMAGE_SIZE, which is defined as 256*1024 = 262144 bytes.
However, HcwFalcn.rom in the zip file you refer to is 376836 bytes.
Wouldn't that result i
On Sunday 15 May 2005 23:26, John Harvey wrote:
> Here's the binary xdriver v0.10.
> It is built against XFree86 4.3 so should be usable by most people.
>
> Any more problems please continue to let me know.
>
> John
Hi John,
So far I've only been able to find the sources for the 0.9 version of yo
On Monday 06 June 2005 04:36, ckennedy wrote:
> ivtv: Encoder revision: 0x02050032
> ftp://ftp.shspvr.com/download/wintv-pvr_150-500/inf/pvr_2.0.24.23035.zip
>
> Unzip that file and inside you'll see HcwFalcn.rom file, which you'll
> want to move to /lib/modules/ivtv-fw-enc.bin
>
> Thanks,
> Chris
Hi,
Help me understand something.
In ivtv-firmware.c, there is a check that the firmware size isn't greater
than IVTV_FIRM_IMAGE_SIZE, which is defined as 256*1024 = 262144 bytes.
However, HcwFalcn.rom in the zip file you refer to is 376836 bytes.
Wouldn't that result in an error when loading
On 6/6/05, Louie Ilievski <[EMAIL PROTECTED]> wrote:
> I think this is some kind of joke or something. Not at all consistent with
> every single other email I've seen from Chris as far as signature, email
> address, etc.
http://whois.net/whois.cgi2?d=groovy.org
-
Your X configuration is broken.
The log file is (usually) saved in /var/log/Xorg.0.log
(0 is replaced with the screen number if you have
multiple X screens).
If you post that log file (or send it to me directly )
and also your Xorg configuration file we can probably
work out what is wrong.
John
--
46 matches
Mail list logo
