[mythtv] [mythtv-commits] Ticket #3350: Threaded Preview Gen does not use qmap index consistently

[Mark Buechler]

I'm glad someone else is also seeing the backend dump during preview
generation. It always happens to me with h264/paff interlaced streams.

- Mark.

On 4/26/07, Daniel Kristjansson <danielk at cuymedia.net> wrote:
>
> On Wed, 2007-04-25 at 21:41 -0400, Chris Pinkham wrote:
> > * On Wed Apr 25, 2007 at 07:28:19PM -0400, Daniel Kristjansson wrote:
> > > If network usage is the problem, I think it might make sense to
> > > change the preview generators concept of a locally accessible
> > > video. You could use the information that the storage groups
> >
> > Since the original preview generator code checked for the file
> > locally, when I made the Storage Groups modifications, I made
> > it force ProgramInfo::GetPlaybackURL() to check locally as well
> > instead of honoring the AlwaysStreamFiles setting.  Maybe we should
> > honor that setting in the preview generator as well.  This isn't
> > directly tied to this issue, but it may affect some people who
> > are seeing the issue.
>
> I don't remember why, but streaming was a problem for the
> preview generator. Maybe we can only do one preview at a
> time when streaming? My frontends are always much more
> powerful than the backends for HDTV playback, so having
> many previews in flight increases throughput. I also tend
> to put the drives in the frontends and NFS mount them on
> the backend which makes seeking much faster during playback,
> and the backend doesn't really need a whole lot of
> performance out of the file system to write a stream of data.
> I think we pretty much don't do streaming for previews,
> we only do frontend generation if we can access the files
> via the file system, and otherwise we do backend preview
> generation on the backend that recorded the file and hence
> has access to it via the file system.
>
> > RE: where to generate the preview at...
> >
> > I can see there may be benefits to generating it locally, but
> > I've always preferred that that kind of thing be done on the
> > backend that recorded the file.  We could still honor the
> > MasterBackendOverride setting and have the master generate the
> > preview if that setting is on.
>
> Ideally we should have an set a numeric limit on the number
> of previews either the frontend or backend should do at a time;
> say b2f1 on a balanced system with the drive on the backend,
> b3f0 on a system where the frontend is slow and/or only has
> access to recordings through the network, b0f4 where the backend
> is slow and the frontend is fast and has direct access to the
> files.
>
> Another thing that has been bugging me about the preview
> generator on the backend is that it can take down the whole
> backend when ffmpeg segfaults when processing a broken
> MPEG-2 file (DTV). I think we should spawn a separate process
> to generate a preview on the backend since a backend crash
> is so much worse than a frontend crash (you lose recordings,
> and you may not notice for a while that the backend is gone).
>
> -- Daniel
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mythtv.org/pipermail/mythtv-dev/attachments/20070426/a6b9ab70/attachment.htm