<div class="gmail_quote">On Thu, Jan 21, 2010 at 2:27 PM, Johnny Walker <span dir="ltr"><<a href="mailto:johnnyjboss@gmail.com">johnnyjboss@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On Wed, Jan 20, 2010 at 9:20 PM, Jerry Rubinow <<a href="mailto:jerrymr@gmail.com">jerrymr@gmail.com</a>> wrote:<br>
> Since switching to 0.22, I'd been having frame drops in the recorded files<br>
> (problem was definitely in the recording, not the playback), delays in<br>
> frontend activity. The frame drops coincided with frontend activity while<br>
> recording (playing back files, deleting files). Network showed no errors.<br>
> CPU usage on backend remained low (much less than 50%) throughout.<br>
> Upgrading from weekly 0.22-fixes to trunk had no effect on the issue.<br>
> Long story short, turning off all logging except for "important" messages<br>
> caused all issues to go away.<br>
<br>
</div>I'm not trying to be rude - but how does one detect a dropped frame<br>
without logging?<br></blockquote><div><br></div><div>No offense taken. It was multiple dropped frames, plural in any given instance, usually a key frame among them. Visually, I'd see at the least a corrupted image for a fraction of a second, and sometimes several seconds of missing or corrupted video and missing audio. This is why I think it was received mpeg packets falling off the buffer rather than problems post-decode.</div>
<div><br></div><div>-Jerry</div></div>