[prev in list] [next in list] [prev in thread] [next in thread]
List: mythtv-dev
Subject: Re: [mythtv] [mythtv-commits] Ticket #3350: Threaded Preview Gen
From: "Mark Buechler" <mark.buechler () gmail ! com>
Date: 2007-04-26 20:44:32
Message-ID: 3e9048940704261344x89ee34cv3ec7921bb72d1fd3 () mail ! gmail ! com
[Download RAW message or body]
[Attachment #2 (multipart/alternative)]
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@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@mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
[Attachment #5 (text/html)]
I'm glad someone else is also seeing the backend dump during preview generation. \
It always happens to me with h264/paff interlaced streams.<br><br>- \
Mark.<br><br><div><span class="gmail_quote">On 4/26/07, <b class="gmail_sendername"> \
Daniel Kristjansson</b> <<a \
href="mailto:danielk@cuymedia.net">danielk@cuymedia.net</a>> \
wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, \
204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> On Wed, 2007-04-25 at \
21:41 -0400, Chris Pinkham wrote:<br>> * On Wed Apr 25, 2007 at 07:28:19PM -0400, \
Daniel Kristjansson wrote:<br>> > If network usage is the problem, I think it \
might make sense to<br>> > change the preview generators concept of a locally \
accessible <br>> > video. You could use the information that the storage \
groups<br>><br>> Since the original preview generator code checked for the \
file<br>> locally, when I made the Storage Groups modifications, I made <br>> \
it force ProgramInfo::GetPlaybackURL() to check locally as well<br>> instead of \
honoring the AlwaysStreamFiles setting. Maybe we should<br>> honor that \
setting in the preview generator as well. This isn't <br>> directly \
tied to this issue, but it may affect some people who<br>> are seeing the \
issue.<br><br>I don't remember why, but streaming was a problem for \
the<br>preview generator. Maybe we can only do one preview at a <br>time when \
streaming? My frontends are always much more<br>powerful than the backends for HDTV \
playback, so having<br>many previews in flight increases throughput. I also \
tend<br>to put the drives in the frontends and NFS mount them on <br>the backend \
which makes seeking much faster during playback,<br>and the backend doesn't \
really need a whole lot of<br>performance out of the file system to write a stream of \
data.<br>I think we pretty much don't do streaming for previews, <br>we only do \
frontend generation if we can access the files<br>via the file system, and otherwise \
we do backend preview<br>generation on the backend that recorded the file and \
hence<br>has access to it via the file system. <br><br>> RE: where to generate the \
preview at...<br>><br>> I can see there may be benefits to generating it \
locally, but<br>> I've always preferred that that kind of thing be done on \
the<br>> backend that recorded the file. We could still honor the \
<br>> MasterBackendOverride setting and have the master generate the<br>> \
preview if that setting is on.<br><br>Ideally we should have an set a numeric limit \
on the number<br>of previews either the frontend or backend should do at a time; \
<br>say b2f1 on a balanced system with the drive on the backend,<br>b3f0 on a system \
where the frontend is slow and/or only has<br>access to recordings through the \
network, b0f4 where the backend<br>is slow and the frontend is fast and has direct \
access to the <br>files.<br><br>Another thing that has been bugging me about the \
preview<br>generator on the backend is that it can take down the whole<br>backend \
when ffmpeg segfaults when processing a broken<br>MPEG-2 file (DTV). I think we \
should spawn a separate process <br>to generate a preview on the backend since a \
backend crash<br>is so much worse than a frontend crash (you lose recordings,<br>and \
you may not notice for a while that the backend is gone).<br><br>-- \
Daniel<br><br>_______________________________________________ <br>mythtv-dev mailing \
list<br><a href="mailto:mythtv-dev@mythtv.org">mythtv-dev@mythtv.org</a><br><a \
href="http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev">http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev</a><br>
</blockquote></div><br>
_______________________________________________
mythtv-dev mailing list
mythtv-dev@mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic