Mailing List Archive

1 2 3  View All
Re: Events at the beginning of a recording [ In reply to ]
On 09/02/2023 09:58, Jan Ceuleers wrote:
> On 09/02/2023 04:36, David Engel wrote:
>>> But I still might! Someday. When I have a better solution to the
>>> misuse. I've never bought the "my guide data is bad" argument and I
>>> still don't. In the immortal words of Steve Jobs, "You're doing it
>>> wrong?" :)
>>>
>>> Either you care about catching the beginning or ends or your
>>> recordings or you don't.
>>
>> Also, how many of you that claim you must have long pre- and
>> post-rolls have actually tried using start early/end late instead? I
>> suspect most of you would get by just fine.
>
> Just to state my understanding of your point: I believe you refer to
> specifying pre and post-roll in recording rules, is that right? (Perhaps
> I'm not using the correct terminology here; apologies if so).
>
> If so, the reason why I am now using the global pre-roll feature is
> that, in my understanding, it enables back-to-back recordings on the
> same capture card, whereas with recording rule-specified pre/post-rolls
> two capture cards are needed to record back-to-back programs.
>
Maybe your more complex system has this problem, but I have no such
difficulty with my DVB-T/T2 tuners when using a default recording rule,
2m early 4m late, with EIT data. Most of my recordings are
single-record only, aand back-to-back happens often.

John P

> The other reason is one of convenience: it is easier to specify
> pre/post-roll periods in only one place rather than having to do so in
> each recording rule. Particularly if a bad experience shows that the
> pre/post-roll periods need to be extended. Please keep in mind that the
> guide data unreliability we face here is universal and unpredictable, so
> the pre/post-roll periods need to be applied to all recordings.
>
> I used to use recording rule-specified pre/post-rolls but switched to
> the global approach for these reasons.
>
> BTW (and I don't mean to annoy you), a dream feature sidestepping the
> first reason above would be to add "multirec" capabilities to all
> capture cards, by regarding a regular (currently non-multirec capable)
> tuner as one that has as many "multiplexes" as it has channels it can
> tune to (i.e. 1 channel = 1 multiplex), such that a channel can be
> recorded from multiple times at once. This would enable recording
> back-to-back shows, with each recording containing its own pre/post-roll.
>
>>> If you do care, you should use the start early/end late options.
>>> That's what they are for(*). If there is a conflict, wouldn't you
>>> really rather have the scheduler choose a later showing that woh't get
>>> chopped off? IMO, that's much better hoping that the tetris blocks
>>> just happen to fall in perfect way by accident. If there is a
>>> conflict, the scheduler will tell you so that YOU can make the best,
>>> informed decision on what to do.
>
> I'm afraid I don't understand this point. The scheduler cannot know
> whether a show is going to be chopped off because it can only base its
> decisions on the guide data it has at its disposal. If that guide data
> is unreliable all bets are off.
>
> HTH, Jan
> _______________________________________________
> mythtv-users mailing list
> mythtv-users@mythtv.org
> http://lists.mythtv.org/mailman/listinfo/mythtv-users
> http://wiki.mythtv.org/Mailing_List_etiquette
> MythTV Forums: https://forum.mythtv.org

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Events at the beginning of a recording [ In reply to ]
On 09/02/2023 12:33, John Pilkington wrote:
>> Just to state my understanding of your point: I believe you refer to
>> specifying pre and post-roll in recording rules, is that right? (Perhaps
>> I'm not using the correct terminology here; apologies if so).
>>
>> If so, the reason why I am now using the global pre-roll feature is
>> that, in my understanding, it enables back-to-back recordings on the
>> same capture card, whereas with recording rule-specified pre/post-rolls
>> two capture cards are needed to record back-to-back programs.
>>
> Maybe your more complex system has this problem, but I have no such
> difficulty with my DVB-T/T2 tuners when using a default recording rule,
> 2m early 4m late, with EIT data.  Most of my recordings are
> single-record only, aand back-to-back happens often.

Yes, a multirec-capable tuner (which most DVB-x tuners are) does not
have this problem to the same extent, because they natively support the
concept of multiplexes which MythTV's multirec capability was designed
for. My HDHR DVB-C tuner, for example, also does not, in that it has
multiple virtual tuners available that can be swung into service for the
purpose of back-to-back recordings (or indeed for parallel recordings of
any combination of channels on the same multiplex).

But the encrypted channels my cable company provides need to be accessed
by means of a set-top box, and there is presently no "multirec"
capability for one-channel-at-a-time capture cards.

Cheers, Jan

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Events at the beginning of a recording [ In reply to ]
On Thu, 9 Feb 2023 at 13:15, Jan Ceuleers <jan.ceuleers@gmail.com> wrote:

> On 09/02/2023 12:33, John Pilkington wrote:
> >> Just to state my understanding of your point: I believe you refer to
> >> specifying pre and post-roll in recording rules, is that right? (Perhaps
> >> I'm not using the correct terminology here; apologies if so).
> >>
> >> If so, the reason why I am now using the global pre-roll feature is
> >> that, in my understanding, it enables back-to-back recordings on the
> >> same capture card, whereas with recording rule-specified pre/post-rolls
> >> two capture cards are needed to record back-to-back programs.
> >>
> > Maybe your more complex system has this problem, but I have no such
> > difficulty with my DVB-T/T2 tuners when using a default recording rule,
> > 2m early 4m late, with EIT data. Most of my recordings are
> > single-record only, aand back-to-back happens often.
>
> Yes, a multirec-capable tuner (which most DVB-x tuners are) does not
> have this problem to the same extent, because they natively support the
> concept of multiplexes which MythTV's multirec capability was designed
> for. My HDHR DVB-C tuner, for example, also does not, in that it has
> multiple virtual tuners available that can be swung into service for the
> purpose of back-to-back recordings (or indeed for parallel recordings of
> any combination of channels on the same multiplex).
>
> But the encrypted channels my cable company provides need to be accessed
> by means of a set-top box, and there is presently no "multirec"
> capability for one-channel-at-a-time capture cards.
>
> Cheers, Jan
>
> I have just now created a pull request #716 (
https://github.com/MythTV/mythtv/pull/716) with a fix that does solve the
REC_PENDING event issue in my testing.

Klaas.
Re: Events at the beginning of a recording [ In reply to ]
On Thu, Feb 09, 2023 at 10:58:28AM +0100, Jan Ceuleers wrote:
> On 09/02/2023 04:36, David Engel wrote:
> >> But I still might! Someday. When I have a better solution to the
> >> misuse. I've never bought the "my guide data is bad" argument and I
> >> still don't. In the immortal words of Steve Jobs, "You're doing it
> >> wrong?" :)
> >>
> >> Either you care about catching the beginning or ends or your
> >> recordings or you don't.
> >
> > Also, how many of you that claim you must have long pre- and
> > post-rolls have actually tried using start early/end late instead? I
> > suspect most of you would get by just fine.
>
> Just to state my understanding of your point: I believe you refer to
> specifying pre and post-roll in recording rules, is that right? (Perhaps
> I'm not using the correct terminology here; apologies if so).

We settled on the following terminolgoy long ago, to avoid this
confusion.

Start early and end late are options in every recording rule. They
are specified in minutes and are intended for cases where the probram
is expceted to or might begin early or run long. The scheduler will
attempt work around these constrains by moving recordings to later of
lower priority tuners to honor the full recording time. In cases
where the full recording time can't be honored, the scheduler will
report a conflict so the user can make the best informed decision on
what to do.

Pre foll and post roll, are global options. They are specified in
seconds and are intended to setup and tead down tuners if the tuner is
not already busy. They are entirely optional and are not guaranteed
to be used. This is what I contend is misused by many people as a
scheduling feature.

> If so, the reason why I am now using the global pre-roll feature is
> that, in my understanding, it enables back-to-back recordings on the
> same capture card, whereas with recording rule-specified pre/post-rolls
> two capture cards are needed to record back-to-back programs.

This is what doesn't compute for me. Users say they absolutely have
to have this feature because their guide data is inaccurate and
without it, they'll miss the beginnings or ends of their shows. Yet,
there's no guarantee this feature will kick in so they still miss
parts of their shows. Then they go one step further and say without
it being optional , they can't schedule show back to back which,
again, will miss parts of their shows.

Why not use the necessary padding in the first place? In the case
where there is a conflict, then you can make the choice of which part
of which show to miss that best fits your needs. Admittedly, MythTV
doesn't do as good of a job of notifying about conflicts as it should.
I've got an incomplete patch that remedies that.

> The other reason is one of convenience: it is easier to specify
> pre/post-roll periods in only one place rather than having to do so in
> each recording rule. Particularly if a bad experience shows that the
> pre/post-roll periods need to be extended. Please keep in mind that the
> guide data unreliability we face here is universal and unpredictable, so
> the pre/post-roll periods need to be applied to all recordings.

Recording, rule templates already make it easy to apply custom,
defaults to all new rules. It wouldn't be hard to add the ability to
optionally apply template changes to all rules.

> I used to use recording rule-specified pre/post-rolls but switched to
> the global approach for these reasons.
>
> BTW (and I don't mean to annoy you), a dream feature sidestepping the
> first reason above would be to add "multirec" capabilities to all
> capture cards, by regarding a regular (currently non-multirec capable)
> tuner as one that has as many "multiplexes" as it has channels it can
> tune to (i.e. 1 channel = 1 multiplex), such that a channel can be
> recorded from multiple times at once. This would enable recording
> back-to-back shows, with each recording containing its own pre/post-roll.

I don't fully understand your point here. However, I have two
comments that might address it.

First, a former developer added a hack long, long ago (yes, this same
discussion has benn going on nearyly 20 years) to quell the masses.
It intentionally avoids putting incompatible recordings back to back
except when it has to be done to avoid conflicts.

Second, MythTV has had the ability for a couple of years now to create
virtual tuners as needed to support overlapping recordings on the same
channel or multiplex. It currently only kicks in for hard overlaps
but would be trivial to extend for back to back recordings too.

> >> If you do care, you should use the start early/end late options.
> >> That's what they are for(*). If there is a conflict, wouldn't you
> >> really rather have the scheduler choose a later showing that woh't get
> >> chopped off? IMO, that's much better hoping that the tetris blocks
> >> just happen to fall in perfect way by accident. If there is a
> >> conflict, the scheduler will tell you so that YOU can make the best,
> >> informed decision on what to do.
>
> I'm afraid I don't understand this point. The scheduler cannot know
> whether a show is going to be chopped off because it can only base its
> decisions on the guide data it has at its disposal. If that guide data
> is unreliable all bets are off.

That's exactly my point from a above about not making sense. Only you
can make the best decision for your cases. Why do you want to let
MythTV essentially make a random decision?

David
--
David Engel
david@istwok.net
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Events at the beginning of a recording [ In reply to ]
On Fri, 10 Feb 2023 17:50:40 -0600, you wrote:

>On Thu, Feb 09, 2023 at 10:58:28AM +0100, Jan Ceuleers wrote:
>> On 09/02/2023 04:36, David Engel wrote:
>> >> But I still might! Someday. When I have a better solution to the
>> >> misuse. I've never bought the "my guide data is bad" argument and I
>> >> still don't. In the immortal words of Steve Jobs, "You're doing it
>> >> wrong?" :)
>> >>
>> >> Either you care about catching the beginning or ends or your
>> >> recordings or you don't.
>> >
>> > Also, how many of you that claim you must have long pre- and
>> > post-rolls have actually tried using start early/end late instead? I
>> > suspect most of you would get by just fine.
>>
>> Just to state my understanding of your point: I believe you refer to
>> specifying pre and post-roll in recording rules, is that right? (Perhaps
>> I'm not using the correct terminology here; apologies if so).
>
>We settled on the following terminolgoy long ago, to avoid this
>confusion.
>
>Start early and end late are options in every recording rule. They
>are specified in minutes and are intended for cases where the probram
>is expceted to or might begin early or run long. The scheduler will
>attempt work around these constrains by moving recordings to later of
>lower priority tuners to honor the full recording time. In cases
>where the full recording time can't be honored, the scheduler will
>report a conflict so the user can make the best informed decision on
>what to do.
>
>Pre foll and post roll, are global options. They are specified in
>seconds and are intended to setup and tead down tuners if the tuner is
>not already busy. They are entirely optional and are not guaranteed
>to be used. This is what I contend is misused by many people as a
>scheduling feature.
>
>> If so, the reason why I am now using the global pre-roll feature is
>> that, in my understanding, it enables back-to-back recordings on the
>> same capture card, whereas with recording rule-specified pre/post-rolls
>> two capture cards are needed to record back-to-back programs.
>
>This is what doesn't compute for me. Users say they absolutely have
>to have this feature because their guide data is inaccurate and
>without it, they'll miss the beginnings or ends of their shows. Yet,
>there's no guarantee this feature will kick in so they still miss
>parts of their shows. Then they go one step further and say without
>it being optional , they can't schedule show back to back which,
>again, will miss parts of their shows.
>
>Why not use the necessary padding in the first place? In the case
>where there is a conflict, then you can make the choice of which part
>of which show to miss that best fits your needs. Admittedly, MythTV
>doesn't do as good of a job of notifying about conflicts as it should.
>I've got an incomplete patch that remedies that.
>
>> The other reason is one of convenience: it is easier to specify
>> pre/post-roll periods in only one place rather than having to do so in
>> each recording rule. Particularly if a bad experience shows that the
>> pre/post-roll periods need to be extended. Please keep in mind that the
>> guide data unreliability we face here is universal and unpredictable, so
>> the pre/post-roll periods need to be applied to all recordings.
>
>Recording, rule templates already make it easy to apply custom,
>defaults to all new rules. It wouldn't be hard to add the ability to
>optionally apply template changes to all rules.
>
>> I used to use recording rule-specified pre/post-rolls but switched to
>> the global approach for these reasons.
>>
>> BTW (and I don't mean to annoy you), a dream feature sidestepping the
>> first reason above would be to add "multirec" capabilities to all
>> capture cards, by regarding a regular (currently non-multirec capable)
>> tuner as one that has as many "multiplexes" as it has channels it can
>> tune to (i.e. 1 channel = 1 multiplex), such that a channel can be
>> recorded from multiple times at once. This would enable recording
>> back-to-back shows, with each recording containing its own pre/post-roll.
>
>I don't fully understand your point here. However, I have two
>comments that might address it.
>
>First, a former developer added a hack long, long ago (yes, this same
>discussion has benn going on nearyly 20 years) to quell the masses.
>It intentionally avoids putting incompatible recordings back to back
>except when it has to be done to avoid conflicts.
>
>Second, MythTV has had the ability for a couple of years now to create
>virtual tuners as needed to support overlapping recordings on the same
>channel or multiplex. It currently only kicks in for hard overlaps
>but would be trivial to extend for back to back recordings too.
>
>> >> If you do care, you should use the start early/end late options.
>> >> That's what they are for(*). If there is a conflict, wouldn't you
>> >> really rather have the scheduler choose a later showing that woh't get
>> >> chopped off? IMO, that's much better hoping that the tetris blocks
>> >> just happen to fall in perfect way by accident. If there is a
>> >> conflict, the scheduler will tell you so that YOU can make the best,
>> >> informed decision on what to do.
>>
>> I'm afraid I don't understand this point. The scheduler cannot know
>> whether a show is going to be chopped off because it can only base its
>> decisions on the guide data it has at its disposal. If that guide data
>> is unreliable all bets are off.
>
>That's exactly my point from a above about not making sense. Only you
>can make the best decision for your cases. Why do you want to let
>MythTV essentially make a random decision?
>
>David

When you are using tuners that do multirec and automatically overlap
back-to-back recordings, then using the start early and end late
options in the recording rule works well. That is what I do. But
back when I had to record from a set top box using a single analogue
tuner, that would not work because the tuner could not do multirec at
all. So in that case, the fact that the global pre- and post-roll
settings are not used for back-to-back recordings was the thing that
made it possible to record that way. You did run into the situation
where the beginning of one program was recorded on the end of the
previous program, but you just learned to live with that and
remembered to not delete the previous program until you had watched
the bit on the end of it. So my guess is that Jan is in the same
situation now, and what he really needs is the ability to set the
number of virtual tuners to 2 and have his single tuners do overlapped
recordings when they are back-to-back. If he had that, then he could
then just use the normal start early and end late settings. I do not
know what sort of tuners Jan is using, and it is actually possible
that they do now support that limited multirec mode. It was added to
a number of tuners a long time ago and it is what I have been using
with my IPTV tuners for a long time now.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Events at the beginning of a recording [ In reply to ]
On 11/02/2023 04:03, Stephen Worthington wrote:
> When you are using tuners that do multirec and automatically overlap
> back-to-back recordings, then using the start early and end late
> options in the recording rule works well. That is what I do. But
> back when I had to record from a set top box using a single analogue
> tuner, that would not work because the tuner could not do multirec at
> all. So in that case, the fact that the global pre- and post-roll
> settings are not used for back-to-back recordings was the thing that
> made it possible to record that way. You did run into the situation
> where the beginning of one program was recorded on the end of the
> previous program, but you just learned to live with that and
> remembered to not delete the previous program until you had watched
> the bit on the end of it. So my guess is that Jan is in the same
> situation now, and what he really needs is the ability to set the
> number of virtual tuners to 2 and have his single tuners do overlapped
> recordings when they are back-to-back. If he had that, then he could
> then just use the normal start early and end late settings. I do not
> know what sort of tuners Jan is using, and it is actually possible
> that they do now support that limited multirec mode. It was added to
> a number of tuners a long time ago and it is what I have been using
> with my IPTV tuners for a long time now.

Stephen's interpretation of what I was saying was right.

But David was also right in that I wasn't aware that the new
mythexternrecorder-based capture cards I am now using are in fact
capable of multirec. So the "dream feature" I described in my previous
post is in fact already available, and I hadn't noticed. Thank you!!

So I will pivot back to using start early/end late.

Thanks to all, particularly to Klaas for fixing the problem I reported.

Jan
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Events at the beginning of a recording [ In reply to ]
On Thu, Feb 9, 2023 at 3:10 AM David Engel <david@istwok.net> wrote:

> But I still might! Someday. When I have a better solution to the
> misuse. I've never bought the "my guide data is bad" argument and I
> still don't. In the immortal words of Steve Jobs, "You're doing it
> wrong?" :)


I thought that was "Just avoid holding it in that way",
commonly reported as "You're holding it wrong".



However, more to the point, I am going to add something
that may be somewhat controversial, but I do believe
that you should over-provision the number of tuners so
that conflicts are minimal and the scheduler does not
need to make hard (or impossible) decisions.

To paraphrase Ms. Simpson: "You can never be too rich, or too thin, or
have too many tuners"

Yes, I do understand there are sometimes other
constraints (tuners cost money, slots may be
limited), but sooner or later you are going to find
that if you run too hot (using all tuners almost all
the time) something will not be able to be
recorded (the scheduler is very good, but it
cannot create time[0]). Some networks and
stations intentionally shift the show time by a few
minutes to discourage channel surfing. Some
seem to do it because they are unable to set their
clocks accurately (maybe they should hire
a few train conductors?). But no matter the
cause, overlaps happen that can require more
tuners than one might otherwise wish to own,
but your wishes are not relevant to the stations.

In my location, at the beginning of the new
TV season, I often schedule recordings of
a lot of the new series that seem like they might
have promise. And while I typically decide
most of those shows are not worth continuing
to watch, and cancel the recordings, during
those first few weeks I can easily find I need at
least five physical tuners (even with virtual and
sub-channel tuning capability), although I would
otherwise rarely be using more than three
(and usually just one or two). For the record,
I have six tuners.

So, to Steve Jobs it, "Just buy more tuners!"





[0] I have no doubt creating (free) time is on
the wish list of many.
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Events at the beginning of a recording [ In reply to ]
On 09/02/2023 22:26, Klaas de Waal wrote:
> I have just now created a pull request #716
> (https://github.com/MythTV/mythtv/pull/716
> <https://github.com/MythTV/mythtv/pull/716>) with a fix that does solve
> the REC_PENDING event issue in my testing.

Hi Klaas.

Thanks again for doing this work.

I see that the patch is still under review though. Any updates?

Many thanks, Jan
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Events at the beginning of a recording [ In reply to ]
On Fri, 17 Feb 2023 at 17:24, Jan Ceuleers <jan.ceuleers@gmail.com> wrote:

> On 09/02/2023 22:26, Klaas de Waal wrote:
> > I have just now created a pull request #716
> > (https://github.com/MythTV/mythtv/pull/716
> > <https://github.com/MythTV/mythtv/pull/716>) with a fix that does solve
> > the REC_PENDING event issue in my testing.
>
> Hi Klaas.
>
> Thanks again for doing this work.
>
> I see that the patch is still under review though. Any updates?
>
> Hi Jan,

I did not get any review comments so I concluded that everybody was happy
with the changes.
I have committed it to master, then two days later to fixes/33 and then
closed the pull request.
So it should just work now if you update to the latest, either fixes/33 or
master.

Thanks for reporting and testing,
Klaas.
Re: Events at the beginning of a recording [ In reply to ]
On 17/02/2023 17:55, Klaas de Waal wrote:
> I have committed it to master, then two days later to fixes/33 and then
> closed the pull request.
> So it should just work now if you update to the latest, either fixes/33
> or master.

I'm on fixes/33 and have updated to the latest mythbuntu packages, and I
do now indeed get REC_PENDING events at 120s, 90s, 60s and 30s before
recordings, so I no longer need to delay my channel changes.

Thanks again.

Cheers, Jan
_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Events at the beginning of a recording [ In reply to ]
On 25/01/2023 20:31, Hika van den Hoven wrote:
> If you wait a few months, I'll publish my management application.

Hika,

I ended up not waiting; see the wiki article I posted earlier today for
a description of what I did. See the "saving power" section and the
hcpow.sh script.

https://www.mythtv.org/wiki/Recording_from_HDMI

HTH, Jan

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org
Re: Events at the beginning of a recording [ In reply to ]
Hoi Jan,

Saturday, February 18, 2023, 7:16:14 PM, you wrote:

> On 25/01/2023 20:31, Hika van den Hoven wrote:
>> If you wait a few months, I'll publish my management application.

> Hika,

> I ended up not waiting; see the wiki article I posted earlier today for
> a description of what I did. See the "saving power" section and the
> hcpow.sh script.

> https://www.mythtv.org/wiki/Recording_from_HDMI

> HTH, Jan

I followed the whole discussion with much interest.



Tot mails,
Hika mailto:hikavdh@gmail.com

"Zonder hoop kun je niet leven
Zonder leven is er geen hoop
Het eeuwige dilemma
Zeker als je hoop moet vernietigen om te kunnen overleven!"

De lerende Mens

_______________________________________________
mythtv-users mailing list
mythtv-users@mythtv.org
http://lists.mythtv.org/mailman/listinfo/mythtv-users
http://wiki.mythtv.org/Mailing_List_etiquette
MythTV Forums: https://forum.mythtv.org

1 2 3  View All