ZoneMinder Forums

The reason why I am looking into the chipset is more as the suggested live CD, took this card and ran well with it, I need to get the current platform running with it.

the suggestion that I saw on that LiveCD post, I took, and looked into, and am looking for tuning BTTV to work with the card, in a manner that is like the LiveCD, though I am on a Fedora box, not a Mandrake box.

The Kernel is timing out the BTTV driver, and due to seeing that, I upped the logging on that. What I am seeing looks like this from the increased logging on the BTTV driver:

Nov 23 00:31:31 s_kernel@minazuki.tsukinokage.net kernel: bttv0: irq loop=0 fc=36 riscs=1, riscc=1e77c29c, bits: VSYNC* HSYNC OFLOW
Nov 23 00:31:31 s_kernel@minazuki.tsukinokage.net kernel: bttv0: irq loop=0 fc=37 riscs=1, riscc=1e77c29c, bits: VSYNC* HSYNC OFLOW
Nov 23 00:31:32 s_kernel@minazuki.tsukinokage.net kernel: bttv0: irq loop=0 fc=38 riscs=1, riscc=1e77c29c, bits: VSYNC* HSYNC OFLOW
Nov 23 00:31:32 s_kernel@minazuki.tsukinokage.net kernel: bttv0: irq loop=0 fc=39 riscs=1, riscc=1e77c29c, bits: VSYNC* HSYNC OFLOW
Nov 23 00:31:32 s_kernel@minazuki.tsukinokage.net kernel: bttv0: irq loop=0 fc=40 riscs=1, riscc=1e77c29c, bits: VSYNC* HSYNC OFLOW
Nov 23 00:31:32 s_kernel@minazuki.tsukinokage.net kernel: bttv0: irq loop=0 fc=41 riscs=1, riscc=1e77c29c, bits: VSYNC* HSYNC OFLOW
Nov 23 00:31:32 s_kernel@minazuki.tsukinokage.net kernel: bttv0: timeout: drop=0 irq=15133/15134, risc=1e77c29c, bits: HSYNC OFLOW
Nov 23 00:31:32 s_dgram@minazuki.tsukinokage.net zmdc[14616]: ERR ['zmc -d /dev/video0' exited abnormally, exit status 255]
Nov 23 00:31:32 s_dgram@minazuki.tsukinokage.net zmwatch[14647]: INF ['zmc -d /dev/video0' stopping at 07/11/23 00:31:31]



I don't and never have worked with tuner cards, nor capture cards on a Linux box before, so on THAT aspect I am rather new, though I know enough to at least fix it, or roll my own kernel if that needs to be done, though that would increase the upkeep of the box over upgrades, which is not desirable.


Ultimately the card was purchased because I did, over the year and a half ago that I got the card to work with a borrowed CCTV cam from a friend. I had tossed the project to the side due to work and school and forgot about it, and half the crap I knew about the card until I started working on this.

Since a little bit of impolite help, I did start looking farther into the card information again. literally, aside from a few electrolyte capacitors and a large amount of surface mounted resisters, fuses and capacitors, there are two IC's, one is buried under a heat sink, and the other is not clearly marked. the secondary one looks like a PIC of some flavor, and due to the Traces it looks like it is responsible for aiding card multiplexing. since this isn't in use, I am not as interested in this variable. This compounded by the fact that I am able to get imagery on the device, as well the fact that I can run the device bare bones at times, makes me point to that Chip set I have been looking into.


To run a test, I have the camera in gray scale right now, and it seems to be healthy. I have followed what I remembered about tuning the system to allow for more shared memory, and checking the resident size in shared doesn't show me that zone minder is taking up all that much of it. I have bumped up from 128Meg to half a gig of shared with no effect. I have also tried to use different 878a card profiles for BTTV, without much success.


I would rather use the card and camera's to the full capacity of the devices, but outside of memory use I don't know where to look. It would be reasonable to find a bit more information on this chipset, more than anything else, since it is the kernel driver I am seeing fall over and die.


