Mailing List Archive: MythTV: Dev

Ticket #4956: Make MythXML's GetProgramGuide return shows inclusively

Index | Next | Previous | View Threaded

chasedouglas.lists at gmail

Jul 8, 2008, 11:58 AM

Post #1 of 6 (1375 views)
Permalink

Ticket #4956: Make MythXML's GetProgramGuide return shows inclusively

As I've posted on the ticket itself (http://svn.mythtv.info/trac/ticket/4956
), I really need this simple patch applied. Could someone please take
a look at the patch and either apply it or state why it can't be
applied right now?

Thanks

mtdean at thirdcontact

Jul 8, 2008, 12:17 PM

Post #2 of 6 (1311 views)
Permalink

Re: Ticket #4956: Make MythXML's GetProgramGuide return shows inclusively [In reply to]

On 07/08/2008 02:58 PM, Chase Douglas wrote:
> As I've posted on the ticket itself
> (http://svn.mythtv.info/trac/ticket/4956), I really need this simple
> patch applied. Could someone please take a look at the patch and
> either apply it

Even if it's applied immediately, it likely won't go to -fixes, meaning
it won't be available "to the general public" until the 0.22 release.
That means if you want to write a client that's usable by 0.21(-fixes)
users, you'd have to write it to work with the "old" approach (and
support the "new" approach once available). If you're writing a client
for yourself, you can simply apply the patch to your own tree (though I
haven't tried lately, it should apply cleanly to either -fixes or trunk).

It is possible that the devs may include it in -fixes under a loose
definition of the word "fix" (since it seems that so far no clients have
begun heavily using MythXML's GetProgramGuide), but even then, if you
want to support 0.21 users, you may want to support the old approach so
you don't have to tell them they need SVN revision X or higher (or so
you don't have to respond to a bunch of "it doesn't work--I don't see
any shows listed" questions about your client).

> or state why it can't be applied right now?

I'm pretty sure it's just a time thing. There are somewhere around 600
open tickets, right now, after all.

Also, if you send an iPhone (based on your link to
http://trac2.assembla.com/mymote ) to Greg Estabrooks (the current owner
of the ticket), he may actually find this ticket to be higher priority
once he receives it. :)

Mike (a.k.a. sphery--the guy who posted the ticket :)
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

chasedouglas.lists at gmail

Jul 8, 2008, 12:35 PM

Post #3 of 6 (1301 views)
Permalink

Re: Ticket #4956: Make MythXML's GetProgramGuide return shows inclusively [In reply to]

On Jul 8, 2008, at 3:17 PM, Michael T. Dean wrote:

> Even if it's applied immediately, it likely won't go to -fixes,
> meaning
> it won't be available "to the general public" until the 0.22 release.

I don't follow the development of mythtv too closely, but wouldn't
this be the type of fix that would be intended for the -fixes branch?
If not, what types of fixes are meant for that branch.

> That means if you want to write a client that's usable by 0.21(-fixes)
> users, you'd have to write it to work with the "old" approach (and
> support the "new" approach once available). If you're writing a
> client
> for yourself, you can simply apply the patch to your own tree
> (though I
> haven't tried lately, it should apply cleanly to either -fixes or
> trunk).

I'm not writing a normal client. In fact, I don't use the mythtv
protocol at all. The reason I use the MythXML interface is because it
does not require any authentication or server setup (compared to
looking it up in the mysql db) and it does not require a mythtv
protocol match.

> Also, if you send an iPhone (based on your link to
> http://trac2.assembla.com/mymote ) to Greg Estabrooks (the current
> owner
> of the ticket), he may actually find this ticket to be higher priority
> once he receives it. :)

If only I had that kind of money...
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mtdean at thirdcontact

Jul 8, 2008, 1:04 PM

Post #4 of 6 (1303 views)
Permalink

Re: Ticket #4956: Make MythXML's GetProgramGuide return shows inclusively [In reply to]

On 07/08/2008 03:35 PM, Chase Douglas wrote:
> On Jul 8, 2008, at 3:17 PM, Michael T. Dean wrote:
>> Even if it's applied immediately, it likely won't go to -fixes,
>> meaning
>> it won't be available "to the general public" until the 0.22 release.
>>
> I don't follow the development of mythtv too closely, but wouldn't
> this be the type of fix that would be intended for the -fixes branch?
> If not, what types of fixes are meant for that branch.
>

The issue is that the current behavior isn't really "broken"--it just
works a bit differently from how one might expect (and differently from
how the Myth protocol works). I think when David Blain originally wrote
the code, he felt it was better for the "server" to trim out the extras
for the (possibly low-powered/low-resource) client rather than send
excess info (though he agreed in IRC to change it to make it symmetrical
with GuideGrid::GetProgramList() ).

So, to support the "old" approach, you can use the "summary" version of
the listings to get information about a range of times that's larger
than the listings to be displayed (i.e. perhaps an hour before and after
the displayed times) and, for channels with missing data, go even
farther back/forward for that particular channel as necessary to fill in
the blanks. And, if you need details for all shows, you can then use
the data from the summary to make the exact request you need on a
per-channel basis.

