Mailing List Archive: MythTV: Users

Number of virtual tuners

Index | Next | Previous | View Threaded

mythtv at tapanitarvainen

Apr 25, 2012, 8:00 PM

Post #1 of 21 (1942 views)
Permalink

Number of virtual tuners

On Wed, Apr 25, 2012 at 10:44:42PM +0200, Karl Dietz (dekarl [at] spaetfruehstuecken) wrote:

> You can record overlapping programs from one DVB card with the multirec
> feature. By default each DVB cards gets added as 2 virtual tuners.
> You can push that up to 5 in mythtv-setup.

Is there some reason to that limit, by the way?
I could use more: we have up to 10 channels per MUX,
and I've already hit the limit - recorded 6 programs
of same MUX at the same time, that is, using two
cards where one would've been enough if I could've
had more virtual tuners per card.

--
Tapani Tarvainen
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

pieter at insync

Apr 25, 2012, 8:07 PM

Post #2 of 21 (1894 views)
Permalink

Re: Number of virtual tuners [In reply to]

On Thu, 26 Apr 2012, Tapani Tarvainen wrote:

> On Wed, Apr 25, 2012 at 10:44:42PM +0200, Karl Dietz (dekarl [at] spaetfruehstuecken) wrote:
>
>> You can record overlapping programs from one DVB card with the multirec
>> feature. By default each DVB cards gets added as 2 virtual tuners.
>> You can push that up to 5 in mythtv-setup.
>
> Is there some reason to that limit, by the way?
> I could use more: we have up to 10 channels per MUX,
> and I've already hit the limit - recorded 6 programs
> of same MUX at the same time, that is, using two
> cards where one would've been enough if I could've
> had more virtual tuners per card.
>
> --
> Tapani Tarvainen
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>
Hi,

I have (and currently are again) using 4 virtuals for my one card. I have
to go back and see where the 8 came from.

Cheers,

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

mythtv-list at dinkum

Apr 26, 2012, 12:19 AM

Post #3 of 21 (1887 views)
Permalink

Re: Number of virtual tuners [In reply to]

On 26 Apr 2012, at 05:00, Tapani Tarvainen wrote:

> On Wed, Apr 25, 2012 at 10:44:42PM +0200, Karl Dietz (dekarl [at] spaetfruehstuecken) wrote:
>
>> You can record overlapping programs from one DVB card with the multirec
>> feature. By default each DVB cards gets added as 2 virtual tuners.
>> You can push that up to 5 in mythtv-setup.
>
> Is there some reason to that limit, by the way?

When multirec was being developed 5 was decided on as the point where performance was still good on contemporary hardware. You can change the limit and re-compile if you need to, a friend's system handles 8 SD channels with no problem on a 2.6Ghz C2D, multirec set to 10.

I mostly record HD and currently there are 4 channels to a mux, it's not that often an overlap causes me to "waste" a tuner.

with the way broadcasters are cramming more and more channels in to one mux maybe this default limit needs re-assessing.

> I could use more: we have up to 10 channels per MUX,
> and I've already hit the limit - recorded 6 programs
> of same MUX at the same time, that is, using two

Then there are overlaps too!

Andre

> cards where one would've been enough if I could've
> had more virtual tuners per card.
>
> --
> Tapani Tarvainen
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>

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

mythtv at tapanitarvainen

Apr 26, 2012, 12:52 AM

Post #4 of 21 (1896 views)
Permalink

Re: Number of virtual tuners [In reply to]

On Apr 26 09:19, Andre (mythtv-list [at] dinkum) wrote:

> When multirec was being developed 5 was decided on as the point
> where performance was still good on contemporary hardware. You can
> change the limit and re-compile if you need to, a friend's system
> handles 8 SD channels with no problem on a 2.6Ghz C2D, multirec set
> to 10.

I tested my box recording 10 simultaneous SD channels using two cards,
it worked just fine without breaking sweat (it's a bit overkill, having
been built out of leftover parts from another project, i5-650 &c),
so I guess it could handle even 20 SSDs, 10 per card;
disk subsystem might become a bottleneck though.

> with the way broadcasters are cramming more and more channels in to
> one mux maybe this default limit needs re-assessing.

Upping the maximum from 5 to 10 should be safe enough -
especially if the default is kept at 2 it should have no
adverse consequences that I can see.

--
Tapani Tarvainen
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mtdean at thirdcontact

