<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    On 1/31/2012 14:07, Matt Emmott wrote:
    <blockquote
cite="mid:CAGHPk0boWBmL74N7nKGH4+HJCcrt2wqiTX9MG7hpfytAnVHjBw@mail.gmail.com"
      type="cite">I think I've come up with a solution, but I was
      wondering if it will cause issues. My old recording directory is
      /var/lib/mythtv/recordings. It's a local 50GB partition running
      EXT3, I believe. I have found using <a moz-do-not-send="true"
        href="http://mythlink.pl">mythlink.pl</a> that I can create
      symlinks in that folder that will point to the destination CIFS
      share of /var/lib/mythtv/recordings3 (Don't ask where recordings2
      went, it's a long story). So, I could repoint my storage group to
      recordings, have ML move the files to recordings3/Episodes, and
      leave symlinks behind. My question is, what kind of weird side
      effects would I run into? I've already told the BE to follow
      symbolic links when deleting files, so that shouldn't be an issue.
      I guess my biggest concern would be with the reported space
      available to myth. My /recordings3 folder is a 2TB mount, while
      /recordings is only 50GB. I have Myth set to leave 1GB free at all
      times. How will Myth calculate its available storage? Is it smart
      enough to see the true destination's space used? Or will it always
      think there is 50GB free, or some other weird scenario that I
      haven't thought of yet?<br>
    </blockquote>
    <br>
    MythTV will be recording directly to the 50GB partition.&nbsp; Hopefully
    this isn't a partition on the same disk that holds your database,
    and is not mounted directly on the recording path.&nbsp; Since your
    average digital recording will be 6-8GB/hr, you've got less than
    eight hours of recording time before MythTV starts expiring
    content.&nbsp; That could potentially be filled by a single block of
    primetime TV.&nbsp; You must run mythicalibrarian at least that
    frequently.<br>
    <br>
    When mythicalibrarian runs, it will copy the content over CIFS to
    your Windows server, leaving behind a symlink and freeing up room.&nbsp;
    Honestly, I got lost in a mess of bash, writing new bash scripts in
    huge one-liners, that it the runs through to do the moving, but in
    the event you fill your destination filesystem, the best case
    scenario is that the content stays on your recording disk and
    mythicalibrarian fails out gracefully.&nbsp; As before, after a couple
    hours of recording, your filesystem will be filled, and MythTV will
    begin expiring content.<br>
    <br>
    So what will happen when you start expiring content?&nbsp; Deletes follow
    symlinks, but the autoexpirer knows nothing of that.&nbsp; All it knows
    is how large the file is, and in what order it is for deletion.&nbsp; As
    you drop below 1GB (or higher if recording), the expirer will kick
    in.&nbsp; Default rate is every fifteen minutes, but as you close in on
    empty, that will accelerate to every three minutes.&nbsp; On each pass,
    it will delete a recording.&nbsp; Since it doesn't know deleting a
    symlink is of no worth, it will simply start working through your
    archived recordings over CIFS, clearing out the lowest ranking
    (usually the oldest) recordings.&nbsp; Your recording filesystem will run
    out of space, the recording will fail, and the autoexpirer will just
    continue happily deleting those symlinks and emptying your CIFS
    share until it finally gets to your real recording directory,
    leaving only the latest six or seven hours of recordings.<br>
  </body>
</html>