See http://www.gossamer-threads.com/lists/mythtv/dev/323174#323174 (and
the rest of the thread) for a bit more info on using GetProgramGuide.

>> That means if you want to write a client that's usable by 0.21(-fixes)
>> users, you'd have to write it to work with the "old" approach (and
>> support the "new" approach once available). If you're writing a
>> client
>> for yourself, you can simply apply the patch to your own tree
>> (though I
>> haven't tried lately, it should apply cleanly to either -fixes or
>> trunk).
> I'm not writing a normal client. In fact, I don't use the mythtv
> protocol at all. The reason I use the MythXML interface is because it
> does not require any authentication or server setup (compared to
> looking it up in the mysql db) and it does not require a mythtv
> protocol match.
>

Yeah, you're actually doing things the right way. Unfortunately, you
just happen to be pretty much the first person to do it the right way,
so you get to experience the growing pains as the XML interface catches
up with "the real world."

>> Also, if you send an iPhone (based on your link to
>> http://trac2.assembla.com/mymote ) to Greg Estabrooks (the current
>> owner
>> of the ticket), he may actually find this ticket to be higher priority
>> once he receives it. :)
>>
> If only I had that kind of money...

Yeah.

Mike
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

chasedouglas.lists at gmail

Jul 8, 2008, 1:24 PM

Post #5 of 6 (1290 views)
Permalink

Re: Ticket #4956: Make MythXML's GetProgramGuide return shows inclusively [In reply to]

On Jul 8, 2008, at 4:04 PM, Michael T. Dean wrote:

> The issue is that the current behavior isn't really "broken"--it just
> works a bit differently from how one might expect (and differently
> from
> how the Myth protocol works). I think when David Blain originally
> wrote
> the code, he felt it was better for the "server" to trim out the
> extras
> for the (possibly low-powered/low-resource) client rather than send
> excess info (though he agreed in IRC to change it to make it
> symmetrical
> with GuideGrid::GetProgramList() ).
>
> So, to support the "old" approach, you can use the "summary" version
> of
> the listings to get information about a range of times that's larger
> than the listings to be displayed (i.e. perhaps an hour before and
> after
> the displayed times) and, for channels with missing data, go even
> farther back/forward for that particular channel as necessary to
> fill in
> the blanks. And, if you need details for all shows, you can then use
> the data from the summary to make the exact request you need on a
> per-channel basis.

Ahhh, this clears up a lot. I now understand what's really going on,
and the fix is obvious but when you're in the mindset that you are
right and the upstream is wrong sometimes the obvious fix doesn't get
a chance to form in the mind...

> Yeah, you're actually doing things the right way. Unfortunately, you
> just happen to be pretty much the first person to do it the right way,
> so you get to experience the growing pains as the XML interface
> catches
> up with "the real world."

Good to know.
_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

mtdean at thirdcontact

Jul 8, 2008, 2:02 PM

Post #6 of 6 (1301 views)
Permalink

Re: Ticket #4956: Make MythXML's GetProgramGuide return shows inclusively [In reply to]

On 07/08/2008 04:24 PM, Chase Douglas wrote:

> On Jul 8, 2008, at 4:04 PM, Michael T. Dean wrote:
>
> > The issue is that the current behavior isn't really "broken"--it
> > just works a bit differently from how one might expect (and
> > differently from how the Myth protocol works). I think when David
> > Blain originally wrote the code, he felt it was better for the
> > "server" to trim out the extras for the (possibly
> > low-powered/low-resource) client rather than send excess info
> > (though he agreed in IRC to change it to make it symmetrical with
> > GuideGrid::GetProgramList() ).
> >
> > So, to support the "old" approach, you can use the "summary"
> > version of the listings to get information about a range of times
> > that's larger than the listings to be displayed (i.e. perhaps an
> > hour before and after the displayed times) and, for channels with
> > missing data, go even farther back/forward for that particular
> > channel as necessary to fill in the blanks. And, if you need
> > details for all shows, you can then use the data from the summary
> > to make the exact request you need on a per-channel basis.
>
> Ahhh, this clears up a lot. I now understand what's really going on,
> and the fix is obvious but when you're in the mindset that you are
> right and the upstream is wrong sometimes the obvious fix doesn't
> get a chance to form in the mind...

:)

And, if you're concerned about efficiency, it should be easy enough to
modify your app to auto-detect whether the "long requests" are required
by sending a single-channel query with the same starttime and endtime.
If you get any shows, you'll know the server supports the inclusive
listings. I don't know the iPhone SDK, but I'm guessing there's a way
you could store a setting so you only need to check once (or, if it's
not the new/inclusive behavior, check once per <timeframe>).

> > Yeah, you're actually doing things the right way. Unfortunately,
> > you just happen to be pretty much the first person to do it the
> > right way, so you get to experience the growing pains as the XML
> > interface catches up with "the real world."
> Good to know.

Oh, I should probably also mention that I'm not a dev, so all my
guessing about whether it will be committed to -fixes, etc., may mean
nothing. If nothing else, I hope I've given you a workable approach for
your July 11 deadline.

BTW, thanks for the work you're doing. I'm sure many users with iPhones
will be very happy to see the app.

Mike

_______________________________________________
mythtv-dev mailing list
mythtv-dev [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads