[mythtv-users] comm flagging hdpvr file while recording results in errors

[Richard Woelk]

Jim Stichnoth wrote:
> On Tue, Mar 2, 2010 at 12:37 PM, sp <analogue at yahoo.com> wrote:
>   
>> My backend is able to comm flag HDPVR recordings while they are still recording but it seems like the comm flagging routine is not as accurate compared to doing the comm flagging after the recording has finished. My backend it able to comm flag at a rate faster than the file is recorded (720p HDPVR recording is 60fps but the comments in the jobqueue table indicate that comm flagging fps is faster -- "84% Completed @ 61.2766 fps")  This results in multiple errors spewed in the mythbackend log:
>>
>> 2010-03-02 14:22:21.543 AFD Error: Unknown decoding error
>> 2010-03-02 14:22:22.604 [h264 @ 0x5636e0]B picture before any references, skipping
>> 2010-03-02 14:22:22.605 [h264 @ 0x5636e0]decode_slice_header error
>> 2010-03-02 14:22:22.605 [h264 @ 0x5636e0]no frame!
>> 2010-03-02 14:22:22.606 AFD Error: Unknown decoding error
>> 2010-03-02 14:22:22.606 [h264 @ 0x5636e0]B picture before any references, skipping
>> 2010-03-02 14:22:22.607 [h264 @ 0x5636e0]decode_slice_header error
>> 2010-03-02 14:22:22.607 [h264 @ 0x5636e0]no frame!
>>
>> I've verified the errors are in fact generated by the mythcommflag process by sending a SIGSTOP signal (errors cease to show up in log) and then a SIGCONT signal (errors start spewing again).  Is this a known issue? Is there some way to throttle the speed of the comm flagger so it does not continually run into these problems?
>>     
>
> I took a look at the code and I'm inclined to agree with your theory.
> By the way, how do you judge the quality difference between real-time
> and delayed commflagging?
>
> Those errors in the log seem to show up especially when skipping
> around in the file.  I see them in the playback logs when skipping
> forward or backward.  I see them in the logo detection phase of
> commflagging (regardless of whether it is real-time or delayed), where
> one frame out of every two seconds is sampled.  And it looks like
> you're seeing them in the commercial detection phase when it catches
> up to real-time.  Maybe these errors are because of dependencies on
> future frames?  I don't know.
>
> In any case, it would be easy enough to modify the end of
> ClassicCommDetector::go() to make sure the commercial detection phase
> stays at least 30 seconds behind the recording, which should get rid
> of the errors after the logo detection completes.  Are you in a
> position to test a patch?
>
> Jim
> _______________________________
I also see these errors everywhere when working with the HDPVR files. I 
think I read previously on this list that they come from ffmpeg, and I 
also see them in mplayer when skipping in a file. I just checked my 
software frontend, and now (on 0.23 trunk version 23405) they are hidden 
unless I start mythfrontend with -v playback. I don't use realtime 
commercial flagging as I normally watch shows 2 to 3 days later, but I 
have seen it spammed from the flagger when a recording is broken enough 
to make it hang
I have ignored them, as they cause no other trouble than filling up 
logs. (on a bad satellite day, that can fill my root partition in a few 
hours)

- Richard