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

Daniel Kristjansson danielk at cuymedia.net
Thu Apr 26 16:00:28 UTC 2007


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



More information about the mythtv-dev mailing list