[mythtv] new feature saving the ring buffer

[Ketan Patel]

Marcelo Toledo wrote:
> I am looking forward in implementing a new feature that
will save the
> ring buffer. What it will do: While watching live tv you
might save what
> has past and still in the ringbuffer, so you will press a
key combination
> and it will store what have been recorded as a recorded
show with the name
> "Live TV date hour".

i've been setting up a couple of myth box and am generally 
happy, with some exception.  as with others, i'm having
problems with myth crashing and hesitating when the
ringbuffer gets extremely large (for EXT3 FS).  moreover,
like others, i would like to see the following features as
well: "post-record" tv program that has passed and allow
multiple remote frontends to watch the same stream
independently.  finally, i find it troubling to lose video
stream when changing channels, mythfrontend
terminates/crashes, or by jumping in/out of myth main menu.
  

i've given the live-tv buffer some thought and have devised
an outline of an implementation that might resolve my
issues.  i have to admit, though, that i'm not familiar
with how the buffer is currently implemented.  moreover, 
my background is scientific programming not app
programming.  nor do i know the nitty-gritty of the
linux-based filesystems, so i am unable to evaluate the
practicality of this implementation.  nevertheless, i'm
throwing this up as a suggestion for someone else to
consider and implement.  any comments with regards to
feasibility and usability would be welcomed. 

in essence, i'm thinking of a buffering scheme implemented
as persistent "short-term" recording, one for each tuner
and independent of the tuner channel or frontend state. in
many ways, it is like a regular recording except with very
special auto-expire policies.   more importantly, scheduled
recording and live-tv watching is sourced exclusively from
this "short-term" recording.  live-tv watching is handled
by watching the contents of the short-term recording just
as one does currently with normal recordings.  moreover,
any number of frontends can access the same recordings. 
with regards to scheduled recording, it would be done in
background by copying the appropriate portions of the
short-term recording as it becomes available.  recording of
live-tv occurs in background and does not affect watching
tv with the exception of locking out channel-changing.  i
think such an persistent buffering scheme can add
significant robustness and flexibility to myth in recording
and live-tv watching.

the basic rules of the implementation would be as follows:

- NEVER STOP buffer streaming video!  backend should
continuously buffer video stream without regards to channel
or state of mythfrontend.

- maintain an independent buffer for each tuner in the myth
network (user may limit number of simultaneously encoded
video for underpowered, multituner CPUs)

- NEVER DELETE the buffer file!  recycle disk space by
replacing oldest buffer segment with newest.  if channel
changes just jump to end of the buffer file.  if user
returns to myth menu while watching live tv, save position
as is done when watching recording, but when returning to
live tv, jump to END of buffer; allow user to jump to
previously saved position (or add "Resume TV" button)

- maintain journal file of time-stamp and channel/program
of buffer file contents; mitigate hicups by accessing of
large files by segmenting the buffer into smaller files,
preferably sync'd to the system clock (i.e. segment buffer
on the 5's or 15's or 30's) rather than byte size.

- use tokens (per tuner) for assigning privilege of
changing tuner channel.  tuner token may be held by either
frontend or backend.  multiple tokens may be held by one
mythend (front or back).  any mythend may remotely usurp
token thru proper safegaurd.  watching live-tv is NOT
limited to token holder; any mythend can view the contents
of the buffer. 

- user schedules recording of program (past, present or
future) as normal, and it is queued up as normal. myth
provides option to record partrial segment program.

- if start-time of any un-executed scheduled recording has
passed, backend spawns a recorder child-process.  if the
end-time of program has NOT passed, backend should take the
tuner token and change the channel.  allow multiple
recorder child-process to be spawned 

- recorder child-process looks at the contents of the
buffer and appends appropriate portions, corresponding to
desired tv program, into a permanent file.  child-process
continues looking at buffers until all of the the
appropriate buffer is copied.  recording processes could be
simplified if the record child-process waits until a
segment file of the buffer file is complete (OR when
recording end-time passes) before copying the contents to a
permanent file.  

- live TV watching and related functions (browse EPG,
schedule recording, etc.) are allowed at ANY and ALL times,
concurrent to recorder child-processes.

-END-


this implementation makes the buffer a truly persistent
ring buffer.  the pros and cons as i see it are as follows:

the advantages:
- no lost video!
- allows recording of program as an after-thought, even
program that has passed altogether and/or live-tv is being
concurrently recorded
- allows user to fully review past video stream without
officially recording it
- allows simultaneous, independent use of multiple
frontends  with one video stream
- allows the user to watch live tv and schedule recordings
as normal, regardless of concurrent recording sessions
- mitigates hick-ups due to handling extremely large files
by segmenting buffer into smaller segments


the disadvantages:
- complicates mythbackend with additional journalling
- ringbuffer will permanently occupy the allocated disk
space without relinquishing it
- might add some additional CPU load to backend


anyways, that's my idea.  if you read this far, thanks!
please feel free to comment.  i really hope this, or
something equally flexible, is implemented.


	
		
__________________________________ 
Yahoo! Mail - PC Magazine Editors' Choice 2005 
http://mail.yahoo.com