Apr 26, 2012, 6:38 PM

Post #5 of 21 (1857 views)
Permalink

Re: Number of virtual tuners [In reply to]

On 04/26/2012 03:19 AM, Andre wrote:
> On 26 Apr 2012, at 05:00, Tapani Tarvainen wrote:
>> On Wed, Apr 25, 2012 at 10:44:42PM +0200, Karl Dietz wrote:
>>
>>> You can record overlapping programs from one DVB card with the multirec
>>> feature. By default each DVB cards gets added as 2 virtual tuners.
>>> You can push that up to 5 in mythtv-setup.
>> Is there some reason to that limit, by the way?
> When multirec was being developed 5 was decided on as the point where performance was still good on contemporary hardware.

More precisely, 5 was determined to be the "sweet spot". Each
additional virtual tuner you add increases resources required to
schedule by a greater and greater amount (non-linear increase), and the
resource increase for the first 5 was reasonable compared to the benefit
they provide, but the 6th virtual tuner required a huge increase in
resources (and additionals even huger) for very little gain.

(Especially when you can pick up additional cards for cheap.)

Mike

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

mythtv at tapanitarvainen

Apr 26, 2012, 8:19 PM

Post #6 of 21 (1860 views)
Permalink

Re: Number of virtual tuners [In reply to]

On Thu, Apr 26, 2012 at 09:38:50PM -0400, Michael T. Dean (mtdean [at] thirdcontact) wrote:

> On 04/26/2012 03:19 AM, Andre wrote:

> > When multirec was being developed 5 was decided on as the point
> > where performance was still good on contemporary hardware.

> More precisely, 5 was determined to be the "sweet spot". Each
> additional virtual tuner you add increases resources required to
> schedule by a greater and greater amount (non-linear increase),

Do you have a more specific idea which particular resources
we are talking about here?
CPU power, RAM, disk I/O, what?

> and the resource increase for the first 5 was reasonable compared to the
> benefit they provide, but the 6th virtual tuner required a huge
> increase in resources (and additionals even huger) for very little
> gain.

Presumably that would only happen if you actually configure
more virtual tuners per card, so merely increasing the limit
one _can_ do would have no impact on people who don't need it.

I agree that _default_ should be set to something that works
well on average hardware, but maximums, hard limits, should
be generally something like "biggest that might make sense"
and let people find their own sweet spots.

In any case, hardware has become rather more powerful since the
limit was set. Perhaps 5 was indeed biggest reasonable value
then, but if someone is already using 8 with success,
it would seem it's time to reconsider the limit.

> (Especially when you can pick up additional cards for cheap.)

The only DVB-C cards I've found that actually work here
are all fairly expensive PCI ones, and I have no free PCI
slots left in my mythtv box or indeed room in the case,
so I'd have to replace the motherboard and chassis,
or build a separate slave backend...
Getting faster disks or more RAM or even a faster CPU
would be easier and cheaper.

Fortunately it is indeed free software and recompiling
from sources is not too hard.

--
Tapani Tarvainen
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mythtv-list at dinkum

Apr 27, 2012, 12:41 AM

Post #7 of 21 (1849 views)
Permalink

Re: Number of virtual tuners [In reply to]

On 27 Apr 2012, at 03:38, Michael T. Dean wrote:

> On 04/26/2012 03:19 AM, Andre wrote:
>> On 26 Apr 2012, at 05:00, Tapani Tarvainen wrote:
>>> On Wed, Apr 25, 2012 at 10:44:42PM +0200, Karl Dietz wrote:
>>>
>>>> You can record overlapping programs from one DVB card with the multirec
>>>> feature. By default each DVB cards gets added as 2 virtual tuners.
>>>> You can push that up to 5 in mythtv-setup.
>>> Is there some reason to that limit, by the way?
>> When multirec was being developed 5 was decided on as the point where performance was still good on contemporary hardware.
>
> More precisely, 5 was determined to be the "sweet spot".

I was going from memory :-) I followed that development with great interest, oh and contributed to the bounty.

> Each additional virtual tuner you add increases resources required to schedule by a greater and greater amount (non-linear increase), and the resource increase for the first 5 was reasonable compared to the benefit they provide, but the 6th virtual tuner required a huge increase in resources (and additionals even huger) for very little gain.

