> Cyrus A wrote:
>> Hans Verkuil wrote:
>>
>>>> Unfortunately, the error came back. The error log is at
>>>> http://koala1.dynalias.com/VBI_errors.txt . I'm not sure it says much.
>>>> I
>>>> can't think of anything else that would have happened at 20:00 that
>>>> would have caused the problem. However, what can you tell me about the
>>>> timing of VBI and recording processes. Should one start before the
>>>> other
>>>> (I remember seeing some errors about "vbi process started after
>>>> recording (seems not to work)")?
>>>>
>>>>
>>> This has been solved and the order shouldn't matter anymore.
>>>
>>>
>>>
>>>> Do you think a prior recording would be
>>>> causing this error? (A recording during the 19:00 hour finishes about
>>>> 20
>>>> seconds before the 20:00 show starts. It's not always the 20:00 show
>>>> with errors though. There really is no pattern to it, that I can see.)
>>>>
>>>>
>>> Do these errors start right from the beginning of the recording? Or is
>>> there a period where the VBI transfers are fine?
>>>
>>>
>>>
>> From what i could tell of the logs, it starts right at the beginning of
>> the recording. The first VBI error was timestamped 20:00:02. There
>> didn't appear to be any "normal" time before that.
>>
>> If you stop the recording
>> with VBI errors and start another, does the new one also have the VBI
>> errors?
>>
>>
>> Recordings on other devices are unaffected, but if a device goes "bad"
>> it will continue having this error on all other recordings attempted on
>> that device until the system is rebooted. I don't even think removing
>> ivtv and putting it back in fixes the issue, but don't quote me on that.
>>
>> Anyway, I would like to see a log that includes the period where
>> the VBI capture is still fine. Weird problem.
>>
>> This time it was a 7:00 show and the first VBI error was timestamped
>> 07:00:03. No errors before that, although I didn't have extra debugging
>> turned on this time. Sorry.
>>
>>
>>> Is it only the PVR150 that has this problem, or does the PVR500 also
>>> exhibit it?
>>>
>>>
>>>
>> I got the error again this morning, and this time it was /dev/ivtv2,
>> which is one of the PVR-500 tuners.
>>
>>
>>> Thanks,
>>>
>>> Hans
>>>
>>>
>>>
>> Let me know what else you need.
>>
>> Cyrus
>>
>> p.s. Just a thought, is it possible that running ivtv-tune at the same
>> time as a VBI or recording process is giving the device too many
>> commands at once causing some sort of rare conflict?
>>
>>
> I just had another error, this time at 12:30. There was a process right
> before it, too from 12:00:00 to 12:29:40. I'm beginning to wonder that
> if the previous VBI process has not yet ended, maybe that's causing a
> conflict of some sort. Seems like a bit of a pattern. I don't know if
> I've noticed errors happening to "new" shows (i.e. shows that are
> starting with no recordings happening in front of them). What do you
> think about that?
I'll try to reproduce this problem during the weekend. At the moment I
truly have no idea what's happening, it's all very weird. My problem right
now is that I do not have a good development and test environment here in
Norway. I'm going to buy a new PC but that won't be available for two
weeks at least.
One thing that will be very useful for me is if you could try the
following: turn on the info and warning messages (ivtvctl -D3) and make a
log. You will get many 'read X from Y' messages, you can comment out the
line 'IVTV_DEBUG_INFO("read %zd from %s, got %zd\n", count, s->name, rc);'
in ivtv-fileops.c, function ivtv_read_pos(). In fact, I recommend that as
it makes the log much shorter and easier to read.
When a VBI capture is started the log will produce an entry like this:
ivtv0 info: Start encoder stream encoder VBI
ivtv0 info: Setup VBI API header 0x0000bd03 pkts 1 buffs 4 ln 36 sz 1456
ivtv0 info: Setup VBI start 0x002fea04 frames 4 fpi 1 lines 0x00000140
ivtv0 info: PGM Index at 0x00180150 with 400 elements
I am very interested in what this looks like for a 'wrong' capture.
Perhaps that contains a clue.
BTW: even though the VBI capture is broken, the MPEG capture is still
producing a valid stream, correct?
Thanks,
Hans
_______________________________________________
ivtv-devel mailing list
[email protected]
http://ivtvdriver.org/mailman/listinfo/ivtv-devel