Lee Sharp, it was your comments, first the low res, and the memory thing, that I did apply. I have to say, looking for gig sticks for this thing left me sticker shocked, so I had to drop back to 512 sticks. and right now it is sitting at 1.25 Gig of memory.

A large portion of what I am after in terms of help is not "Hey someone get this working right now now now" since I have waited about a year and a half already to get this box up full and running, it is more about "Hey, I don't know what this means, could I get a little help on people who have the ZM/V4L combined EXP to help me figure out what this is doing?"


I have received some general, and good, suggestions that I have looked into, I just don't being treated in a way that can be construed as condescending, simple as that.

So, I leave it at this, if anyone does really want to give me a hand with this tell me what you need of me, including killing this server and bringing it up under the liveCD again, and I will get the settings off of that that is needed or asked for.

The problem is you have more than one problem hitting at once. To start, if you can find another machine, (with a lot of ram) try that first. Try the traditional LiveCD, and perhaps the Puppy, and the Ubuntu LiveCD roll your own. Get dmesg from all of them, and see what works and what doesn't. And yes, it gets frustrating. This is why I buy hardware that works. I can't handle the headaches that often. We did a massive test of 5 different cards once, and that was enough!

That said, I would be willing to take your card for a spin in a known working system of mine. Others might be as well. USPS might be the fastest way to see if it can be made to work in other hardware.

Well, I know the card works in *nix, that is the fun/annoying/challenging thing about this. If I am going to make this aspect of the systems a concrete aspect, and my current old junker won't handle it, I will go well beyond the normal spec's. I have two dual CPU boards, and maybe get another one just for the CCTV/Camera system (With 16-32 GB RAM, that isn't a bad option) but what floors me is that the liveCD works well (40FSP reported, but on the current settings I get near real time anyways, while it claims only 5FPS) and this is a rather low end RapidOS card that was sold as an Apollo card. Go figure that Apollo isn't in business anymore.

I have more than enough spare memory allocated (I set up 512MB for the shared, and will prolly bump that to 750 or so) as another test. The calculation of memory usage is a bit hard to get just right, on RBG24. That and the color wasn't right, and aside from a few minor things, Black and white works just as well (esp. the Infrared side is all B&W) so the hardest thing I am having with the aspect isn't hardware, but what is done with the liveCD's kernel/drivers/build that is different from my current rig. Guess I will have to take some time to reverse engineer it to get the exact settings.


And as a note, I figured out what the error 255 for the camera terminating means. The bugger has run out of shared memory and wasn't able to recycle it.

Live, learn and get a headache from it all.



Thanks for the help so far, and thanks for putting up with the bitching so far

It isn't really a Zoneminder thing now, but Zoneminder is working to be a better tool than I thought with this problem. It looks like the Brooktree drivers I have been playing with have various reactions to the camera capture. I have come really close to the Live CD on performance with this card:

Ends up with 20-40 FPS (depending on how the driver 'feels' per re-load) runs wonderfully for anywhere from 5 minutes to 3 weeks. When it crashes, Zoneminder is fine and happy (no red devices, and reporting it is accessing the device fine) the video stream just goes black on gray-tone, and blue on RBG.

I haven't found the exact crash on the driver, or why it does this, since the logging even shows that it is running properly, FPS count keeps the same, and frames captured increments the way it should.

my modprobe.conf has this in it for the driver:
options bttv bttv_debug=1 irq_debug=1 bttv_verbose=2

and a short output of my logs are as follows:

Dec 19 16:15:50 s_kernel@minazuki.tsukinokage.net kernel: bttv0: irq loop=0 fc=38283 riscs=1, riscc=1095b01c, bits: HSYNC RISCI*
Dec 19 16:15:50 s_kernel@minazuki.tsukinokage.net kernel: bttv0: next set: top=00000000 bottom=f752d500 [screen=00000000,irq=1,0]
Dec 19 16:15:50 s_kernel@minazuki.tsukinokage.net kernel: bttv0: irq loop=0 fc=38283 riscs=1, riscc=0b568024, bits: VSYNC* HSYNC FDSR
Dec 19 16:15:50 s_kernel@minazuki.tsukinokage.net kernel: bttv0: buffer field: bottom format: 8 bpp, gray size: 320x240
Dec 19 16:15:50 s_kernel@minazuki.tsukinokage.net kernel: bttv0: read count=61440 type=vbi-cap
Dec 19 16:15:50 s_kernel@minazuki.tsukinokage.net kernel: bttv0: irq loop=0 fc=38284 riscs=1, riscc=173d1398, bits: VSYNC* HSYNC FDSR
Dec 19 16:15:50 s_kernel@minazuki.tsukinokage.net kernel: bttv0: irq loop=0 fc=38285 riscs=4, riscc=2412001c, bits: HSYNC RISCI* FDSR
Dec 19 16:15:50 s_kernel@minazuki.tsukinokage.net kernel: bttv0: irq loop=0 fc=38285 riscs=1, riscc=1095b01c, bits: HSYNC RISCI*
Dec 19 16:15:50 s_kernel@minazuki.tsukinokage.net kernel: bttv0: next set: top=00000000 bottom=f752df00 [screen=00000000,irq=1,0]
Dec 19 16:15:50 s_kernel@minazuki.tsukinokage.net kernel: bttv0: irq loop=0 fc=38285 riscs=1, riscc=1323a02c, bits: VSYNC* HSYNC FDSR


Sadly I am not even close to being completely competent with the BTTV driver, so most of the log output passes me by, but I know, thanks to previous posts, it is due to how the Fedora 7 branch kernel (2.6.23.1-21.fc7, with the driver loaded as a module, at this time) interacts with the card.


Now, with all this said, I am looking for a good 4-8 port card that doesn't require as much voodoo to get it running, though this HAS been a lark, and I am wondering if anyone has a good suggestion for a small list of the cards that would be perfect for a CCTV setup.

One other thing, I am wondering if anyone has some good BTTV sites that are decent at explaining the module options. I have found a few, but most seem to trail off. I know this isn't the place for that support though.

Ok, I solved the issues I was having. I started digging into a lot of the issues I was seeing and ended up seeing that I had an IRQ conflict with my 3Com NIC. I had an upgrade to an Intel NIC on the way, so when I swapped it out, I got the system up and working as it should have. Seems that though it is a common case of searching with your eyes closed on my part.


Now I venture into the fun area of getting it to work right, zoneminder that is. Zones aren't firing the way they should (no motion detection/recording) and I KNOW that is my fault, and my own errors, and that is plenty said about in the documentation.


As a recap, this old system with a 4 port CCTV card from a company that is now defunct does work in this computer. With 2 gigs of memory, and a 1Gig nic, it has improved its lot in life as well. So to answer my own question, you can run full color/framerate on an old system (even though 1 Gig still isn't a bad speed).


Thanks for the help everyone!

Thanks for the updates, even if you maybe felt like you were talking to yourself half the time!

Some day I have to put together a list of the 20 or so "First things you should try." IRQ conflicts are somewhere on that list.

Well, I guess that is what I get for using an old 3com card that I pulled out of a system when it was brand new. Mind you this system was an old Intel Pentium 200 (before MMX came out) and the stuff I was watching for was the wrong area to be watching. I am no longer as used to fighting hardware conflicts since most addresses are configurable on newer hardware I have been using. Guess I got spoiled. But I guess that is what I get for waiting so long to get a real camera on the system. I did try to use a USB webcam as an add on, but that crashed and killed my USB hub (what ever crappy driver I found for it, tested it, and forget to remove it after the camera was scrapped off the idea) so there have been a lot of fun things I have tried with it, all have gone the way of carbon based input error and other problems like that. The only thing that confused me at first was "Why does the live CD work and the real system install, not work?" I looked more in depth, and the card grabs a different address on the bus than it does in my Fedora build. I wasn't sure that the new card would fix it, in case it grabbed the same IRQ, but hey, I am not complaining. Though maybe now I can reduce logging with the module.


The only other thing I am fighting with now, is the alerting on the camera, since nothing seems to work so far. I know this is all me now, so.... Biggest thing is no triggers no matter what I have tried so far, though I haven't tried everything I can think of yet, so it isn't all that bad. I also need to RE-RTFM, so... that would help too...


Thanks for the help, feedback and so far on this...

There is an entry in the FAQ that might help you with configuring zones for motion detection etc.

Working with image analysis and monitor tweaking, and have a really, well I think it is funny, error exploding in my syslog (now that I have turned off the bttv driver debugging) the Error is:

Feb 11 10:38:11 s_dgram@minazuki.tsukinokage.net zmc_dvideo0[6307]: WAR [Buffer overrun at index 25, slow down capture, speed up analysis or increase ring buffer size]
Feb 11 10:38:14 s_dgram@minazuki.tsukinokage.net zmc_dvideo0[6307]: WAR [Buffer overrun at index 25, slow down capture, speed up analysis or increase ring buffer size]
Feb 11 10:38:17 s_dgram@minazuki.tsukinokage.net zmc_dvideo0[6307]: WAR [Buffer overrun at index 25, slow down capture, speed up analysis or increase ring buffer size]
Feb 11 10:38:19 s_dgram@minazuki.tsukinokage.net zmc_dvideo0[6307]: WAR [Buffer overrun at index 25, slow down capture, speed up analysis or increase ring buffer size]
Feb 11 10:38:22 s_dgram@minazuki.tsukinokage.net zmc_dvideo0[6307]: WAR [Buffer overrun at index 25, slow down capture, speed up analysis or increase ring buffer size]



I need to figure out where the analysis tuning is done, since it has been a while since I have done that, I will be digging into the documentation for that. I have a buffer of 80 right now, may increase that a bit more, depending.


Outside of that, the box is chugging along great since I swapped that NIC out.

One more fun one. I cleared/edited the last error out (changed the alert area and it cleared this up) and testing alarms. I am now getting this:

Feb 11 15:21:02 s_dgram@minazuki.tsukinokage.net zma_m20[7720]: ERR [Incomplete frame write: 16128 of 71174 bytes written]
Feb 11 15:21:02 s_dgram@minazuki.tsukinokage.net zmf_m20[7717]: INF [Frame server socket open, awaiting images]
Feb 11 15:21:02 s_dgram@minazuki.tsukinokage.net zmf_m20[7717]: ERR [Incomplete read of frame image data, 16112 bytes only]
Feb 11 15:21:02 s_dgram@minazuki.tsukinokage.net zma_m20[7720]: ERR [Incomplete frame write: 16128 of 71244 bytes written]
Feb 11 15:21:02 s_dgram@minazuki.tsukinokage.net zmf_m20[7717]: INF [Frame server socket open, awaiting images]
Feb 11 15:21:02 s_dgram@minazuki.tsukinokage.net zmf_m20[7717]: ERR [Incomplete read of frame image data, 16112 bytes only]
Feb 11 15:21:02 s_dgram@minazuki.tsukinokage.net zma_m20[7720]: ERR [Incomplete frame write: 16128 of 71202 bytes written]
Feb 11 15:21:02 s_dgram@minazuki.tsukinokage.net zmf_m20[7717]: INF [Frame server socket open, awaiting images]
Feb 11 15:21:02 s_dgram@minazuki.tsukinokage.net zmf_m20[7717]: ERR [Incomplete read of frame image data, 16112 bytes only]
Feb 11 15:21:02 s_dgram@minazuki.tsukinokage.net zma_m20[7720]: ERR [Incomplete frame write: 16128 of 71376 bytes written]
Feb 11 15:21:02 s_dgram@minazuki.tsukinokage.net zmf_m20[7717]: INF [Frame server socket open, awaiting images]
Feb 11 15:21:02 s_dgram@minazuki.tsukinokage.net zmf_m20[7717]: ERR [Incomplete read of frame image data, 16112 bytes only]
Feb 11 15:21:02 s_dgram@minazuki.tsukinokage.net zma_m20[7720]: ERR [Incomplete frame write: 16128 of 71265 bytes written]
Feb 11 15:21:02 s_dgram@minazuki.tsukinokage.net zma_m20[7720]: INF [Front_Door: 453445 - Left alarm state (744) - 231(161) images]



So I guess I have a little more tweaking to go with it and this old hardware should be good. I have been reading the wiki and documentation but have had a hard time finding errors outside of indirect approaches.

This is an issue with default socket sizes when sending them to the frame server. You can either modify your system config as per this post or disable the frame server via Options->System->ZM_OPT_FRAME_SERVER. I would recommend the latter unless you are at the limit of your systems performance.

Thanks for the reply. I did disable it and the errors went away (did a lot of reading yesterday and took a lot of the crud I configured that I didn't need out) and am back at getting the modetect to do as it says. I know it is me, and my settings, but I do have to say it drives me batty that I got it to work with a camera with poor quality (moving blurs, more than anything) and now that I have a REAL camera to use, my silly self can't remember what he did to get it to work. Oh well, perfect time to relearn, I guess.



Once again, thanks for the help! I will post when I get the modetect (and mocord? if I can find the vid's it creates, now that I have fixed the video/event directory problems I was having, heh) working.

Ok, I am a bit stumped here, I am getting this in my debugging output for this camera set:

Every 1.0s: cat /var/log/zoneminder/debugging.log Wed Feb 13 20:48:36 2008

02/13/08 20:48:34.239553 zmu[21663].INF-zm_debug.c/304 [New Debug Level = 3, New Debug Log = /var/log/zoneminder/debugging.log]
02/13/08 20:48:34.242051 zmu[21663].DB1-zm_monitor.cpp/1899 [Got 1 monitors]
02/13/08 20:48:34.244523 zmu[21663].DB1-zm_monitor.cpp/253 [monitor purpose=0]
02/13/08 20:48:34.244646 zmu[21663].DB1-zm_monitor.cpp/260 [shm.size=21889628]
02/13/08 20:48:34.245464 zmu[21663].DB1-zm_zone.cpp/49 [Initialised zone 0/All - 1 - 320x240 - Rgb:ff0000, CM:3, MnAT:15, MxAT:0, MnAP:50, MxAP:7
5000, FB:3x3, MnFP:50, MxFP:50000, MnBS:10, MxBS:0, MnB:0, MxB:0]
02/13/08 20:48:34.251109 zmu[21663].DB1-zm_monitor.cpp/329 [Monitor Front_Door has function 3]
02/13/08 20:48:34.251148 zmu[21663].DB1-zm_monitor.cpp/330 [Monitor Front_Door LBF = '%%s - %m/%d/%y %H:%M:%S', LBX = 0, LBY = 0]
02/13/08 20:48:34.251178 zmu[21663].DB1-zm_monitor.cpp/331 [Monitor Front_Door IBC = 95, WUC = 10, pEC = 20, PEC = 20, EAF = 16, FRI = 1000, RBP
= 10, FM = 0]
02/13/08 20:48:34.251230 zmu[21663].DB1-zm_monitor.cpp/2036 [Loaded monitor 20(Front_Door), 0 zones]



it shows loaded 1 zone when I create the zone, but then it doesn't seem to load the zone at all, even in the 'all' default zone state. I don't know what is broken where, which is a bit of a pain. Any help on this?

What are you trying to get zmu to do? It will only load the zones if it thinks it needs to. To do simple things it sometimes only needs the monitor info itself.