Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> HD-2000/3000 drivers -> Athlon64 and QAM driver issues Goto page Previous  1, 2
Post new topic  This topic is locked: you cannot edit posts or make replies. View previous topic :: View next topic 
PostPosted: Mon Feb 20, 2006 3:59 pm Reply with quote
christiaan
 
Joined: 20 Feb 2006
Posts: 3




pridkett wrote:
pcHDTV_tech wrote:
Just a thought or two:

Since the signal level drops and corruption happens when you watch and record at the same time on the same machine, it could be that your power supply is marginal and the increase in activity (video card, disk access, etc.) is actually dropping the voltage on the PCI bus.

EMI could be an issue, but I'm doubtful that would show up as decreased signal levels. A voltage drop on the bus could result in data errors in the received stream.

HTH,

Rusty


I never thought about the power supply issues. Know of a way I can check to see what the voltage is on the PCI bus while it's running (short of cracking open the case and plugging a multimeter into some wires). I've got a reasonably good Antec powersupply (part of Antec Overture II), so I'm doubtful that's the problem, but it could explain it. Also, it could just be a result of QAM related issues, at it seems other people are experiencing similar problems, as shown in this thread.

I'd like to try antenna, but even though I'm close to the towers, the hills in Pittsburgh make this rather difficul. I suppose I could just climb on the roof though. Anecdotal evidence on the MythTV-Users list, suggests it may be QAM related though


You know, I'm currently troubleshooting a similar issue. I notice that having X running, and more specifically video throughput in X causes problems for me. A simple test for me was to use a program I created called "dvbrecord". Without X running (nvidia driver), I can record flawlessly. As soon as X starts up and I interact with an Xterm for example, I start getting errors (PAT/PMT corruption, transport_error_indicator problems). This all started after I started using my new AMD Opteron board.
View user's profile Send private message
PostPosted: Thu Mar 09, 2006 2:01 am Reply with quote
pfile
 
Joined: 06 Aug 2004
Posts: 80




christiaan wrote:
pridkett wrote:
pcHDTV_tech wrote:
Just a thought or two:

Since the signal level drops and corruption happens when you watch and record at the same time on the same machine, it could be that your power supply is marginal and the increase in activity (video card, disk access, etc.) is actually dropping the voltage on the PCI bus.

EMI could be an issue, but I'm doubtful that would show up as decreased signal levels. A voltage drop on the bus could result in data errors in the received stream.

HTH,

Rusty





I never thought about the power supply issues. Know of a way I can check to see what the voltage is on the PCI bus while it's running (short of cracking open the case and plugging a multimeter into some wires). I've got a reasonably good Antec powersupply (part of Antec Overture II), so I'm doubtful that's the problem, but it could explain it. Also, it could just be a result of QAM related issues, at it seems other people are experiencing similar problems, as shown in this thread.

I'd like to try antenna, but even though I'm close to the towers, the hills in Pittsburgh make this rather difficul. I suppose I could just climb on the roof though. Anecdotal evidence on the MythTV-Users list, suggests it may be QAM related though


You know, I'm currently troubleshooting a similar issue. I notice that having X running, and more specifically video throughput in X causes problems for me. A simple test for me was to use a program I created called "dvbrecord". Without X running (nvidia driver), I can record flawlessly. As soon as X starts up and I interact with an Xterm for example, I start getting errors (PAT/PMT corruption, transport_error_indicator problems). This all started after I started using my new AMD Opteron board.


one thing to try: make sure your chassis grounding is tight. that is, make sure the faceplace of the HD3000 card fits tightly against the back panel, and if not, go get some EMI gasketing material or copper tape and tape it up.

a friend of mine had similar issues until he straightened out his chassis grounding...
View user's profile Send private message
Re: Did you ever find a solution?
PostPosted: Thu Apr 27, 2006 11:23 pm Reply with quote
patman
 
Joined: 30 Mar 2006
Posts: 8
Location: Portland, OR




myrkle wrote:
I am having the same problems, and I too have an Antec Overture II. I begin to wonder whether the power supply is indeed the issue. Did you ever wind up solving your problems?

Has anyone had any luck using the Antec Overture II and its powersupply with the HD-3000?


Per this thread, I replaced my smartpower 2.0 250w with an HE 500, and QAM tuning is now working.

-- Patrick
View user's profile Send private message Visit poster's website
Re: Did you ever find a solution?
PostPosted: Fri Apr 28, 2006 12:29 am Reply with quote
kmj0577
 
Joined: 03 Jan 2006
Posts: 57




patman wrote:
myrkle wrote:
I am having the same problems, and I too have an Antec Overture II. I begin to wonder whether the power supply is indeed the issue. Did you ever wind up solving your problems?

Has anyone had any luck using the Antec Overture II and its powersupply with the HD-3000?


Per this thread, I replaced my smartpower 2.0 250w with an HE 500, and QAM tuning is now working.

-- Patrick

Interesting, I'm having trouble with my QAM tuning and I had replaced my power supply with a new one and now mine is garbled. I may try popping in the old one for a test run and then again it may be my cable (sometimes the digital cable channels will freeze up on the video, but I just get a garbled blocked up video on QAM with the HD-3000. Although I didn't before, so I don't know if it's my cable or my computer). Anyone have any conjectures as to why a power supply would cause this though?

Edit: Now it seems pointless for me to even try since TNTHD and Discovery HD have been made subscription channels and are no longer clear to air, so I couldn't pick those up now if i wanted to. I'll be moving in the fall to a place where I don't think I'd get any HDTV OTA though, so I'll have to try QAM once again. Although possibly I might try because one digital station is VHF still and I get an occassional glitch OTA and hopefully not get that on cable.

Edit2: Didn't seem to work. I'll post back the results in a few months when I'm on my new cable. I'm actually too lazy to get this fixed since I get the same stuff OTA that I get on cable now.
View user's profile Send private message
PostPosted: Mon May 22, 2006 1:32 am Reply with quote
tear
 
Joined: 24 Apr 2006
Posts: 2




Hey,

It seems I'm hitting the same thing here, x86-64 kernel gets corrupted data
x86 does not. Well with one slight difference, x86-64 kernel did have
nvidia module loaded at the time of testing. I'll try recording ts without it.

Anyway...

I actually managed to record same transport stream using both hardware
exhibiting and not exhibiting the problem so one can actually see corruption
patterns.

I didn't have time to do the analysis though. I can put those streams
(synced) up onto some site, if anyone's interested.

Still, if this has already been resolved, let know and sorry for the noise..

Cheers,
tear
View user's profile Send private message
More followup
PostPosted: Sun Aug 13, 2006 11:17 am Reply with quote
pridkett
 
Joined: 22 Oct 2005
Posts: 13




So, I decided to poke around some more. It still looks like I'm getting weird errors while there is activity at the same time as recording, either watching it, or basically anything else. However, I did notice some messages in my kernel dmesg:

Code:
[17182194.948000] or51132: Version: 10001334-17430000 (133-4-174-3)
[17182194.972000] or51132: Firmware upload complete.
[17182195.008000] cx88[0]/2: cx8802_timeout
[17182195.008000] cx88[0]/2: cx8802_stop_dma
[17182195.008000] cx88[0]/2: restarting queue
[17182195.008000] cx88[0]/2: cx8802_restart_queue
[17182195.008000] cx88[0]/2: cx8802_restart_queue: queue is empty
[17182195.008000] cx88[0]/2: queue is empty - first active
[17182195.008000] cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
[17182195.008000] cx88[0]/2: setting the interrupt mask
[17182195.008000] cx88[0]/2: [f4817d80/0] cx8802_buf_queue - first active
[17182200.144000] cx88[0]/2: cx8802_restart_queue
[17182200.144000] cx88[0]/2: cx8802_restart_queue: queue is empty
[17182614.952000] cx88[0]/2: queue is empty - first active
[17182614.952000] cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
[17182614.952000] cx88[0]/2: setting the interrupt mask
[17182614.952000] cx88[0]/2: [f4817840/0] cx8802_buf_queue - first active
[17182615.948000] cx88[0]/2: cx8802_restart_queue
[17182615.948000] cx88[0]/2: cx8802_restart_queue: queue is empty
[17182615.952000] cx88[0]/2: queue is empty - first active
[17182615.952000] cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
[17182615.952000] cx88[0]/2: setting the interrupt mask
[17182615.952000] cx88[0]/2: [dc0c9d40/0] cx8802_buf_queue - first active
[17182616.284000] cx88[0]/2: cx8802_restart_queue
[17182616.284000] cx88[0]/2: cx8802_restart_queue: queue is empty
[17182616.312000] cx88[0]/2: queue is empty - first active
[17182616.312000] cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
[17182616.312000] cx88[0]/2: setting the interrupt mask
[17182616.312000] cx88[0]/2: [da90a780/0] cx8802_buf_queue - first active
[17182635.640000] cx88[0]/2: cx8802_restart_queue
[17182635.640000] cx88[0]/2: cx8802_restart_queue: queue is empty
[17182638.188000] cx88[0]/2: queue is empty - first active
[17182638.188000] cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
[17182638.188000] cx88[0]/2: setting the interrupt mask
[17182638.188000] cx88[0]/2: [e0d82c00/0] cx8802_buf_queue - first active
[17182638.608000] cx88[0]/2: cx8802_restart_queue
[17182638.608000] cx88[0]/2: cx8802_restart_queue: queue is empty
[17182638.616000] cx88[0]/2: queue is empty - first active
[17182638.616000] cx88[0]/2: cx8802_start_dma w: 0, h: 0, f: 2
[17182638.616000] cx88[0]/2: setting the interrupt mask
[17182638.616000] cx88[0]/2: [f62c4140/0] cx8802_buf_queue - first active
[17182773.276000] cx88[0]/2: cx8802_restart_queue
[17182773.276000] cx88[0]/2: cx8802_restart_queue: queue is empty


These messagse popped up while I was watching the program in MythTV. It looks like it's having some weird errors going on. Any help here?

For reference, the kernel is 2.6.15-26 (Ubuntu Dapper), the processor is an AMD Athlon 64x2 4400+, and the motherboard is an MSI K8N-Neo4 Platinum in an Antec Overture 2 case. So replacing the power supply is not an easy option...stupid proprietary power supplies. I get errors with both 386 and x86_64 kernels. And as a reminder, this machine is certainly HD capable, my HD firewire box works just fine.
View user's profile Send private message
It was the power supply
PostPosted: Wed Aug 16, 2006 12:57 pm Reply with quote
pridkett
 
Joined: 22 Oct 2005
Posts: 13




So it really looks like the problem was the power supply after all. I narrowed it down to the one component of the system I hadn't checked out. The stock powersupply with the Anter Overture II couldn't cut it, but it appears a new Antec NeoHE 550W power supply has no problem. I just tested recording of 2xpcHDTV HD-3000, HD from a Motorola DCT-6200, SD from a WinTV PVR-250, transcoding some HD, having MythTV play some HD, and playing Quake 4 all at the same time. Only problem was that Quake 4 was a little slow.
View user's profile Send private message
Athlon64 and QAM driver issues
  pcHDTV Forum Index -> HD-2000/3000 drivers
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
All times are GMT - 7 Hours  
Page 2 of 2  
Goto page Previous  1, 2
  
  
 Post new topic  This topic is locked: you cannot edit posts or make replies.  


Powered by phpBB © 2001-2003 phpBB Group
Theme created by Vjacheslav Trushkin