<br><br><div class="gmail_quote">On Wed, Feb 1, 2012 at 12:31 PM, Raymond Wagner <span dir="ltr"><<a href="mailto:raymond@wagnerrp.com">raymond@wagnerrp.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div class="im">On 2/1/2012 11:41, Matt Emmott wrote:<br>
> In my experience, Myth will always record to the first disk in the SG<br>
> until that one fills up, and then move on to the second. My thought<br>
> was that since Myth could see the second disk's free space, it would<br>
> remove recordings as needed.<br>
<br>
</div>That's not at all the case. MythTV uses a disk scheduler to place<br>
recordings on storage, with four different modes. The "free space"<br>
scheduler just blindly records to the disk with the most free space, and<br>
the "percent free space" scheduler behaves similarly as would be<br>
expected. The "disk I/O" scheduler will record to the disk with the<br>
lowest current load, allowing variable weights applied for concurrent<br>
recording, playback, commercial flagging, and transcoding, variable<br>
initial weights for local versus network filesystems, and even per<br>
directory weights. The default "combination" scheduler is a mixture<br>
between the I/O and free space methods.<br>
<br>
You could weight the remote disk very highly (meaning low probability of<br>
use), but that's really just a clumsy way to do it, and abuse of the<br>
mechanism.<br>
<div class="im"><br>
> I'm going to revisit my idea of mounting the drives via NFS, and at<br>
> that point the symlinks should work. I hope that this won't have any<br>
> ill effects later on down the road... Say in six months when I want to<br>
> upgrade to .25-fixes or something, and Myth freaks out when all the<br>
> recordings are actually symlinks.<br>
<br>
</div>Symlinks are really just a bad way to do things, especially when MythTV<br>
has a built in mechanism for doing this, and has had such since Storage<br>
Groups were added in 0.21. You can define your own storage group<br>
names. Recordings store which storage group they are expected to be in,<br>
however when searching for files, MythTV will fall through to searching<br>
every non-special (i.e. Videos) storage group to find the content. Set<br>
all your recording rules to store to one storage group, move it to a<br>
path in a different storage group, and preferably update the group name<br>
in the database. It would also be good to check inuseprograms to make<br>
sure you aren't pulling the file out from under something else.<br>
<br>
Recordings will go to the group you want it to, while your "archive"<br>
group will be left untouched. MythTV still has control over the file<br>
should you wish to delete it. Even the autoexpire methods can still be<br>
made to work, setting the minimum free space to something larger than<br>
your largest expected file (maybe a 20GB, 3hr movie?), such that as new<br>
content is archived in, old content will be deleted to maintain that<br>
free space.<br>
_______________________________________________<br>
<br></blockquote><div><br>The problem (well, challenge, no offense intended) is two-fold with what I want to accomplish. First, I want filenames that can be queried against a tv listings database so aggregators like XBMC, Boxee and Plex can index and display the episode descriptions to the end user. Second, I want this to happen to _all_ of my recordings seamlessly, not just those I plan to archive for the long-term. The latter could certainly be accomplished by setting up specific recording groups for shows I want to keep entire sets of, but the issue would still be that they are stored in the Myth-esque naming convention, so if I connected via Samba etc, I couldn't easily see which file is which episode.<br>
<br>I haven't used MythArchive since around version 0.20 or .21 - Perhaps it has more features now and can do some of the things I'm looking for. I'll head off and read the wiki but first, a ponderous tome:<br>
<br>I've used Mythlink.pl in the past to periodically sweep through and set up symlinks TO my recordings, and then pointed my aggregators to its "show_names" folder. Unfortunately, I end up with a huge flat directory of vague filenames based purely on show and recorded date. <br>
<br>The more I think about this, it seems like what I'm looking for is a version of <a href="http://mythlink.pl">mythlink.pl</a> that would use whatever magic MythicalLibrarian uses to get episode metadata, and then create symlinks to those episodes with the naming convention that the aggregators could recognize. I suppose there would have to be some logic in there that would check the source directory periodically to remove the symlink when the original recording was deleted by Myth, but otherwise it would theoretically work with the aggregators with the added benefit of leaving the Myth recordings where they belong. <br>
<br>This is the point where I throw up the IANAC (I am not a coder) badge and hide behind it, but does such a thing sound possible?<br></div></div><br>