[mythtv] Suggestion for improving SLOW channel changinginLiveTV.....

Carlos Fdez Manteiga churly at gmail.com
Fri Sep 9 20:08:04 UTC 2005


What about using the same ringbuffer when changing the channel?

I mean: Instead of deleting the old ringbuffer, and creating a new one
starting with the new channel, using the same buffer and "marking" the
beggining of the new channel, so yo can't rewind past that point.

Also it would be good that the ringbuffer never get deleted (as an
option). Deleting and creating a new one adds a lot of overload, and
my MythTV like many others has its own dedicated cache partition.

Sorry if it's not very comprehensible, but english it's not my lang :)

Greets!

2005/9/9, Pascal Favre <Pascal.Favre at gmx.net>:
> >  That sounds similar to what I was suggesting.  I don't see why
> > there needs to be an element of time involved though... just keep on
> > displaying realtime data until there's a reason not to
> 
> When zapping through I do not want the extra load for setting up a new ringbuffer.
> If this are milliseconds, I agree with you.
> 
> ----- Original Message -----
> From: "Cory Papenfuss" <papenfuss at juneau.me.vt.edu>
> To: "Development of mythtv" <mythtv-dev at mythtv.org>
> Sent: Friday, September 09, 2005 7:48 PM
> Subject: Re: [mythtv] Suggestion for improving SLOW channel changinginLiveTV.....
> 
> 
> > On Fri, 9 Sep 2005, Pascal Favre wrote:
> >
> >> I never use LiveTV because changing channels are to slow.
> >> I suggest to have an option for 'fast-changing-channels' where the input is
> >> immediately directed to the output for the specific amount of time (say 1
> >> minute).
> >> This allows fast changing channels.
> >> After this time the normal LiveTV behaviour starts, but we still keep
> >> receiving the currently received input data.
> >> The first time we halt or rewind to move over to the ringbuffer behaviour.
> >>
> >> About the option when provided in seconds: 0 = normal LiveTV behaviour, >0 =
> >> seconds to start LiveTV behaviour.
> >>
> >> Just an idea. When implemented I will use LiveTV.
> >> Pascal
> >>
> >  That sounds similar to what I was suggesting.  I don't see why
> > there needs to be an element of time involved though... just keep on
> > displaying realtime data until there's a reason not to.  Hit pause and
> > there's a bit of lag while the display transitions from raw capture to
> > decoded ringbuffer.  From then-on, it's ringbuffer until you change
> > channel.
> >
> >  Interesting to hear that the ivtv drivers allow for simultaneous
> > raw and encoded data.  I wasn't sure if the hardware could transfer both
> > at the same time over the PCI bus.  The potential issue with this solution
> > would be the increase in PCI bus traffic.  If two or three bttv-based
> > cards can already exist in one system, though, this would be easier than
> > that.
> >
> > -Cory
> >
> > --
> >
> > *************************************************************************
> > * Cory Papenfuss                                                        *
> > * Electrical Engineering candidate Ph.D. graduate student               *
> > * Virginia Polytechnic Institute and State University                   *
> > *************************************************************************
> >
> >
> 
> 
> --------------------------------------------------------------------------------
> 
> 
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> 
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev at mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> 


-- 
CINeol - http://www.cineol.net


More information about the mythtv-dev mailing list