Mailing List Archive: MythTV: Users

A hope regarding the new SchedulesDirect methodology

Index | Next | Previous | View Threaded

ian at duckland

Aug 8, 2007, 6:01 PM

Post #1 of 20 (2403 views)
Permalink

A hope regarding the new SchedulesDirect methodology

I believe that this was brought up before, but I don't recall seeing an
answer... (okay - I skipped over a lot of the messages. ;) )

Anyhoo...

In my myth setup, I have to use 2 Z2L accounts in order to get my
listings. I'd just like to remind the powers-that-be that there may be
many people out there in the same scenario, and hope that we wouldn't
have to sign up twice to SchedulesDirect to get the equivalent
functionality. I always found that to be a peculiar aspect of
labs.zap2it.com in that one could only choose one listing of each type
from a given account, so I couldn't have say...

(in the SF Bay Area)
1. Direct cable feed (up to channel 83)
2. DCT-2000 feed over RCA (up to channel 5xx)
3. DVB feed
4. DCT-6200 feed over firewire (19x and 7xx HD channels)

Especially 3 & 4 on the same listing... wasn't possible...

Like I said - I'm just hoping that it's taken into account...

-I

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

trgreer at gmail

Aug 8, 2007, 6:10 PM

Post #2 of 20 (2351 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

On 8/8/07, Ian Forde <ian [at] duckland> wrote:
>
> I believe that this was brought up before, but I don't recall seeing an
> answer... (okay - I skipped over a lot of the messages. ;) )
>
> Anyhoo...
>
> In my myth setup, I have to use 2 Z2L accounts in order to get my
> listings. I'd just like to remind the powers-that-be that there may be
> many people out there in the same scenario, and hope that we wouldn't
> have to sign up twice to SchedulesDirect to get the equivalent
> functionality. I always found that to be a peculiar aspect of
> labs.zap2it.com in that one could only choose one listing of each type
> from a given account, so I couldn't have say...
>
> (in the SF Bay Area)
> 1. Direct cable feed (up to channel 83)
> 2. DCT-2000 feed over RCA (up to channel 5xx)
> 3. DVB feed
> 4. DCT-6200 feed over firewire (19x and 7xx HD channels)
>
> Especially 3 & 4 on the same listing... wasn't possible...
>
> Like I said - I'm just hoping that it's taken into account...

That's a good point. I have a combination of DCT-6xxx boxes via firewire
and and HDHomeRun. With Zap2it, I needed to create two accounts to get the
listings.

Hopefully, schedulesdirect.org will have a neat way to do that through a
single account.

Tom

rmeden at yahoo

Aug 8, 2007, 8:02 PM

Post #3 of 20 (2356 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

On 8/8/2007 8:01 PM, Ian Forde wrote:
> In my myth setup, I have to use 2 Z2L accounts in order to get my
> listings. I'd just like to remind the powers-that-be that there may be
> many people out there in the same scenario, and hope that we wouldn't
> have to sign up twice to SchedulesDirect to get the equivalent
> functionality. I always found that to be a peculiar aspect of
> labs.zap2it.com in that one could only choose one listing of each type
> from a given account, so I couldn't have say...
>
> (in the SF Bay Area)
> 1. Direct cable feed (up to channel 83)
> 2. DCT-2000 feed over RCA (up to channel 5xx)
> 3. DVB feed
> 4. DCT-6200 feed over firewire (19x and 7xx HD channels)
>
> Especially 3 & 4 on the same listing... wasn't possible...
>
Can you elaborate a bit and include actual lineup names not local
physical device names?

I have confirmed with both Z2L and SD, I could add "DirectTV" and
"DirectTV Dallas". (both Satellite)

If you're talking wanting to add a single lineup twice with different
stations added/removed, that limitation still exists and is caused by
some low level settings shared by both platforms.

The solution is to filter channels on the client side. Maybe the
capability will be added to the native myth grabber, but if not, feel
free to use the XMLTV grabber as it can filter at the client level. I
believe current versions of the myth XMLTV loader finds all the
"special" fields that Z2L provided, and XMLTV put in "strange" places.
If they missed some, I'm sure I can work it out with them.

Robert
XMLTV
Schedules Direct.

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

ian at duckland

Aug 8, 2007, 8:41 PM

Post #4 of 20 (2356 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

On Wed, 2007-08-08 at 22:02 -0500, Robert Eden wrote:
> On 8/8/2007 8:01 PM, Ian Forde wrote:
> > In my myth setup, I have to use 2 Z2L accounts in order to get my
> > listings. I'd just like to remind the powers-that-be that there may be
> > many people out there in the same scenario, and hope that we wouldn't
> > have to sign up twice to SchedulesDirect to get the equivalent
> > functionality. I always found that to be a peculiar aspect of
> > labs.zap2it.com in that one could only choose one listing of each type
> > from a given account, so I couldn't have say...
> >
> > (in the SF Bay Area)
> > 1. Direct cable feed (up to channel 83)
> > 2. DCT-2000 feed over RCA (up to channel 5xx)
> > 3. DVB feed
> > 4. DCT-6200 feed over firewire (19x and 7xx HD channels)
> >
> > Especially 3 & 4 on the same listing... wasn't possible...
> >
> Can you elaborate a bit and include actual lineup names not local
> physical device names?

Okay - here goes - BTW - I was wrong in my summary above - 3&4 coexist
just fine... it's a different conflict..

I have 2 accounts:

Account 1 has 2 listing types:
Cable - "attached" to 2*PVR 150 cards
Cable Digital - "attached" to the DCT-2000

Account 2 has 2 listing types:
Cable Digital - "attached" to a DCT-6200 - some of the DCT-2000 channels
don't come through via firewire (5C encryption), so I had to disable
them. But this lineup/tuner can accept the HD channels that the
DCT-2000 can't.
Local - "attached" to a PCHDTV 3000 card - this is for my QAM channels
over comcast, so it's just the DT HD channels

> I have confirmed with both Z2L and SD, I could add "DirectTV" and
> "DirectTV Dallas". (both Satellite)
>
> If you're talking wanting to add a single lineup twice with different
> stations added/removed, that limitation still exists and is caused by
> some low level settings shared by both platforms.

That's what I'm talking about - especially applicable when one has 2
cable boxes with different capabilities...

> The solution is to filter channels on the client side. Maybe the
> capability will be added to the native myth grabber, but if not, feel
> free to use the XMLTV grabber as it can filter at the client level. I
> believe current versions of the myth XMLTV loader finds all the
> "special" fields that Z2L provided, and XMLTV put in "strange" places.
> If they missed some, I'm sure I can work it out with them.

I think I see what you mean - so I should have one "unified" listing,
then use the channel editor in myth to disable the
non-working-per-cable-box per tuner, right?

-I

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

rmeden at yahoo

Aug 8, 2007, 8:56 PM

Post #5 of 20 (2365 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

On 8/8/2007 10:41 PM, Ian Forde wrote:
>> The solution is to filter channels on the client side. Maybe the
>> capability will be added to the native myth grabber, but if not, feel
>> free to use the XMLTV grabber as it can filter at the client level. I
>> believe current versions of the myth XMLTV loader finds all the
>> "special" fields that Z2L provided, and XMLTV put in "strange" places.
>> If they missed some, I'm sure I can work it out with them.
>>
>
> I think I see what you mean - so I should have one "unified" listing,
> then use the channel editor in myth to disable the
> non-working-per-cable-box per tuner, right?
>
I don't use Myth so I can't tell you if disabling the channels will
work. Sounds feasable.

BTW.. if you do use the XMLTV route, in the first run use add --dd-data
to save the raw file, then use --dd-data --reprocess with a different
--config file for the other lineups.. that way you only download the raw
data once.

Robert

ron.garrison at gmail

Aug 8, 2007, 9:11 PM

Post #6 of 20 (2368 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

This is something I also need to do (have 2 accounts). I was not going to
say anything until I saw what was available through scedulesdirect, but
since its been brought up.... If there is way to get around this in MythTV
I was never able to figure it out.

In my case I have comcast cable. I run the cable direct to two ntsc tuners
which gets me channels up to 99. I use the cable box controlled via RS-232
for the upper channels. I therefore need two separate cable listings as I
couldn't seem to filter them on the client side per tuner. Zap2it would
allow two listings with one account if you had OTA and cable, but you
couldn't have two different cable listings on the same account, thus
requiring two separate accounts. I also grab the local HD channels off the
cable, but can use the OTA listings for this - avoiding a third account.

If I could filter on the client on a per tuner basis then the problem would
be solved - but as I said, I was not able to figure out how to do this.

Ron

billymacdonald at gmail

Aug 8, 2007, 11:35 PM

Post #7 of 20 (2362 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

On 8/8/07, Ian Forde <ian [at] duckland> wrote:
> In my myth setup, I have to use 2 Z2L accounts in order to get my
> listings. I'd just like to remind the powers-that-be that there may be
> many people out there in the same scenario, and hope that we wouldn't
> have to sign up twice to SchedulesDirect to get the equivalent
> functionality. I always found that to be a peculiar aspect of
> labs.zap2it.com in that one could only choose one listing of each type
> from a given account, so I couldn't have say...

I have three accounts setup on Z2L as well. It may be because I
couldn't figure out how to do it with one account when I tried the
first time. They are for cable analog (pvr250), cable qam
(hdhomerun), and atsc (hdhomerun).

If there are technical limitations as Robert mentioned, maybe there is
a way to not have to pay for that second account if needed.
Unfortunately I'm sure that may lead to people sharing accounts or
something to get around the billing for a couple of friends or a
system integrator. I'd gather that there could be security measures
to help prevent abuse of such a feature.

Just an option. I'd like to throw in my thanks for all the work at
schedules direct. I'm a little anxious at the pricing structure, a
little upset that TMS is getting my to pay for this data 4 or 5 times
over, a little excited that a permanent solution is close, a little
afraid that schedulesdirect will have the same problems as z2l.

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

mtdean at thirdcontact

Aug 9, 2007, 12:40 AM

Post #8 of 20 (2357 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

On 08/08/2007 11:41 PM, Ian Forde wrote:
> On Wed, 2007-08-08 at 22:02 -0500, Robert Eden wrote:
>
>> On 8/8/2007 8:01 PM, Ian Forde wrote:
>>
>>> In my myth setup, I have to use 2 Z2L accounts in order to get my
>>> listings. I'd just like to remind the powers-that-be that there may be
>>> many people out there in the same scenario, and hope that we wouldn't
>>> have to sign up twice to SchedulesDirect to get the equivalent
>>> functionality. I always found that to be a peculiar aspect of
>>> labs.zap2it.com in that one could only choose one listing of each type
>>> from a given account, so I couldn't have say...
>> The solution is to filter channels on the client side. Maybe the
>> capability will be added to the native myth grabber, but if not, feel
>> free to use the XMLTV grabber as it can filter at the client level. I
>> believe current versions of the myth XMLTV loader finds all the
>> "special" fields that Z2L provided, and XMLTV put in "strange" places.
>> If they missed some, I'm sure I can work it out with them.
>>
> I think I see what you mean - so I should have one "unified" listing,
> then use the channel editor in myth to disable the
> non-working-per-cable-box per tuner, right?

That won't work. Currently, each video source must have a unique lineup
(by design).

The patch at http://svn.mythtv.org/trac/ticket/3299 will allow you to
use a single ("meta") lineup for multiple video sources. However,
before it's integrated into mythfilldatabase, mfdb should be modified to
notice that multiple sources use the same lineup and cache the
downloaded listings data.

When the patch is applied in its current state, mfdb will download the
exact same data for the meta-lineup once for each video source that uses
the lineup. Therefore, applying the patch to "upstream" without
modifying mfdb to allow caching means that for a user with 2 "cable"
sources, instead of downloading two "smaller" lineups, the lineups would
be combined into one larger lineup, which would be downloaded twice.
(Granted, it's likely that one lineup is basic cable and the other
includes basic cable and more, so one is a larger lineup and one is
smaller, but 1+1/2 or 1+1/3 is still smaller than 1+1.)

Because of this, Robert's XMLTV-based approach (with caching -
http://www.gossamer-threads.com/lists/mythtv/users/283058#283058 ) is
currently the preferred approach. And, Robert's approach will work for
0.20-fixes users as well as trunk users, regardless of whether they
compile themselves or use packages.

See http://www.gossamer-threads.com/lists/mythtv/dev/264755#264755 for more.

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

rmeden at yahoo

Aug 9, 2007, 12:59 AM

Post #9 of 20 (2361 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

On 8/8/2007 10:56 PM, Robert Eden wrote:
> On 8/8/2007 10:41 PM, Ian Forde wrote:
>>> The solution is to filter channels on the client side. Maybe the
>>> capability will be added to the native myth grabber, but if not, feel
>>> free to use the XMLTV grabber as it can filter at the client level. I
>>> believe current versions of the myth XMLTV loader finds all the
>>> "special" fields that Z2L provided, and XMLTV put in "strange" places.
>>> If they missed some, I'm sure I can work it out with them.
>>>
>> I think I see what you mean - so I should have one "unified" listing,
>> then use the channel editor in myth to disable the
>> non-working-per-cable-box per tuner, right?
Actually no, not a unified lineup. XMLTV/tv_grab_na_dd only supports
one "lineup" per "config" file. Even though all lineups are downloaded,
only the one in the config file is used. In addition the config file
lets you filter out certain stations.

My solution is this:

tuner1.config

username: user
password: pass
timezone: -0500
lineup: TX42822:-
channel: 54 AETV
channel: 43 CNBC
not channel: 3 DSC
not channel: 57 TLC

tuner2.config

username: user
password: pass
timezone: -0500
lineup: TX42822:-
not channel: 54 AETV
not channel: 43 CNBC
channel: 3 DSC
channel: 57 TLC

tv_grab_na_dd --config-file-tuner1.config --dd-data=dd.xml
--output=tuner1.xmltv
tv_grab_na_dd --config-file-tuner2.config --dd-data=dd.xml
--output=tuner2.xmltv --reprocess
mythdatabaseload tuner1.xmltv (syntax made up, remember I don't know myth)
mythdatabaseload tuner2.xmltv

Robert

trgreer at gmail

Aug 9, 2007, 6:03 AM

Post #10 of 20 (2354 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

On 8/9/07, Robert Eden <rmeden [at] yahoo> wrote:
>
> Actually no, not a unified lineup. XMLTV/tv_grab_na_dd only supports one
> "lineup" per "config" file. Even though all lineups are downloaded, only
> the one in the config file is used. In addition the config file lets you
> filter out certain stations.
>
> My solution is this:
>
> tuner1.config
>
> username: user
> password: pass
> timezone: -0500
> lineup: TX42822:-
> channel: 54 AETV
> channel: 43 CNBC
> not channel: 3 DSC
> not channel: 57 TLC
>
> tuner2.config
>
> username: user
> password: pass
> timezone: -0500
> lineup: TX42822:-
> not channel: 54 AETV
> not channel: 43 CNBC
> channel: 3 DSC
> channel: 57 TLC
>
> tv_grab_na_dd --config-file-tuner1.config --dd-data=dd.xml --output=
> tuner1.xmltv
> tv_grab_na_dd --config-file-tuner2.config --dd-data=dd.xml --output=
> tuner2.xmltv --reprocess
> mythdatabaseload tuner1.xmltv (syntax made up, remember I don't know
> myth)
> mythdatabaseload tuner2.xmltv
>
> Robert
>

This certainly looks like it will solve the problem of requiring multiple
accounts to download the lineup data. I'll have to give this a try.

But it still is not the *best* way to handle this. My situation is a little
different; but I think it represents the typical in the real world.

cablebox.config
channel: 1
channel: 2
channel: 3
channel: 4

qamtuner.config
channel: 1
channel: 2
(3 and 4 excluded)

In this scenario, mythfilldatabase runs twice, once for each of the tuner
configurations. However, since the qamtuner.config is a subset of the
cablebox.config, the second run is completely wasted, all the data
duplicates existing data in the database.

Since mythfilldatabase taxes the system, it would make a lot of sense to
consolidate the channels required and update the database in a single pass.

Tom

mtdean at thirdcontact

Aug 9, 2007, 9:09 AM

Post #11 of 20 (2315 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

On 08/09/2007 09:03 AM, Tom Greer wrote:
> This certainly looks like it will solve the problem of requiring
> multiple accounts to download the lineup data. I'll have to give this
> a try.
>
> But it still is not the *best* way to handle this. My situation is a
> little different; but I think it represents the typical in the real
> world.
>
> cablebox.config
> channel: 1
> channel: 2
> channel: 3
> channel: 4
>
> qamtuner.config
> channel: 1
> channel: 2
> (3 and 4 excluded)
>
> In this scenario, mythfilldatabase runs twice, once for each of the
> tuner configurations. However, since the qamtuner.config is a subset
> of the cablebox.config, the second run is completely wasted, all the
> data duplicates existing data in the database.
>
> Since mythfilldatabase taxes the system, it would make a lot of sense
> to consolidate the channels required and update the database in a
> single pass.

http://www.gossamer-threads.com/lists/mythtv/users/283097#283097

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

freedenizen at gmail

Aug 9, 2007, 9:28 AM

Post #12 of 20 (2315 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

I too, have this situation and I see it as being one of the biggest
headaches moving over. I currently have 3 accts at zap2it labs due to
different channels I can get from ATSC, QAM, analog cable, and
Firewire via a dct6200. I think that patch is going to be getting A
LOT of testing very shortly.

While I understand that this is a fundamental low level issue, but
maybe there is a way around it by having a higher level account that
people have at SD, which is a container for multiple other accounts
that contain the lineups.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

trgreer at gmail

Aug 9, 2007, 9:55 AM

Post #13 of 20 (2318 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

On 8/9/07, Michael T. Dean <mtdean [at] thirdcontact> wrote:
>
> http://www.gossamer-threads.com/lists/mythtv/users/283097#283097
>
>
Mike,

I saw that link already; but in reading it, I thought the message was that
this patch was being rejected - and that Robert's method was "preferred".

Did I read this wrong? Is the patch going to be implemented?

Advise.

Tom

mtdean at thirdcontact

Aug 9, 2007, 10:06 AM

Post #14 of 20 (2323 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

On 08/09/2007 12:55 PM, Tom Greer wrote:
> On 8/9/07, Michael T. Dean <mtdean [at] thirdcontact> wrote:
>
>> http://www.gossamer-threads.com/lists/mythtv/users/283097#283097
> I saw that link already; but in reading it, I thought the message was that
> this patch was being rejected - and that Robert's method was "preferred".
>
> Did I read this wrong? Is the patch going to be implemented?
>
> Advise.

I'm not one of the devs, so I can't reject the patch. ;) If you look
at the ticket, it's still open.

My suggestion (in the "See ... for more" post to which the above post
links) was that applying the patch be deferred until mfdb is changed to
cache its downloads as appropriate. 4 months ago when the patch was
first posted to Trac, several people expressed interest and motivation
to modify mfdb, but it seems they have lost interest in the interim
(possibly because they felt it was easier to just apply the existing
patch and ignore the consequences).

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

