<html>
<head>
<meta content="text/html; charset=ISO-8859-1"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
On 1/21/2012 10:06, George Nassas wrote:
<blockquote cite="mid:51B64C82-538C-4667-ABDA-27CBFD73D4EF@mac.com"
type="cite">
<div>
<div>On 2012-01-21, at 9:40 AM, Michael T. Dean wrote:</div>
<br class="Apple-interchange-newline">
<blockquote type="cite"><span class="Apple-style-span"
style="border-collapse: separate; font-family: Helvetica;
font-style: normal; font-variant: normal; font-weight:
normal; letter-spacing: normal; line-height: normal;
orphans: 2; text-align: -webkit-auto; text-indent: 0px;
text-transform: none; white-space: normal; widows: 2;
word-spacing: 0px; -webkit-border-horizontal-spacing: 0px;
-webkit-border-vertical-spacing: 0px;
-webkit-text-decorations-in-effect: none;
-webkit-text-size-adjust: auto; -webkit-text-stroke-width:
0px; font-size: medium; ">A planned change to the schema
will allow multiple media files for any<span
class="Apple-converted-space"> </span><br>
given recording or video.</span></blockquote>
</div>
<br>
<div>Ooooo, that's a welcome development. Can you tell more? Like,
when it might arrive.</div>
</blockquote>
<br>
It's not anything particularly new. It's been in some planning
stage or another for something like three years now, and has been
mentioned multiple times on this mailing list. The plan is to start
implementing it shortly after the 0.25 release, giving the bulk of
the 0.26 development cycle for ironing out any lingering bugs in the
transition. The idea centers around having one single table to
define all file content MythTV has access to. Then you have a
series of cross-reference tables that can map multiple files to a
single metadata entry, and multiple metadata entries to a single
file.<br>
<br>
<blockquote cite="mid:51B64C82-538C-4667-ABDA-27CBFD73D4EF@mac.com"
type="cite">
<div>In particular, will this tie together streaming with
recording metadata? Right now the stream APIs are oriented
around filenames while recording APIs want chanid/starttime.
When you have a stream there's no obvious way to know what
recording it pertains to without keeping your own filename ->
metadata structure. That's easy enough but it feels like there's
a missing link.</div>
</blockquote>
<br>
I'm not sure I understand what you're asking. The new Services API,
and the old MythXML before it, both use chanid and starttime in the
recording access methods. On the other hand, the backend protocol
might use filenames to start the transfer, but all subsequent calls
reference a far more ambiguous socket id, which is arbitrarily
generated, and bares no reference to anything in the metadata. If
you're looking for a QUERY_FILETRANSFER subfunction that returns a
ProgramInfo block for that socket id, I honestly see no utility in
that. As you say, it's easy enough to maintain that link client
side.<br>
</body>
</html>