Is there a difference in the resources required for 2 cards with 10 virtual tuners as against 4 cards with 5 virtual? I thought Myth didn't fully "understand" multirec virtual tuners and treated them the same as real ones for scheduling, not moaning, just curious.

>
> (Especially when you can pick up additional cards for cheap.)

Well yes, ish DVBS2 cards that actually work properly are still a little expensive >�80 but when adding an extra card requires hiring a �150 a day hoist to externally cable extra satellite feeds and replacing Motherboard to get extra slots, which then means new CPU, new ram! Of course MythTV has never been a budget solution and there's always the re-compile option. Would be nice to be able to stay on the binary builds though, how about storing the limit in the DB somewhere?

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

mtdean at thirdcontact

Apr 28, 2012, 7:37 AM

Post #8 of 21 (1829 views)
Permalink

Re: Number of virtual tuners [In reply to]

On 04/27/2012 03:41 AM, Andre wrote:
> On 27 Apr 2012, at 03:38, Michael T. Dean wrote:
>> Each additional virtual tuner you add increases resources required to schedule by a greater and greater amount (non-linear increase), and the resource increase for the first 5 was reasonable compared to the benefit they provide, but the 6th virtual tuner required a huge increase in resources (and additionals even huger) for very little gain.
> Is there a difference in the resources required for 2 cards with 10 virtual tuners as against 4 cards with 5 virtual?

Yes. The difference is the constraints imposed by multirec--2 cards
with 10 virtual tuners are much more constrained than 4 cards with 5
virtual tuners.

Max of 5 was chosen as "the biggest that makes sense for nearly all
users". The max prevents users who think, "more must be better," from
breaking their systems due to ignorance. Those who want higher are
welcome to change the code--and fix any problems that occur as a result.

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

brian at interlinx

Apr 28, 2012, 8:10 AM

Post #9 of 21 (1828 views)
Permalink

Re: Number of virtual tuners [In reply to]

On 12-04-28 10:37 AM, Michael T. Dean wrote:
>
> Max of 5 was chosen as "the biggest that makes sense for nearly all
> users". The max prevents users who think, "more must be better," from
> breaking their systems due to ignorance.

Indeed. The other way I see this frequently handled is to display an
explanation of the danger of going beyond a value and asking for a
confirmation. Is that not reasonable here?

> Those who want higher are
> welcome to change the code--and fix any problems that occur as a result.

But what problems? Somebody said earlier that it was merely a
diminishing returns problem due to a non-linear complexity growth in
scheduling with that many virtual tuners. To me, that simply means that
the scheduler takes longer to get it's result or requires more resources
to do it in a reasonable amount of time.

What other "problems" are you referring to? Is there additional
constraints (beyond simply scheduling complexity) that nobody has talked
about yet?

b.

Attachments:

signature.asc (0.26 KB)

mtdean at thirdcontact

Apr 28, 2012, 8:48 AM

Post #10 of 21 (1827 views)
Permalink

Re: Number of virtual tuners [In reply to]

On 04/28/2012 11:10 AM, Brian J. Murrell wrote:
> On 12-04-28 10:37 AM, Michael T. Dean wrote:
>> Max of 5 was chosen as "the biggest that makes sense for nearly all
>> users". The max prevents users who think, "more must be better," from
>> breaking their systems due to ignorance.
> Indeed. The other way I see this frequently handled is to display an
> explanation of the danger of going beyond a value and asking for a
> confirmation. Is that not reasonable here?
>
>> Those who want higher are
>> welcome to change the code--and fix any problems that occur as a result.
> But what problems? Somebody said earlier that it was merely a
> diminishing returns problem due to a non-linear complexity growth in
> scheduling with that many virtual tuners. To me, that simply means that
> the scheduler takes longer to get it's result or requires more resources
> to do it in a reasonable amount of time.
>
> What other "problems" are you referring to? Is there additional
> constraints (beyond simply scheduling complexity) that nobody has talked
> about yet?

Untested/unsupported configurations mean you're on your own. If I could
tell you what problems, I'd just fix them.

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

dekarl at spaetfruehstuecken

Apr 28, 2012, 11:13 AM

Post #11 of 21 (1818 views)
Permalink

Re: Number of virtual tuners [In reply to]

