Hi<br><br><div class="gmail_quote">On Sun, Jan 11, 2009 at 7:06 AM, Per Heldal <span dir="ltr"><heldal@eml.cc></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d">10.01.2009 18:01, Mark Buechler wrote:<br>
><br>
> This is still an issue with Dish recordings from an R5000 box. The backend<br>
> waits too long for an IDR to come along and the frontend bulks. I've seen an<br>
> average of 10-15 seconds on the backend before a payload start message comes<br>
> up. Reversing commit 19094 gets around the issue.<br>
><br>
> - Mark.<br>
><br>
><br>
<br>
</div>You need to apply the diff in 19094 (not reverse it) to make the backend<br>
ignore IDR and solve the problem.<br>
<br>
I had to do the same using a Hauppauge HVR4000/DVB-S2 on Canal Digital<br>
Nordic (Norway) . I first tested by upping the 16sec (16000msec in the<br>
code) timer in the player to 10min and timed how long it took for the<br>
back-end to find an IDR-frame and start recording. The results varied a<br>
bit between attempts on a channel, but more across the different<br>
channels. An average for 10 attempts differed from 18sec on the "best"<br>
channel to 7min52sec on the worst.<br>
<font color="#888888"><br>
//per<br>
</font></blockquote><div><br>What I'm seeing is no IDR frames at all, only SLICE frames (type 1). I do see a frame 0, but I'm also seeing 512 frames/primary key (I'm told) so waiting for frame 0 could take several seconds.<br>
</div></div><br>- Mark.<br>