Log in Register FAQ Memberlist Search pcHDTV Forum Index
pcHDTV Forum

pcHDTV Forum Index -> General pcHDTV topics -> HD-3000 locks up every couple days or so
Post new topic  Reply to topic View previous topic :: View next topic 
HD-3000 locks up every couple days or so
PostPosted: Sun Oct 22, 2006 8:37 pm Reply with quote
toups
 
Joined: 10 Mar 2006
Posts: 18




Running a HD-3000 with MythTV 0.20. Every few days, the card is unable to tune in any stations. MythTV reports a signal strength of 100% and no lock on all channels. If I stop the back end do a "rmmod cx88_dvb" followed by a "modprobe cx88_dvb" then restart the back end then everyting is fine for a day, or two, maybe more. Any suggestions for debugging?

Kernel is 2.6.17-gentoo-r8

Thanks.
View user's profile Send private message
PostPosted: Mon Oct 23, 2006 6:25 am Reply with quote
waterhead
 
Joined: 24 Apr 2005
Posts: 299




Have you checked the log for any info? In Fedora mine is located at /var/log/mythbackend.log. Also try running the frontend and backend from a shell and inable verbose reporting like this:
Code:
 >mythbackend -v all


It may give some clues as to why it freezes up. There are other tags that can be added to -v instead of all. For an explanation, type in:
Code:
mythbackend -v help


Paul

_________________
Mythbuntu 8.04
Intel D875PBZ main board
Pentium4 3.06Ghz
1024GB RAM
nVidia 6600GT
pcHDTV HD-3000
Air2PC PCI
MythTV 0.21
View user's profile Send private message
PostPosted: Mon Oct 23, 2006 6:32 pm Reply with quote
toups
 
Joined: 10 Mar 2006
Posts: 18




Thanks for the reminder, had had various logging options in the past but never found the issue. I need to turn full logging back on and try again.
View user's profile Send private message
Me too!
PostPosted: Mon Dec 04, 2006 6:05 pm Reply with quote
Steve-o
 
Joined: 04 Dec 2006
Posts: 3




I've been getting the same lockups using 64-bit Gentoo running Gnome 2.14. Kernel v is 2.6.18. So far I have been unable to spot the issue in my logs. Did you ever spot the issue in your system?

_________________
For every complex problem, there is a solution: simple, straightforward, and invariably wrong.
H.L. Mencken
View user's profile Send private message
PostPosted: Wed Dec 06, 2006 10:16 pm Reply with quote
toups
 
Joined: 10 Mar 2006
Posts: 18




No, never saw anything in the log.

I haven't been using it much lately so I can't say whether the problem is still there or not.
View user's profile Send private message
PostPosted: Mon Dec 11, 2006 2:52 pm Reply with quote
deeek
 
Joined: 11 Dec 2006
Posts: 1




I get something similar to this as well. After a few days, reading from the card device file it returns a bunch of giberish instead of an MPEG2 file. It use to not do this. I hope my card is fine.
View user's profile Send private message
debug cx88-dvb
PostPosted: Wed Dec 13, 2006 6:02 pm Reply with quote
Steve-o
 
Joined: 04 Dec 2006
Posts: 3




I tried to add the following line in /etc/modules.conf to help find the issue:
Code:
options  cx88-dvb  debug


modprobe rejects this syntax. Anyone know how to start this module in debug mode?

Thanks.

Steve

_________________
For every complex problem, there is a solution: simple, straightforward, and invariably wrong.
H.L. Mencken
View user's profile Send private message
PostPosted: Wed Dec 13, 2006 7:06 pm Reply with quote
xyzzy
 
Joined: 12 Feb 2006
Posts: 225




options cx88-dvb debug=1
View user's profile Send private message
PostPosted: Thu Dec 14, 2006 3:25 pm Reply with quote
Steve-o
 
Joined: 04 Dec 2006
Posts: 3




Quote:
options cx88-dvb debug=1


Thanks. I'm thinking the problem may be with the drivers and hardware, rather than anything myth is doing, since none of us have found any reference to it in any of the myth logs.

I'll let everyone know if this pans out.

Steve

_________________
For every complex problem, there is a solution: simple, straightforward, and invariably wrong.
H.L. Mencken
View user's profile Send private message
PostPosted: Tue Jan 16, 2007 12:44 pm Reply with quote
boris_qd
 
Joined: 13 Nov 2005
Posts: 9




i'm having the same problem. I've started reloading the kernel modules every couple of days.

I havn't found anything in my logs either.

So - any progress on this?
View user's profile Send private message
PostPosted: Tue Feb 20, 2007 7:13 pm Reply with quote
sandro
 
Joined: 20 Feb 2007
Posts: 1




I'm having exactly the same problem. This is dropping the utility of my MythTV box to zero (since it's out of commission every time I need it to record something).

Doesn't anyone have a clue what might be causing this (or how to fix it).

I'm running Ubuntu 6.06 (Linux outland 2.6.17-10)
on a Pentium 4 2.8Ghz system.


-Sandro
View user's profile Send private message
PostPosted: Mon Mar 12, 2007 4:32 pm Reply with quote
vid_hobb
 
Joined: 21 Jun 2006
Posts: 5
Location: Caledon Ontario Canada




toups wrote:
Running a HD-3000 with MythTV 0.20. Every few days, the card is unable to tune in any stations. MythTV reports a signal strength of 100% and no lock on all channels. If I stop the back end do a "rmmod cx88_dvb" followed by a "modprobe cx88_dvb" then restart the back end then everyting is fine for a day, or two, maybe more. Any suggestions for debugging?

Kernel is 2.6.17-gentoo-r8

Thanks.


I see this also, and I can duplicate the problem over and over. I'm not using mythtv, but pchdtvr for Over-the-air, (not QAM cable).

Every 14 hours or so it Pchdtvr does the following...
When pchdtvr is left running with posted jobs, I come back the next day, and see failed recordings, failed EPG updates, and channel signal scan reports all channels at 100% signal strength.

Later I discovered this only happens if I leave the automatic EPG update turned on. So on occasion when the machine is not busy, it will tune stations all on its own and download the EPG from each station. It seems to be a problem when tuning to weaker stations (< 45% sig). I have yet to confirm this however because I,ve turned off all automatic EPG updates. With auto EPG off on all stations, card has not locked up in over a week, with about 15 recordings since last modprobe.

I don't know mythtv, but if it tunes around stations, including weaker ones, it can add up to be the same problem.

I don't think this has anything to do with pchdtvr or Mythtv, its (yet) another driver issue.

And yes granted I,m not using the latest pchdtvr ( which is renamed to atscap ), but thats not the issue here.

vid_hobb

--
PVR_1
2.6.17-gentoo-r8
Pentium D about 3.000 Mhz
Asus P5LD2, HD-3000
still in beta for over 2 years, uptime: 5 days average
--
PVR_0
2.6.9-1.11_FC2 (fedora2)
Pentium 3 1000
some old Asus MB, Haup. PVR350
full production, uptime > 475 days
100's of recordings used daily
[mythtv@mythtv movie]$ uptime
19:22:40 up 476 days, 19:19, 11 users, load average: 0.01, 0.01, 0.00
[mythtv@mythtv movie]$ (my old machine is named myth, but i never installed it.)
At least I have one reliable pvr card in the house.....$$$

_________________
OS: Gentoo
Kernel: 2.6.14
Card: HD-3000
View user's profile Send private message
driver design, card design, demodulator design, who knows?
PostPosted: Fri Apr 20, 2007 3:40 am Reply with quote
inkling
 
Joined: 05 Feb 2004
Posts: 342




vid_hobb wrote:
I don't think this has anything to do with pchdtvr or Mythtv, its (yet) another driver issue.


No argument there. The kernel and linuxtv.org OR51132 driver is garbage.

I gave up on getting anywhere with the idiotic DVB API developers and forked the v4l-dvb OR51132 code for HD-3000 ATSC only. To this day, I have never seen NTSC mode work on the card. The interrupt routine for cx88-video seems too broken. I don't use NTSC anyway. The HD-3000 has only one purpose for me and that is capturing ATSC.

Maybe it's an i2c bus capacitance issue in the card design. Maybe the OR51132 is simply a defective chip design that is incapable of working for more than a few hours after reset. Maybe the microcode (read: firmware) is the problem and not the actual hardware.

It should be noted that the silkscreen on the back of the card indicates the device is not for continuous use.

It should also be noted that some people have reported to me that their HD-3000 never fails and my patches to or51132.c to make it reset itself are never utilized. Lucky them. I was never so lucky.


I have fought with the *exact* same problems that you are having with my own HD-3000's in 2005, but I mostly ignored it because I was busy working on other things. I would simply reload the driver to get it going again. Eventually the problem became a reliability issue for pchdtvr (now named atscap) and it had to be addressed.

I would see ALL FOUR of my HD-3000's stop responding to i2c anywhere from 5 minutes to 5 hours after reset. It didn't matter if it was scanning frequencies or retrieving EPG or just sitting idle.

It would simply stop working with software or hardware i2c. It would sometimes drop dead *during* captures as well, but only if I were doing some kind of OR51132 i2c transaction during capture.

People have asked me, why doesn't pchdtvr/atscap use ioctl FE_READ_STRENGTH during capture?

The short answer is that it does, but because it can cause the OR51132 to fail and because the software i2c is a host CPU pig when using the stock kernel and v4l-dvb drivers from linuxtv.org it is not enabled by default. That's why pchdtvr and atscap have the -x option: so the user can decide to risk FE_READ_STRENGTH during capture.

When it failed during EPG retrieval or event capture, it was always during the initial AOS (Acquisition Of Signal) which is used to determine if it is even worth bothering to try to capture from that channel. At least this particular failure is DEFINITELY related to FORCING the OR51132 to present junk data on a weak signal.

How can it give you any kind of SNR reading when there is no signal to compare against? Negative SNR? That's just plain stupid. Signal and Noise are always positive or zero, therefore the Ratio will be positive or it will be a divide by zero logical code error.

What do op-amp comparators do when one or both inputs are floating? Try it for yourself with various op-amps and get back to me with your findings. I think you'll find there is quite a bit of variance in how they respond with or without proper clamping on the inputs.


Eventually I found the time to spend on the driver code. Within a week I had a solution. I presented my findings to the DVB API developers in March 2006 and they ignored me. I presented the fixes to the users here as well. Some of them actually use my patches and have lived happily with their HD-3000's since.


Mike Krusty, the self-appointed maintainer of the DVB API card drivers was too busy watching live-TV to be bothered with my patches. Maybe if he had something like pchdtvr or atscap to capture his TV shows for him so he could work on other things, he could have found the time to listen to an Engineer tell him how to fix the problem with the HD-3000. Mike Krusty doesn't have an HD-3000 so it's obviously not his problem and he doesn't care. Ask Mike why he doesn't care.

Here it is a year later and the linuxtv.org v4l hg/CVS and the kernel OR51132 drivers are still as broken and defective as they were 2 years ago and over a year after I developed a working solution to the problem.


My solution involves fixing things on a number of levels. The first part of my solution is to never read any signal related data with i2c if the status return doesn't have a lock indication.

Another part of my solution is to reset the device with the CX23883 External Reset pin and reload the microcode when the read_status() routine detects the modulation that was set is no longer being returned in the status register because the i2c communication is desynchronized.

A third, optional, part of my solution is to use hardware i2c so the reset doesn't take 10 seconds, but rather only 1 or 2 seconds. The hardware i2c, which is more or less a direct port from the linuxtv.org v4l bttv-i2c hardware i2c code, also eliminates the host CPU loading that occurs with software i2c algo-bit both on microcode load and on signal scan. It's optional for a reason.

With the linuxtv.org driver, the 20% host CPU usage during signal scan is ridiculous and unacceptable. Having the whole system go unresponsive for 40 seconds while the microcode loads for my FOUR HD-3000's is also ridiculous and unacceptable.

With hardware i2c transactions, host CPU usage is <1% on microcode load and <1% on signal scanning, as it should have always been, had someone taken the time to do it right by making the i2c hardware interrupt driven instead of software bit banging via algo-bit.

Remember I said optional? One of my test systems isn't working correctly with hardware i2c anymore, but works fine with software i2c, even though the driver and kernel are exactly identical to what it was before hardware i2c stopped working.

This is what prompts me to theorize that it's related to component aging and/or i2c bus capacitance issues.

Perhaps the i2c circuitry (read: op-amp comparators) on the OR51132 itself or the capacitors or clamping resistors on the i2c bus are drifting out of specification and the 100kHz i2c Clock and Data signals are arriving so far out of phase that the OR51132 gives up and puts itself to sleep.

Remember the silkscreen on the back of the card? It is interesting and relevant, AS IF the Engineers who designed the or51132 were very well aware that the device is not capable of continuous reliable operation.


Trent Piehole removed all the sleeps from the latest linuxtv.org incarnation of or51132.c, so the host CPU usage is even worse than it was before he touched the code. That was a truly stupid and needless 'code cleanup' excision that detrimentally affects people with slow capture machines, like one of my test systems that is a Pentium II with a 350MHz CPU.

Ask Trent why the driver is still broken and incapable of fault tolerance and fault recovery, since he slapped his name at the top of the or51132 file. He has had my driver patches to use as an example for well over a year now, yet Trent has done nothing with the ideas presented. I cringe at the thought of how many other users have had to suffer from his haphazard logic and lack of regression testing for his linuxtv.org patch submissions. Does Mauro Carvalho Chehab signs off on any old crap as long as it's pleasing to the eye, with no regard at all whatsoever about how broken it is?


"You can buy them books and send them to school but you can't make them think."


Most editors list *below* the original author, unless they're willing to take full responsibility for any issues the users might have with their commandeering of the code. That is a source code etiquette issue and not an Engineering issue but it's something that really irks some Engineers. Maybe Kirk Lapray-Itworks doesn't care. I'm glad they're not building the Freedom Tower.

Trent also claims to have 'discovered' the modulation status return not matching when i2c fails, according to a message he posted on the linuxtv.org forum, over a month after I had already posted about it here.

Maybe he did 'discover' it all right, AFTER I posted my findings about it here on this forum. Is his 'discovery' plagiarism of my own hard work? If it is, it has to be the worst job of plagiarism I have ever seen.

Even if Trent did actually 'coincidentally discover' it a month later, he did absolutely nothing with it except return an error mesage. That is unacceptable. He doesn't understand how to fix the problem and has done absolutely nothing to address it. A Discovery is useless without further Invention to utilize the knowledge gained.

The latest hg/CVS v4l-dvb 2.0 code from linuxtv.org seems to be so broken with regards to HD-3000 and or51132 that so far none of my known remedies have been able to correct the breakage. It seems that it fails the same as the old driver before I fixed it.

I'm still working on fixing the latest linuxtv.org tree or51132 code because I know some people are interested in using newer kernels and want the same reliable and robust driver that I was able to provide for 2.6.16.x, even if they don't particularly care about using atscap at all. If it works, it should work for atscap, MythTV or anything else.

However, my remedies applied to the v4l 1.0 code from January 2006 have been working fine with 2.6.16.x for over a year now. They may work with MythTV and other capture programs, as long as you keep in mind that it is ATSC only, not NTSC.

My FOUR HD-3000s have uptimes of months, when I'm not putting new features into atscap. Other people who use my driver patches report similar success.

The latest phases of regression testing have actually seen fewer resets per day than previous efforts, so something is improving somewhere. Maybe my reception? It will need more data collection and trend analysis.

As long as it resets itself when appropriate, as in not during capture, I don't particularly care how many resets per day or month it needs to do.

I'm sorry to hear that you are not able to achieve the same results with your HD-3000. Take up your complaints with the DVB API developers, or use my forked HD-3000 driver with an old 2.6.16.x kernel, or buy a new card in the vain hope that the DVB API developers will actually get it right one day.


Oren was bought by Zoran so you're not going to get any help from Zoran about OR51132 microcode. My own experience with Zoran and Vaddis III, 7 years ago, proved to me that Zoran doesn't care once they have your money. I got the Vaddis III working despite the stonewalling from Zoran. You can be sure there isn't going to be a new revision of the OR51132 microcde. The OR51132 product seems to be at End-Of-Life as far as Zoran/Oren is concerned.


Finally, I suggest that you use atscap instead of the old, deprecated and unsupported pchdtvr code. A years worth of work and testing has gone into making atscap much easier to use for capturing and editing. Also, please submit any bug or problem reports to the tracker that may be found on the SourceForge page.


Good Luck!
View user's profile Send private message
HD-3000 locks up every couple days or so
  pcHDTV Forum Index -> General pcHDTV topics
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 1 of 1  

  
  
 Post new topic  Reply to topic  


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