[mythtv-users] Integrating non-traditional program sources into MythTV (won't tell you what it 'was:')

Andrew Close aclose at gmail.com
Wed Jul 23 13:35:22 UTC 2008


On Wed, Jul 23, 2008 at 12:14 AM, David Shay <david at shay.net> wrote:
> On Tue, Jul 22, 2008 at 5:05 PM, Jay R. Ashworth <jra at baylink.com> wrote:
>> On Tue, Jul 22, 2008 at 02:55:23PM -0500, Kevin Kuphal wrote:
>>>    It is an interesting conundrum. It really can't be integrated
>>>    into searches per se because it isn't guide data.
>>
>> Expand on the assumptions you make within "it isn't guide data", would
>> you?
>>
>>>                                                         It doesn't fit
>>>    in the traditional role of the program guide because the programs
>>>    are instantly available without notice. How did you envision this
>>>    appearing? Would you expect to see feed "recording rules" along
>>>    side normal rules in the Recording Priorities list?
>>
>> Well, I would just treat them as channels, each with it's own
>> (pseudo-)tuner, and the "future data" is just the available programs.
>>
>> Remember: some RSS feeds only show the latest items, but items
>> announced earlier can still be retrieved.
>>
>> So given that, I don't think it's unreasonable to merely simulate a
>> program guide, dropping each new item onto the grid for it's 'channel'
>> as of when you first see it, and droping multiple items in sequence if
>> more than one thing appears simultaneously.
>>
>
> To me, this analogy breaks down in two key ways.  From a UI
> standpoint, made-up times just would seem kind of strange.  Do you
> just list all available content with invented times starting from
> right now, without repeats, then just stop the grid when you run out
> of content?  Do you use the "air" date from the content (but that
> would always be in the past...). Seems kind of odd/incongrous.
>
> Then, from a code standpoint, this is very much
> totally-unscheduler-like.  Having spent a few days in the scheduler
> code working on a patch for something else, I can confidently say that
> this kind of thing would be a total rewrite of the pretty much the
> entire scheduler.  It is completely reliant on times and dates as a
> key component of its logic, and making ones up just to effectively do
> some regexp searching and intelligent downloading/DB inserting seems
> like overkill.
>
> I can see a different type of search screens being setup, with some
> similar constructs around searching by title, and some similar things
> like duplicate checking, but it's still enough different from a
> scheduled broadcast model to require a different backend data model
> and GUI as well, in my opinion.

the program guide definitely makes sense for broadcast programs (i.e.
tv) especially since that's a very common or 'standard' way of viewing
program data even if you're not familiar with Myth.  however, i agree
that it may not be the best way to display other media that isn't
necessarily on a time schedule.  but something similar, say a program
matrix, could be potentially used with the same sort of look and feel.
 you could probably even mix and match between traditional broadcast
'tv' and nuveux media (podcasts, vodcasts, webcasts, etc).  the user
doesn't necessarily need a time/date grid to know what's available for
recording/capturing/downloading.  they just need to know what is
available and that it will show up on their system in the next week or
so.  not knowing anything about the code for the existing schedule
guide, i'd still guess that this would be best implemented separately.

-- 
Andrew Close


More information about the mythtv-users mailing list