cpinkham at bc2va
Apr 11, 2012, 9:06 AM
Post #2 of 3
* 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
mythtv-users mailing list
mythtv-users [at] mythtv