mtdean at thirdcontact

Aug 9, 2007, 10:14 AM

Post #15 of 20 (2309 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

On 08/09/2007 12:28 PM, Asher wrote:
> I too, have this situation and I see it as being one of the biggest
> headaches moving over. I currently have 3 accts at zap2it labs due to
> different channels I can get from ATSC, QAM, analog cable, and
> Firewire via a dct6200. I think that patch is going to be getting A
> LOT of testing very shortly.
>

Please, if you use that patch, consider writing the mfdb caching code
(it wouldn't be that hard to do--just requires a little "pre-download"
logic). If someone adds caching to mfdb, then no one will need to use
the patches (because they'll be added to upstream).

Also, remember that Robert's XMLTV-based approach is a more efficient
approach than applying the patch without caching... (Trying to guilt
people into either writing the caching code or being "considerate" users
of SD. :)

> While I understand that this is a fundamental low level issue, but
> maybe there is a way around it by having a higher level account that
> people have at SD, which is a container for multiple other accounts
> that contain the lineups.

Regardless, the small change to mfdb (actually Myth's libs) to allow
caching the data would probably be a lot easier to program than a SD
"meta account." So, people who have been asking what they can do to
help SD, this may be something. If it turns out that most of the DD
code (or at least the infrastructure for DD in MythTV) is used for SD,
creating the data-caching patch for mfdb would actually help SD.

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

lists at forevermore

Aug 9, 2007, 10:14 AM

Post #16 of 20 (2309 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

Asher wrote:
> While I understand that this is a fundamental low level issue, but
> maybe there is a way around it by having a higher level account that
> people have at SD, which is a container for multiple other accounts
> that contain the lineups.

That would probably violate our agreement with TMS, not to mention be a
headache to develop. We did talk about this kind of thing, though --
offering some kind of "sub account" for people in your situation at a
significantly reduced cost. But I don't think that it will be able to
happen.

-Chris

Attachments:

signature.asc (0.18 KB)

ian at duckland

Aug 9, 2007, 10:48 AM

Post #17 of 20 (2308 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

On Thu, 2007-08-09 at 03:40 -0400, Michael T. Dean wrote:
> That won't work. Currently, each video source must have a unique lineup
> (by design).

Crap...

> The patch at http://svn.mythtv.org/trac/ticket/3299 will allow you to
> use a single ("meta") lineup for multiple video sources. However,
> before it's integrated into mythfilldatabase, mfdb should be modified to
> notice that multiple sources use the same lineup and cache the
> downloaded listings data.

okay...

> When the patch is applied in its current state, mfdb will download the
> exact same data for the meta-lineup once for each video source that uses
> the lineup. Therefore, applying the patch to "upstream" without
> modifying mfdb to allow caching means that for a user with 2 "cable"
> sources, instead of downloading two "smaller" lineups, the lineups would
> be combined into one larger lineup, which would be downloaded twice.
> (Granted, it's likely that one lineup is basic cable and the other
> includes basic cable and more, so one is a larger lineup and one is
> smaller, but 1+1/2 or 1+1/3 is still smaller than 1+1.)

I can see how this would be bad when scaled over thousands of users...

> Because of this, Robert's XMLTV-based approach (with caching -
> http://www.gossamer-threads.com/lists/mythtv/users/283058#283058 ) is
> currently the preferred approach. And, Robert's approach will work for
> 0.20-fixes users as well as trunk users, regardless of whether they
> compile themselves or use packages.
>
> See http://www.gossamer-threads.com/lists/mythtv/dev/264755#264755 for more.

Okay - I'm a trunk user (haven't updated since 6/30/2007), and I'm out
of town until tomorrow - I'll try it over the weekend and see what
happens.

Thanks!

-I

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

mtdean at thirdcontact

Aug 9, 2007, 11:17 AM

Post #18 of 20 (2310 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

On 08/09/2007 01:14 PM, Chris Petersen wrote:
> Asher wrote:
>
>> While I understand that this is a fundamental low level issue, but
>> maybe there is a way around it by having a higher level account that
>> people have at SD, which is a container for multiple other accounts
>> that contain the lineups.
>>
> That would probably violate our agreement with TMS, not to mention be a
> headache to develop. We did talk about this kind of thing, though --
> offering some kind of "sub account" for people in your situation at a
> significantly reduced cost. But I don't think that it will be able to
> happen.

Chris, the patch in #3299 will allow filtering of one "larger" lineup by
mfdb (technically allows keeping channels in the lineup even if they're
not associated with the current video source). However, it should
probably be modified to include some caching mechanism (as without the
modification, it downloads the one larger lineup once for each video
source that uses the lineup).

Since so many people are worried about this, perhaps one of them who
needs this functionality will write the caching logic (technically, they
just have to ensure that we cache the downloaded data longer than we
currently do)...

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

david at shay

Aug 9, 2007, 11:51 AM

Post #19 of 20 (2311 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

On 8/9/07, Michael T. Dean <mtdean [at] thirdcontact> wrote:
> On 08/09/2007 01:14 PM, Chris Petersen wrote:
> > Asher wrote:
> >
> >> While I understand that this is a fundamental low level issue, but
> >> maybe there is a way around it by having a higher level account that
> >> people have at SD, which is a container for multiple other accounts
> >> that contain the lineups.
> >>
> > That would probably violate our agreement with TMS, not to mention be a
> > headache to develop. We did talk about this kind of thing, though --
> > offering some kind of "sub account" for people in your situation at a
> > significantly reduced cost. But I don't think that it will be able to
> > happen.
>
> Chris, the patch in #3299 will allow filtering of one "larger" lineup by
> mfdb (technically allows keeping channels in the lineup even if they're
> not associated with the current video source). However, it should
> probably be modified to include some caching mechanism (as without the
> modification, it downloads the one larger lineup once for each video
> source that uses the lineup).
>
> Since so many people are worried about this, perhaps one of them who
> needs this functionality will write the caching logic (technically, they
> just have to ensure that we cache the downloaded data longer than we
> currently do)...
>
> Mike

I'm one of those who needs this.... I will take a look at this
tonight, although I'll have to tear myself away from my other patch.
Of course, that might do my sanity some good.

Has the base patch (3299) been tested and proved working, so that the
only real open issue to worry about is caching?
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-users

mtdean at thirdcontact

Aug 9, 2007, 12:04 PM

Post #20 of 20 (2304 views)
Permalink

Re: A hope regarding the new SchedulesDirect methodology [In reply to]

On 08/09/2007 02:51 PM, David Shay wrote:
> On 8/9/07, Michael T. Dean <mtdean [at] thirdcontact> wrote:
>
>> the patch in #3299 will allow filtering of one "larger" lineup by
>> mfdb (technically allows keeping channels in the lineup even if they're
>> not associated with the current video source).
>>
...
>> Since so many people are worried about this, perhaps one of them who
>> needs this functionality will write the caching logic (technically, they
>> just have to ensure that we cache the downloaded data longer than we
>> currently do)...
> I'm one of those who needs this.... I will take a look at this
> tonight,

Great. And, as the author of the DD support in Myth, you're probably an
excellent candidate. Of course, you'll have to get to know some of
Daniel's lineup-management changes, but they're pretty straightforward.

> although I'll have to tear myself away from my other patch.
> Of course, that might do my sanity some good.
>

Yeah. I've seen you working some late nights on that.

> Has the base patch (3299) been tested and proved working, so that the
> only real open issue to worry about is caching?

The submitter seemed to be using it and it /looks/ right to me. :)
It's really a pretty simple patch that just verifies that a channel
found in the lineup exists in /any/ video source (rather than just the
current video source) before it removes the channel from the DD lineup.

(I'm wondering how many of those DD's should have been Z2L's, but I
think you get my drift.)

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

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads