My Myth box is *so* close to being finished, but I'm stuck with a semi-frequent (every day or two) lock-up that means I can never guarantee I'll get a recording OK :(
Every so often, a recording generates zero bytes, and Myth becomes deeply unhappy about this (it doesn't seem to realise, it just plays up). I have to reboot, *then* stop & restart the backend after it's come back up to get it to work again.
Once it's locked (prior to reboot), I see a zero byte 'ongoing' recording; I can kill the backend and do 'mplayer /dev/video0' (this is s-video only) and get no output (ditto 'cat /dev/video0 > test.mpeg' == zero length output).
It *seems* to happen at the very start of recording; it *may* happen only straight after another recording (or even only at the *end* of recording) as I think I've only got it [so far] in between two concurrent progs.
Here's what ivtv spews when it should be generating video:
... Mar 4 22:25:30 pvr kernel: ivtv: encoder thread sleeping 2419 Mar 4 22:25:30 pvr kernel: ivtv: VBI: Sched DMA Mar 4 22:25:30 pvr kernel: ivtv: encoder thread sleeping 2419 Mar 4 22:25:30 pvr kernel: ivtv: VBI: Sched DMA Mar 4 22:25:30 pvr kernel: ivtv: encoder thread sleeping 2419 Mar 4 22:25:30 pvr kernel: ivtv: VBI: Sched DMA Mar 4 22:25:30 pvr kernel: ivtv: encoder thread sleeping 2419 Mar 4 22:25:30 pvr kernel: ivtv: VBI: Sched DMA Mar 4 22:25:30 pvr kernel: ivtv: encoder thread sleeping 2419 Mar 4 22:25:30 pvr kernel: ivtv: VBI: Sched DMA ...
Here's where that starts (but may not be the location of an error):
...
Mar 4 22:00:05 pvr kernel: ivtv: API Call: 0x000000a1
Mar 4 22:00:05 pvr kernel: ivtv: cmd: 0x000000a1 arg 2 stored
Mar 4 22:00:05 pvr kernel: ivtv: as 0x00000001
Mar 4 22:00:05 pvr kernel: ivtv: API Call: 0x000000d0
Mar 4 22:00:05 pvr kernel: ivtv: cmd: 0x000000d0 arg 1 stored
Mar 4 22:00:05 pvr kernel: ivtv: as 0x00000000
Mar 4 22:00:05 pvr kernel: ivtv: API Call: 0x000000d8
Mar 4 22:00:05 pvr kernel: ivtv: cmd: 0x000000d8 arg 12 stored
Mar 4 22:00:05 pvr kernel: ivtv: as 0x00000000
Mar 4 22:00:05 pvr kernel: ivtv: API Call: 0x000000d9
Mar 4 22:00:05 pvr kernel: ivtv: got free mailbox: 1 after 0 tries
Mar 4 22:00:05 pvr kernel: ivtv: API Call: 0x00000081
Mar 4 22:00:05 pvr kernel: ivtv: got free mailbox: 0 after 0 tries
Mar 4 22:00:05 pvr kernel: ivtv: [0]result not ready, waiting 10 ms
Mar 4 22:00:05 pvr kernel: ivtv: Releasing mailbox (before 0x00000007, ivtv: after 0x00000000)
Mar 4 22:00:05 pvr kernel: ivtv: ivtv_read: stream 0..
Mar 4 22:00:05 pvr kernel: ivtv: ENC: 256 bufs, 0x00000000 fill; 256 free 0 dma 0 full 0 io
Mar 4 22:00:05 pvr kernel: ivtv: VBI: Sched DMA
Mar 4 22:00:05 pvr kernel: ivtv: encoder thread sleeping 2419
Mar 4 22:00:05 pvr kernel: ivtv: VBI: Sched DMA
...
I've left a longer snippet of the above, with a bit before (OK), a bit during changeover (stop last recording, start next) and a bit after bork at:
http://www.fnxweb.com/data/ivtv.log
The blank lines in the log are where I've snipped; there was wuite a lot! I still have the full lot if needed.
This is FC3 (fresh install), ivtv 0.2 from ATrpms (I'm ure I installed 0.1, dunno when 0.2 self-installed), myth 0.17 FWIW.
Please help! I'm at my wit's end; I'm now beyond my level of knowledge for trying to analyse it any further, and to be honest I'm not even sure how to prove whether it's the driver or something myth's doing :-/
-- [EMAIL PROTECTED] ~]# rm -f .signature [EMAIL PROTECTED] ~]# ls -l .signature ls: .signature: No such file or directory [EMAIL PROTECTED] ~]# exit
------------------------------------------------------- SF email is sponsored by - The IT Product Guide Read honest & candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click _______________________________________________ ivtv-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/ivtv-devel
