<br><br><div class="gmail_quote">On Mon, Dec 21, 2009 at 11:44 AM, Bill Bogstad <span dir="ltr"><<a href="mailto:bogstad@pobox.com">bogstad@pobox.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Do you use SchedulesDirect for listings? If so, why did you decide to<br>
pick "-" rather then the<br>
more (to me) obvious "." as the channel seperator? Should this be<br>
documented by MythTV<br>
or by SchedulesDirect?<br></blockquote><div><br><br>Yes, I do use SD for listings. I don't recall ever changing the channel separator, I probably just used the default. Everything mapped properly for me, I haven't had to mess with XMLIDs or the like at all. <br>
<br></div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A classic example of the "it's not really mythtv that is at fault"<br>
response. It's some outside program or entity. It may not be fair to<br>
MythTV to blame it for all of my problems, but end-users aren't going<br>
to care. By the way, did you miss the part of my rant about nine<br>
submenus of undocumented pages of mythtv-setup's 'General' menu? I<br>
forgot to mention in my original note about the fun I had when I was<br>
trying use user jobs to do transcoding for my MediaMVP and didn't want<br>
to use the built-in transcoding system because: 1) I didn't understand<br>
what it did. 2) I wanted to keep the original recordings around for<br>
when I got an HD capable FE. Now why I wanted to keep two copies of a<br>
recording around wasn't directly MythTV related, but figuring out user<br>
jobs was. I admit that this particular project was relatively easy<br>
compared to the ones I did list.<br></blockquote><div><br><br>How is "It's not MythTVs fault that Comcast screws with channel mappings on a whim" not a valid response? What, exactly, do you propose the devs do about it? Do you know of a way to map that data programmaticly? If there is a clean way to deal with it, by all means, write up a bug report and I'm sure someone will look into it. I'm not a Myth dev and I haven't read that code, so I can't really offer more than that. <br>
<br>No, I didn't miss that part, I simply didn't find the "General" menu difficult to understand. There is help text in there, and google filled in any missing bits I needed. I don't know about the transcoding bit, I never bothered with that. I just used FEs that were capable of playing the recordings I was making. I never did SD, I started using Myth when the HDHR came out, so I have always worked with ATSC digital. Even HD MPEG2 isn't all that difficult to play back, and I've never had a problem with those files. If I were to try what you are talking about, I probably wouldn't use Myth at all as it doesn't really seem suited to it. I'd just use the rename script to give the files reasonable names and write my own script to transcode them, keeping the originals around. <br>
<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
My change over from DataDirect? to SchedulesDirect was a BREEZE<br>
compared with the analog/digital and on much less warning for all<br>
concerned. And if there was more modularity/documentation of<br>
interfaces in MythTV then on-the fly transcoding (for example) is<br>
something that a non-core developer could work on. Yes, I know that<br>
there is/was? a project to work on this. At least one of the ones I<br>
heard of had to do with the Iphone and the developer of that one<br>
decided to take a different route in the end and has stopped working<br>
on it. That may be different then the one that was just posted about<br>
this week.<br></blockquote><div><br><br>While that may be a valid point, perhaps those writing the code just aren't that worried about that particular issue? Even the Linux kernel doesn't maintain standard interfaces between versions, much to the dismay of some. I will say that the few times I've been interested in something enough to dig in the code, I've had little trouble finding the parts I was interested in. <br>
</div></div>