[mythtv-users] HLS file expiration

[Chris Pinkham]

* On Wed Apr 11, 2012 at 08:36:39AM -0400, George Nassas wrote:
> Hi, I notice that eventually the backend removes the files associated
> with an http live stream. Problem is it doesn't remove the database entry
> for the stream itself so it continues to appear in the list returned

There is no code to auto-expire HLS stream files.  The only cleanup done
on these files is when you delete a stream which should delete the files
along with the DB entry.  Perhaps you have something else cleaning up
~/.mythtv/tmp/hls.  Is your home directory persistent?

> Also related is when you delete a TV recording its HLS files continue
> to exist. That sounds wrong since, without the recording's metadata,
> there's no way to know what a stream refers to. Probably the same problem
> exists with videos. I guess the right behaviour is to do a broad delete
> when source material disappears.

HLS supprt is a work in progress, and currently there is nothing to tie
together a recording or video and it's HLS stream.  This glue will come
later and be made easier by the planned file table changes.

> Personally I'd like control over expiration policy. I'm using streams
> as a way to have an iPad-compatible copy on tap while still keeping
> a full res version around for my main rig & it's not amusing when the
> iPad version gets yanked out from under me. It's not like I need the
> disk space.

Once the file table schema changes are in place, you'll actually be able
to have a second copy of a recording in .mp4 format and MythTV will
track it right along with the original .mpg file.  Tracking a HLS
stream will also be possible once we get the glue in place.

> I can open bugs but maybe there needs to be a brief discussion on what
> is the good behaviour?

The issue isn't ideas, it's time.  I haven't had time leading up to 0.25
to add even 1/4 of the items on my HLS TODO list, but I didn't want to
rip out the existing HLS support prior to release either.  I figured
the existing support is usable as-is and I'll add more glue post 0.25.

> Oh, also, the RemoveRecorded http api doesn't take a parameter for
> allow rerecord. The code seems to do a permanent delete. Is this an
> oversight or intentional? I'd like to have the option & might even be
> able to supply a patch if people agree.

I think this was probably an oversight.  A patch to allow this should
be welcome.

--
Chris