On 28.04.2012 17:10, Brian J. Murrell wrote:
> On 12-04-28 10:37 AM, Michael T. Dean wrote:
>>
>> Max of 5 was chosen as "the biggest that makes sense for nearly all
>> users". The max prevents users who think, "more must be better," from
>> breaking their systems due to ignorance.
>
> Indeed. The other way I see this frequently handled is to display an
> explanation of the danger of going beyond a value and asking for a
> confirmation. Is that not reasonable here?

Please don't. I'd rather see that part of the recorders rewritten so we
can remove the option and still get the feature then seeing even more
options. (I'm counting a confirmation as an option here)

>> Those who want higher are
>> welcome to change the code--and fix any problems that occur as a result.
>
> But what problems? Somebody said earlier that it was merely a
> diminishing returns problem due to a non-linear complexity growth in
> scheduling with that many virtual tuners. To me, that simply means that
> the scheduler takes longer to get it's result or requires more resources
> to do it in a reasonable amount of time.
>
> What other "problems" are you referring to? Is there additional
> constraints (beyond simply scheduling complexity) that nobody has talked
> about yet?

There have been reports of issues when the scheduler run takes to long
(for various definitions of "long"). The scheduler is being optimized,
CPUs get faster, etc. pp. Basically you are leaving known waters and
might meet dragons :)

More power to you if you go there and life to tell the story :D

Regards,
Karl
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

pieter at insync

Apr 29, 2012, 2:48 AM

Post #12 of 21 (1808 views)
Permalink

Re: Number of virtual tuners [In reply to]

On 26/04/2012 15:00, Tapani Tarvainen wrote:
> On Wed, Apr 25, 2012 at 10:44:42PM +0200, Karl Dietz (dekarl [at] spaetfruehstuecken) wrote:
>
>> You can record overlapping programs from one DVB card with the multirec
>> feature. By default each DVB cards gets added as 2 virtual tuners.
>> You can push that up to 5 in mythtv-setup.
> Is there some reason to that limit, by the way?
> I could use more: we have up to 10 channels per MUX,
> and I've already hit the limit - recorded 6 programs
> of same MUX at the same time, that is, using two
> cards where one would've been enough if I could've
> had more virtual tuners per card.
>
Hi,

I think "we" should have a limit of per card:

My card (1) can't do more than 2:

TVRecEvent dvbchannel.cpp:347 (CheckFrequency)
DVBChan(3:/dev/dvb/adapter0/frontend0): Your frequency setting
(12483000) is out of range. (min/max:950000/2150000)

That freq. is a transponder that is valid :)

06:02.0 Multimedia video controller: Conexant Systems, Inc.
CX23880/1/2/3 PCI Video and Audio Decoder (rev 05)
Subsystem: Hauppauge computer works Inc. Nova-S-Plus DVB-S
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (5000ns min, 13750ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at f8000000 (32-bit, non-prefetchable) [size=16M]
Capabilities: [44] Vital Product Data
Unknown large resource type 04, will not decode more.
Capabilities: [4c] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: cx8800
Kernel modules: cx8800

06:02.1 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI
Video and Audio Decoder [Audio Port] (rev 05)
Subsystem: Hauppauge computer works Inc. Device 9202
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (1000ns min, 63750ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at f7000000 (32-bit, non-prefetchable) [size=16M]
Capabilities: [4c] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: cx88_audio
Kernel modules: cx88-alsa

06:02.2 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI
Video and Audio Decoder [MPEG Port] (rev 05)
Subsystem: Hauppauge computer works Inc. Device 9202
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (1500ns min, 22000ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 18
Region 0: Memory at f6000000 (32-bit, non-prefetchable) [size=16M]
Capabilities: [4c] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: cx88-mpeg driver manager
Kernel modules: cx8802

06:02.4 Multimedia controller: Conexant Systems, Inc. CX23880/1/2/3 PCI
Video and Audio Decoder [IR Port] (rev 05)
Subsystem: Hauppauge computer works Inc. Device 9202
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium
>TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 32 (1500ns min, 63750ns max), Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 5
Region 0: Memory at f5000000 (32-bit, non-prefetchable) [size=16M]
Capabilities: [4c] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-

Cheers,

Pieter

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

linux at thehobsons

Apr 29, 2012, 4:38 AM

Post #13 of 21 (1796 views)
Permalink

Re: Number of virtual tuners [In reply to]

Pieter De Wit wrote:

>I think "we" should have a limit of per card:
>
>My card (1) can't do more than 2:

Yes, each installation will have limits - in your case it appears due
to the card, for others it's disk bandwidth, and there are other
factors that can limit the total recordings/system or recording/card
that can be done.

The discussion is about a compiled in limit that restricts the users
ability to decide how many virtual tuners they want/can use/is
supported by their hardware. For some users, this artificial limit of
5 is an issue - so there's a discussion as to whether this needs to
be raised (or removed ?), and what it should be. It will in no way
force anyone to use more virtual tuners than they want/their system
will support - but if the limit is made too high, then novice users
may set it too high due to ignorance of the issues involved and
experience poor performance or other problems.

--
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

pieter at insync

Apr 29, 2012, 1:34 PM

Post #14 of 21 (1798 views)
Permalink

Re: Number of virtual tuners [In reply to]

On Sun, 29 Apr 2012, Simon Hobson wrote:

> Pieter De Wit wrote:
>
>> I think "we" should have a limit of per card:
>>
>> My card (1) can't do more than 2:
>
> Yes, each installation will have limits - in your case it appears due to the
> card, for others it's disk bandwidth, and there are other factors that can
> limit the total recordings/system or recording/card that can be done.
>
> The discussion is about a compiled in limit that restricts the users ability
> to decide how many virtual tuners they want/can use/is supported by their
> hardware. For some users, this artificial limit of 5 is an issue - so there's
> a discussion as to whether this needs to be raised (or removed ?), and what
> it should be. It will in no way force anyone to use more virtual tuners than
> they want/their system will support - but if the limit is made too high, then
> novice users may set it too high due to ignorance of the issues involved and
> experience poor performance or other problems.
>
> --
> Simon Hobson
>
> Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
> author Gladys Hobson. Novels - poetry - short stories - ideal as
> Christmas stocking fillers. Some available as e-books.
> _______________________________________________
> mythtv-users mailing list
> mythtv-users [at] mythtv
> http://www.mythtv.org/mailman/listinfo/mythtv-users
>

Hi,

Going back to my original post, how will this go down:

During the channel scanning phase a scan is done to see how many channels
a card can tune to. This can be done to /dev/null to drop out disk/display
and other bottle necks.

Once this number is known, Virtual tuners can be used to record from the
real tuners. Virtual tuners is something that "we" control so we can limit
them based on other factors. I am sure we can safely say, that you only
need to display 2 channels at once (watch, someone will give us a
screenshot with 4 PnP's :) )

If we find that the system can't cope with a set of recorders, we drop one
from the list (something like that)

This might not score us a lot of points on the technical side, but user XP
will be better.

Cheers,

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

linux at thehobsons

Apr 30, 2012, 12:08 AM

Post #15 of 21 (1786 views)
Permalink

Re: Number of virtual tuners [In reply to]

Pieter De Wit wrote:

>During the channel scanning phase a scan is done to see how many
>channels a card can tune to. This can be done to /dev/null to drop
>out disk/display and other bottle necks.
>
>Once this number is known, Virtual tuners can be used to record from
>the real tuners. Virtual tuners is something that "we" control so we
>can limit them based on other factors. I am sure we can safely say,
>that you only need to display 2 channels at once (watch, someone
>will give us a screenshot with 4 PnP's :) )

That won't help in the general case - there is more to recording
multiple streams than just getting them from the tuners and stuffing
them on disk, not to mention that if you have multiple tuners then
the system may not be able to handle the max no of recordings the
tuners are collectively capable of doing while it can handle the max
for any one tuner on it's own. It's been suggested earlier in the
thread that some other factors come into play - for example, what
does it do to the system when several recordings start at once and
the <something> kicks in to update the database ? Then you've got an
arbitrary number and type of user jobs, and an arbitrary number of
frontends - in theory there's no limit to the number of frontends/TVs
someone could have hanging off the backend.

But the biggest problem with any automated system like you describe
is that they always end up getting in the way sooner or later. It's
like using MS Office - you know exactly how you want to format your
document, but the darn software keeps getting in the way and doing
different things "to be helpful" because the vendors have the same
mindset of "making it easy".

Personally I'm inclined to say it's a documentation problem to be
solved. You cannot set a limit that satisfies the requirement to be
"safe" for all users (you've found that a limit of just 3 wouldn't be
"safe" for your hardware) while not artificially restricting other
users. The problem as I see it is that MythTV is a complex project
for a new user (it's still complex for me and I've been using it for
years !), and the documentation in some areas can be difficult to
navigate.
So how can it be made easier for a novice to find the right bit of
information when they arrive at each setting of the many they need to
know about ? It's probably a whole wiki page to cover just how to
setup multirec AND determine how many tuners is "safe" for your
hardware.

--
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mythtv at tapanitarvainen

Apr 30, 2012, 12:46 AM

Post #16 of 21 (1784 views)
Permalink

Re: Number of virtual tuners [In reply to]

On Apr 30 08:08, Simon Hobson (linux [at] thehobsons) wrote:

> Personally I'm inclined to say it's a documentation problem to be
> solved. You cannot set a limit that satisfies the requirement to be
> "safe" for all users (you've found that a limit of just 3 wouldn't
> be "safe" for your hardware) while not artificially restricting
> other users.

Exactly.

> The problem as I see it is that MythTV is a complex
> project for a new user (it's still complex for me and I've been
> using it for years !), and the documentation in some areas can be
> difficult to navigate.

No disagreement there. :-)

> So how can it be made easier for a novice to find the right bit of
> information when they arrive at each setting of the many they need
> to know about ? It's probably a whole wiki page to cover just how to
> setup multirec AND determine how many tuners is "safe" for your
> hardware.

Right.

But, I think it wouldn't make things worse if the limit was removed
(or increased to something like highest value of channels in
single MUX anywhere, i.e., at least 10) and the help text in setup
changed to include a warning like
"VALUES HIGHER THAN 5 REQUIRE A VERY POWERFUL SYSTEM".
It should be enough to keep newcomers from breaking things
accidentally - indeed possibly better than the current
hard limit, which many (?) may read indicating 5 is always safe -
while allowing those who actually have overpowered systems to use
higher values easier than by recompiling.

--
Tapani Tarvainen
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

pieter at insync

Apr 30, 2012, 1:10 AM

Post #17 of 21 (1778 views)
Permalink

Re: Number of virtual tuners [In reply to]

On 30/04/2012 19:08, Simon Hobson wrote:
> Pieter De Wit wrote:
>
>> During the channel scanning phase a scan is done to see how many
>> channels a card can tune to. This can be done to /dev/null to drop
>> out disk/display and other bottle necks.
>>
>> Once this number is known, Virtual tuners can be used to record from
>> the real tuners. Virtual tuners is something that "we" control so we
>> can limit them based on other factors. I am sure we can safely say,
>> that you only need to display 2 channels at once (watch, someone will
>> give us a screenshot with 4 PnP's :) )
>
> That won't help in the general case - there is more to recording
> multiple streams than just getting them from the tuners and stuffing
> them on disk, not to mention that if you have multiple tuners then the
> system may not be able to handle the max no of recordings the tuners
> are collectively capable of doing while it can handle the max for any
> one tuner on it's own. It's been suggested earlier in the thread that
> some other factors come into play - for example, what does it do to
> the system when several recordings start at once and the <something>
> kicks in to update the database ? Then you've got an arbitrary number
> and type of user jobs, and an arbitrary number of frontends - in
> theory there's no limit to the number of frontends/TVs someone could
> have hanging off the backend.

I beg to differ - I think this can be done in code (mplayer does
something like what I am thinking - your system is to slow to play
this), but, since this seems to be the general feeling, I will leave it
at that

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

linux at thehobsons

Apr 30, 2012, 2:44 AM

Post #18 of 21 (1782 views)
Permalink

Re: Number of virtual tuners [In reply to]

Tapani Tarvainen wrote:

> > So how can it be made easier for a novice to find the right bit of
>> information when they arrive at each setting of the many they need
>> to know about ? It's probably a whole wiki page to cover just how to
>> setup multirec AND determine how many tuners is "safe" for your
>> hardware.
>
>Right.
>
>But, I think it wouldn't make things worse if the limit was removed
>(or increased to something like highest value of channels in
>single MUX anywhere, i.e., at least 10)

That isn't a sufficient qualification - if you pad recordings (as I
do) then you can need two tuners for one channel to allow for the
overlap. Besides, I've just had a look and I make it 21 channels on
our Mux A (BBC), about 1/2 of which are radio, and one or two are
interactive (text) services, and some of the TV channels are part
time to share a bandwidth allocation.
So by a simplistic interpretation, you'd need a limit of 20 or more -
by which point, why have a limit at all ?

> and the help text in setup
>changed to include a warning like
>"VALUES HIGHER THAN 5 REQUIRE A VERY POWERFUL SYSTEM".
>It should be enough to keep newcomers from breaking things
>accidentally - indeed possibly better than the current
>hard limit, which many (?) may read indicating 5 is always safe -
>while allowing those who actually have overpowered systems to use
>higher values easier than by recompiling.

That text might also suggest that "5 is OK". I think a link to a wiki
page would be a good idea - then the wiki page can explain the issues
and how to choose a "good" number.
--
Simon Hobson

Visit http://www.magpiesnestpublishing.co.uk/ for books by acclaimed
author Gladys Hobson. Novels - poetry - short stories - ideal as
Christmas stocking fillers. Some available as e-books.
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

mythtvuser1818 at gmail

Apr 30, 2012, 7:17 AM

Post #19 of 21 (1772 views)
Permalink

Re: Number of virtual tuners [In reply to]

On Mon, Apr 30, 2012 at 3:46 AM, Tapani Tarvainen <
mythtv [at] tapanitarvainen> wrote:

> But, I think it wouldn't make things worse if the limit was removed
> (or increased to something like highest value of channels in
> single MUX anywhere, i.e., at least 10) and the help text in setup
> changed to include a warning like
> "VALUES HIGHER THAN 5 REQUIRE A VERY POWERFUL SYSTEM".
> It should be enough to keep newcomers from breaking things
> accidentally - indeed possibly better than the current
> hard limit, which many (?) may read indicating 5 is always safe -
> while allowing those who actually have overpowered systems to use
> higher values easier than by recompiling.
>
Rather than hard coding the limit, requiring code modification every time
you do an upgrade, why not put the limit in a config file (defaulting to 5
if not specified). That way the limit is fixed for newbies, but easily
modified by those in the know and remembered after an upgrade.

gary.buhrmaster at gmail

Apr 30, 2012, 10:57 AM

Post #20 of 21 (1762 views)
Permalink

Re: Number of virtual tuners [In reply to]

On Mon, Apr 30, 2012 at 14:17, Roger H <mythtvuser1818 [at] gmail> wrote:
....
> Rather than hard coding the limit, requiring code modification every time
> you do an upgrade, why not put the limit in a config file (defaulting to 5
> if not specified).� That way the limit is fixed for newbies, but easily
> modified by those in the know and remembered after an upgrade.

Well, it probably should be in the database (along with a
master "TAINTED" value displayed at every startup to
warn you you are on your own whenever you set values
outside of the tested range(s)), but while i have no idea
if such a patch would be accepted, at this point this is
at best a feature request without a patch, which means
it is likely to go nowhere fast. Perhaps you want to add
it to the wiki feature request page(s), if you think it is
appropriately important.

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

mythtv at tapanitarvainen

Apr 30, 2012, 9:57 PM

Post #21 of 21 (1752 views)
Permalink

Re: Number of virtual tuners [In reply to]

On Mon, Apr 30, 2012 at 10:44:00AM +0100, Simon Hobson (linux [at] thehobsons) wrote:

> >But, I think it wouldn't make things worse if the limit was removed
> >(or increased to something like highest value of channels in
> >single MUX anywhere, i.e., at least 10)
>
> That isn't a sufficient qualification - if you pad recordings

Right you are.

> So by a simplistic interpretation, you'd need a limit of 20 or more

Yes.

> - by which point, why have a limit at all ?

Indeed.

And putting the limit in the database or making it otherwise
adjustable would rather obviously be much more work than
simply removing it altogether (or raising it to something
that only acts as a sanity check, say 1000, if it's easier
to do).

> > and the help text in setup changed to include a warning like
> >"VALUES HIGHER THAN 5 REQUIRE A VERY POWERFUL SYSTEM".

> That text might also suggest that "5 is OK". I think a link to a
> wiki page would be a good idea - then the wiki page can explain the
> issues and how to choose a "good" number.

Agreed.

At this point my preference would be getting rid of the limit,
adding some warning in the help message and link to wiki.

--
Tapani Tarvainen
_______________________________________________
mythtv-users mailing list
mythtv-users [at] mythtv
http://www.mythtv.org/mailman/listinfo/mythtv-users

Index | Next | Previous | View Threaded

Interested in having your list archived? Contact Gossamer Threads