Login | Register For Free | Help
Search for: (Advanced)

Mailing List Archive: MythTV: Dev

UK Freeview "Playback"

 

 

MythTV dev RSS feed   Index | Next | Previous | View Threaded


martin.long at rozel

Aug 24, 2006, 8:37 AM

Post #1 of 25 (3638 views)
Permalink
UK Freeview "Playback"

Has anyone managed to get their hands on the technical change
specifications for Freeview "Playback"? I know that to support some of the
changes there are plans to introduce some new metadata into the EPG and
possibly some MHEG stuff too. This will include such features as:

- 'Series link' linking episodes in the same series - like season pass on
TiVo or series link on Sky+
- Trailer link - 'hyperlinks' during show trailers, allowing automatic
insertion of the show into the schedule.


I can see that some of these ideas would require enhancement of, at least:

EIT
Guide metadata tables
recording options
etc etc

If anyone has seen the details from Freeview/DTG, I would be interesting
in looking into this.

Rgds

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


stuarta at squashedfrog

Aug 24, 2006, 9:14 AM

Post #2 of 25 (3608 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

On Thu, Aug 24, 2006 at 04:37:32PM +0100, Martin Long wrote:
>
> Has anyone managed to get their hands on the technical change
> specifications for Freeview "Playback"? I know that to support some of the
> changes there are plans to introduce some new metadata into the EPG and
> possibly some MHEG stuff too. This will include such features as:

Not at the moment. I'd bet it's closed at the moment and only
available to the dtg members.

>
> - 'Series link' linking episodes in the same series - like season pass on
> TiVo or series link on Sky+
> - Trailer link - 'hyperlinks' during show trailers, allowing automatic
> insertion of the show into the schedule.
>

Most of this they will have to signal with some form of EIT data.
As soon as we can catch this in the wild it'll be coded up.

>
> I can see that some of these ideas would require enhancement of, at least:
>
> EIT
> Guide metadata tables
> recording options

A lot of the things they are proposing we already have support
for and the RT grabber populates the internal tables for us.
It's just the EIT data currently isn't up to scratch. Luckily
it seems to be improving.

>
> If anyone has seen the details from Freeview/DTG, I would be interesting
> in looking into this.

so would I.


Stuart

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


lists at youspy

Jan 5, 2007, 4:19 AM

Post #3 of 25 (3451 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

On 8/24/06, Stuart Auchterlonie <stuarta[at]squashedfrog.net> wrote:
> On Thu, Aug 24, 2006 at 04:37:32PM +0100, Martin Long wrote:
> >
> > Has anyone managed to get their hands on the technical change
> > specifications for Freeview "Playback"? I know that to support some of the
> > changes there are plans to introduce some new metadata into the EPG and
> > possibly some MHEG stuff too. This will include such features as:
>
> Not at the moment. I'd bet it's closed at the moment and only
> available to the dtg members.
>
> >

Mythtv is almost compliant, aside from a few areas:

1. Series linking and split events (I have seen people are already
working on this)
2. Recording back to back events should not register a conflict (this
was mentioned ages ago on this list - has it been looked at?)
3. Recording start and stop needs to be controlled by the EITpf. i.e.
start recording when the event to be recorded becomes the EITpf
Present event, and stop when it disappears from the EITpf. Going on
the billed time is not enough, as if a channel is running late the
EITpf update will be delayed by the channel playout automation system.
I have mentioned this loads of time on this list but never got any
answer to my question. In the UK this would be hugely beneficial. No
more missed ends/beginnings of recordings! NB. Note that if an event
is still flagged as the present event in the pf for more than 2 hours
after its billed stop time the recorder should terminate the
recording.

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


tom at compton

Jan 5, 2007, 4:30 AM

Post #4 of 25 (3452 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

In message <c08cf2fc0701050419i7704dbe0ye07c4e4707de4af3[at]mail.gmail.com>
Chris Birkinshaw <lists[at]youspy.me.uk> wrote:

> 1. Series linking and split events (I have seen people are already
> working on this)

I think this will far and away the most useful thing, assuming of
course that the data isn't too full of errors... I hope that the
data gets published on the RT feed as well as in the EIT data, but
that might be asking a bit much.

> 2. Recording back to back events should not register a conflict (this
> was mentioned ages ago on this list - has it been looked at?)

Eh? Back to back events don't generate conflicts for me... Well not
unless I set hard padding for them anyway.

> 3. Recording start and stop needs to be controlled by the EITpf. i.e.
> start recording when the event to be recorded becomes the EITpf
> Present event, and stop when it disappears from the EITpf. Going on
> the billed time is not enough, as if a channel is running late the
> EITpf update will be delayed by the channel playout automation system.
> I have mentioned this loads of time on this list but never got any
> answer to my question. In the UK this would be hugely beneficial. No
> more missed ends/beginnings of recordings! NB. Note that if an event
> is still flagged as the present event in the pf for more than 2 hours
> after its billed stop time the recorder should terminate the
> recording.

I think you have far more faith in the ability of the broadcasters
to update this information that I do... If my experience of PDC is
anything to go by even the mainstream channels seem to find this a
challenge (the BBC were probably best) and I imagine most the lesser
channels will be utterly hopeless.

It also of course introduces whole new challenges with back to back
recordings on different channels - what if one channel indicates that
it is five minutes late and the other that it is five minutes early
and you want to switch from the late one to the early one for back
to back recordings ;-)

Tom

--
Tom Hughes (tom[at]compton.nu)
http://www.compton.nu/
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


janne-mythtv at grunau

Jan 5, 2007, 4:39 AM

Post #5 of 25 (3451 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

On Friday 05 January 2007 13:19, Chris Birkinshaw wrote:
> Mythtv is almost compliant, aside from a few areas:
>
> 1. Series linking and split events (I have seen people are already
> working on this)
> 2. Recording back to back events should not register a conflict (this
> was mentioned ages ago on this list - has it been looked at?)

I'm working on this ATM.

> 3. Recording start and stop needs to be controlled by the EITpf. i.e.
> start recording when the event to be recorded becomes the EITpf
> Present event, and stop when it disappears from the EITpf.

I hope they use the running status of the event to indicate that. If
that's the case I had a PoC patch for it before I deleted it
accidentially. It's not hard and I'll redo it once I'm finished with my
current tasks.

> Going on
> the billed time is not enough, as if a channel is running late the
> EITpf update will be delayed by the channel playout automation
> system. I have mentioned this loads of time on this list but never
> got any answer to my question.

I can't remember reading such questions in the last year but I mentioned
my PoC patch here and on IRC. The last status I heard for UK was that
using running status is planned but not live (last summer).

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


stuart at tase

Jan 5, 2007, 4:40 AM

Post #6 of 25 (3454 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

On Friday 5 January 2007 12:19, Chris Birkinshaw wrote:
> On 8/24/06, Stuart Auchterlonie <stuarta[at]squashedfrog.net> wrote:
> > On Thu, Aug 24, 2006 at 04:37:32PM +0100, Martin Long wrote:
> > > Has anyone managed to get their hands on the technical change
> > > specifications for Freeview "Playback"? I know that to support some of
> > > the changes there are plans to introduce some new metadata into the EPG
> > > and possibly some MHEG stuff too.
>
> Mythtv is almost compliant, aside from a few areas:

It's not a case of mythtv's compliance so much as requiring the specs for the
additional metadata.

> 1. Series linking and split events (I have seen people are already
> working on this)

Series linking is already done in effect but without series identifiers in the
EIT it can't distinguish between different series or even accurately identify
repeats at times. This is the sort of thing which requires the information be
broadcast and which hopefully will be introduced by Freeview Playback - but
no one has seen the specs yet.

> 2. Recording back to back events should not register a conflict (this
> was mentioned ages ago on this list - has it been looked at?)

I've never, ever seen it happen unless someone is using per recording padding
in which case it is intended.

> 3. Recording start and stop needs to be controlled by the EITpf

Ending the recording according to that is fine and Janne has done work in that
area, although it doesn't actually stop the recording but places cut marks.
Starting the recording according to event is more problematic. To start early
we would need to be monitoring ahead of the programme start which may not be
possible.
--
Stuart Morgan
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


soren at dalsgaards

Jan 5, 2007, 4:47 AM

Post #7 of 25 (3447 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

> > 2. Recording back to back events should not register a conflict (this
> > was mentioned ages ago on this list - has it been looked at?)
>
> I've never, ever seen it happen unless someone is using per recording
> padding
> in which case it is intended.


Maybe this has been asked and answered before, but what is the problem in
grabbing the same program video stream into two files simultaneously thus
allowing two programs on the same channel with overlapping schedules to not
conflict?

Søren


janne-mythtv at grunau

Jan 5, 2007, 5:05 AM

Post #8 of 25 (3446 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

On Friday 05 January 2007 13:47, Søren Dalsgaard wrote:
> > > 2. Recording back to back events should not register a conflict
> > > (this was mentioned ages ago on this list - has it been looked
> > > at?)
> >
> > I've never, ever seen it happen unless someone is using per
> > recording padding
> > in which case it is intended.
>
> Maybe this has been asked and answered before, but what is the
> problem in grabbing the same program video stream into two files
> simultaneously thus allowing two programs on the same channel with
> overlapping schedules to not conflict?

Nothing, at least for the mpeg based recorders. Nobody did it up to now.
Gnome42 and I are working on it.

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


soren at dalsgaards

Jan 5, 2007, 5:24 AM

Post #9 of 25 (3450 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

> Nothing, at least for the mpeg based recorders. Nobody did it up to now.
> Gnome42 and I are working on it.


This is very nice to hear. I have been puzzled that this "problem" has been
there ever since I started with mythtv years back...

Looking very much forward to see the results of your efforts!

Søren


ric at weirdness

Jan 5, 2007, 5:28 AM

Post #10 of 25 (3506 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

Janne Grunau wrote:
> On Friday 05 January 2007 13:47, Søren Dalsgaard wrote:
>
>>>> 2. Recording back to back events should not register a conflict
>>>> (this was mentioned ages ago on this list - has it been looked
>>>> at?)
>>>>
>>> I've never, ever seen it happen unless someone is using per
>>> recording padding
>>> in which case it is intended.
>>>
>> Maybe this has been asked and answered before, but what is the
>> problem in grabbing the same program video stream into two files
>> simultaneously thus allowing two programs on the same channel with
>> overlapping schedules to not conflict?
>>
>
> Nothing, at least for the mpeg based recorders. Nobody did it up to now.
> Gnome42 and I are working on it.
On a slightly similar note, I've noticed that when two back to back
recordings are on different channels and I have system wide padding
enabled, it will cut one off to start the next - even if there is a
spare tuner available that could start the second recording thus keeping
both overlaps.
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


abostock at gmail

Jan 5, 2007, 6:06 AM

Post #11 of 25 (3451 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

That really annoys/puzzles me too.

Ash

On 1/5/07, Richard Conway <ric[at]weirdness.com> wrote:
>
> On a slightly similar note, I've noticed that when two back to back
> recordings are on different channels and I have system wide padding
> enabled, it will cut one off to start the next - even if there is a
> spare tuner available that could start the second recording thus keeping
> both overlaps.
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev[at]mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>


dm at prolingua

Jan 5, 2007, 7:14 AM

Post #12 of 25 (3448 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

Stuart Morgan wrote:
> On Friday 5 January 2007 12:19, Chris Birkinshaw wrote:
>> On 8/24/06, Stuart Auchterlonie <stuarta[at]squashedfrog.net> wrote:
>>> On Thu, Aug 24, 2006 at 04:37:32PM +0100, Martin Long wrote:
>>>> Has anyone managed to get their hands on the technical change
>>>> specifications for Freeview "Playback"? I know that to support some of
>>>> the changes there are plans to introduce some new metadata into the EPG
>>>> and possibly some MHEG stuff too.
>> Mythtv is almost compliant, aside from a few areas:
>
> It's not a case of mythtv's compliance so much as requiring the specs for the
> additional metadata.
>
>> 1. Series linking and split events (I have seen people are already
>> working on this)
>
> Series linking is already done in effect but without series identifiers in the
> EIT it can't distinguish between different series or even accurately identify
> repeats at times. This is the sort of thing which requires the information be
> broadcast and which hopefully will be introduced by Freeview Playback - but
> no one has seen the specs yet.

There are almost certainly some documents specific to Freeview Playback
that are only available within the DTG but some of this appears to be
based on ETSI standards e.g. TS 102 323 and they available free from the
ETSI site. The programme ID and series ID that the BBC are currently
transmitting in the EIT are based on that. I've been using the
programme ID information in particular for the last few weeks (see
#2811) and it is much better at detecting duplicates than textual
comparisons of the subtitle and/or description. The series ID seems to
need some improvement: generally a "series" seems to be a particular
series at a particular time. If it is repeated at a different time it
seems to have a different series ID, although the programme IDs of
repeated episodes will be the same.

>> 2. Recording back to back events should not register a conflict (this
>> was mentioned ages ago on this list - has it been looked at?)
>
>> 3. Recording start and stop needs to be controlled by the EITpf
>
> Ending the recording according to that is fine and Janne has done work in that
> area, although it doesn't actually stop the recording but places cut marks.
> Starting the recording according to event is more problematic. To start early
> we would need to be monitoring ahead of the programme start which may not be
> possible.

TS 102 323 defines several ways of detecting start and end, including
EITp/f. I have no idea how much of this the BBC are planning to
implement but I would certainly be interested in trying out a patch that
derived start and end from the EIT data. It is always going to be
necessary to tune the transport a little bit in advance and that may
depend on having a tuner available.

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


lists at youspy

Jan 5, 2007, 7:57 AM

Post #13 of 25 (3447 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

> TS 102 323 defines several ways of detecting start and end, including
> EITp/f. I have no idea how much of this the BBC are planning to
> implement but I would certainly be interested in trying out a patch that
> derived start and end from the EIT data. It is always going to be
> necessary to tune the transport a little bit in advance and that may
> depend on having a tuner available.
>

What you see off-air now is the full implementation - sorry guys! No RST!

The Freeview playback spec states that the recording will start
following an EIT refresh. i.e. the program will be recorded only while
it is the EIT Present event.

As for concerns about the broadcasters triggering this change
correctly - the BBC has been doing this for some years now and it does
not often crash. The people who monitor the central Freeview EIT
generation system are keeping an eye out for events running over their
scheduled stop time and can check if this is a legitimate scheduling
adjustment or due to a malfunction in the path of the trigger from the
broadcaster's autmation system. As Freeview Playback is about to
launch you can probably guess that people are keeping a very close eye
on the triggering systems. At some point in the future the majority of
the UK PVR population will be using this EIT triggering.

You are probably much more likely to miss the end of your program by
not enabling EIT triggering than you are to miss the beginning due to
a malfunctioning trigger... ;-)

At any rate - the question was about getting mythtv Freeview Playback
compliant/capable. In order to do this then the EIT recording
triggering needs to be sorted out. Perhaps offer some options:

1. Enable EIT triggering of recordings
2. Enable EIT trigger to set cut points only
3. Disable triggering

Regards,

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


tom at compton

Jan 5, 2007, 8:45 AM

Post #14 of 25 (3449 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

In message <c08cf2fc0701050757q2bf1ddb4g760d3f41510bff84[at]mail.gmail.com>
Chris Birkinshaw <lists[at]youspy.me.uk> wrote:

>> TS 102 323 defines several ways of detecting start and end, including
>> EITp/f. I have no idea how much of this the BBC are planning to
>> implement but I would certainly be interested in trying out a patch that
>> derived start and end from the EIT data. It is always going to be
>> necessary to tune the transport a little bit in advance and that may
>> depend on having a tuner available.
>
> What you see off-air now is the full implementation - sorry guys! No RST!

Does that also mean that this business of repeats getting different
series IDs to the original showing is here to stay? That seems rather
odd...

> As for concerns about the broadcasters triggering this change
> correctly - the BBC has been doing this for some years now and it does
> not often crash. The people who monitor the central Freeview EIT
> generation system are keeping an eye out for events running over their
> scheduled stop time and can check if this is a legitimate scheduling
> adjustment or due to a malfunction in the path of the trigger from the
> broadcaster's autmation system. As Freeview Playback is about to
> launch you can probably guess that people are keeping a very close eye
> on the triggering systems. At some point in the future the majority of
> the UK PVR population will be using this EIT triggering.
>
> You are probably much more likely to miss the end of your program by
> not enabling EIT triggering than you are to miss the beginning due to
> a malfunctioning trigger... ;-)

I've missed entire programs in the past when relying on PDC, sometimes
even on the BBC. It's why I gave up using it completely on the end - I
had given up using it on ITV (which as far as I know never actually
implemented it properly) long before.

Don't get me wrong, I'm sure the BBC at least will try reasonably hard
and probably get it right 99.9% of the time. I'm more sceptical about
some of the commercial broadcasters, especially the non-mainstream
ones that can't even manage to broadcast widescreen programming in
widescreen after umpty years of DTV.

Then again, even BBC2 has been broadcasting 14:9 letterboxed material
in a 4:3 frame on digital recently... I can only assume they've lost
the 16:9 masters somewhere and had to use a 14:9 copy. Either that or
the original This Life was actually made in 14:9 for some bizarre
reason?

Oh and I wonder whether the commercial broadcasters will do the EITp/f
transition when the program starts or when the ad break before the
program starts (and indeed the BBC with respect to trailers)? I bet
that I can guess the answer to that...

Tom

--
Tom Hughes (tom[at]compton.nu)
http://www.compton.nu/
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


stuart at tase

Jan 5, 2007, 9:17 AM

Post #15 of 25 (3449 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

On Friday 5 January 2007 16:45, Tom Hughes wrote:
> I've missed entire programs in the past when relying on PDC, sometimes
> even on the BBC. It's why I gave up using it completely on the end - I
> had given up using it on ITV (which as far as I know never actually
> implemented it properly) long before.

I doubt think we would ever rely on EIT alone to start a recording. i.e. If we
reach the programme start time but still have not seen the EITp/f then we
begin recording as normal. If the event occurs after this point then we can
create a cut point.

When it comes to ending early, if the EITp/f event occurs more than a
certain % before the programme was scheduled to end then we can ignore it to
be on the safe side.

I'm most interested in using the events to help reduce the size of recordings
and possibly resolve conflicts. i.e. Some films tend to end upto 15 minutes
before the next programme starts. If a recording ends early we should
reschedule and possibly use that 15 minutes to record something which was
previously conflicted.
--
Stuart Morgan
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


ric at weirdness

Jan 5, 2007, 9:26 AM

Post #16 of 25 (3447 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

Stuart Morgan wrote:
> On Friday 5 January 2007 16:45, Tom Hughes wrote:
>
>> I've missed entire programs in the past when relying on PDC, sometimes
>> even on the BBC. It's why I gave up using it completely on the end - I
>> had given up using it on ITV (which as far as I know never actually
>> implemented it properly) long before.
>>
>
> I doubt think we would ever rely on EIT alone to start a recording. i.e. If we
> reach the programme start time but still have not seen the EITp/f then we
> begin recording as normal. If the event occurs after this point then we can
> create a cut point.
>
> When it comes to ending early, if the EITp/f event occurs more than a
> certain % before the programme was scheduled to end then we can ignore it to
> be on the safe side.
>
Surely it could also take into account the length of the programme in
the guide as well - for instance, if the EITp/f event tells us the
programme started 10 minutes early then if the end event tells us the
programme is also ending 15 minutes early we can probably take it to be
correct (I suppose with the option of adding a cut point but still
recording until the listed end time.
> I'm most interested in using the events to help reduce the size of recordings
> and possibly resolve conflicts. i.e. Some films tend to end upto 15 minutes
> before the next programme starts. If a recording ends early we should
> reschedule and possibly use that 15 minutes to record something which was
> previously conflicted.
>
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


lists at youspy

Jan 5, 2007, 9:58 AM

Post #17 of 25 (3450 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

uld also take into account the length of the programme in
> the guide as well - for instance, if the EITp/f event tells us the
> programme started 10 minutes early then if the end event tells us the
> programme is also ending 15 minutes early we can probably take it to be
> correct

You need to remember though that sometimes an event is extended - e.g.
football - and this is perfectly valid.

How about the following behaviour - it's simple but will always work:

1. EIT refresh signals event starts early => start recording

2. Billed start time passes without EIT rollover => start recording
and then set cut point when EIT refreshes.

3. EIT refresh signals event finishes early => set cut point and
record until billed stop time
or
just stop recording when EIT refreshes (this would be very safe)

4. EIT does not refresh at billed stop time => record past billed stop
time upto max of 2 hours and then stop (this is exactly as per the
Freeview Playback spec)


If something fails in the broadcasters system you are going to get a
failure of type 2 above. As you see this would be protected against as
all we do it set a cut point.


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


lists at ebourne

Jan 5, 2007, 4:05 PM

Post #18 of 25 (3434 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

On Fri, 05 Jan 2007 14:06:35 +0000, Ashley Bostock wrote:
> On 1/5/07, Richard Conway <ric[at]weirdness.com> wrote:
>> On a slightly similar note, I've noticed that when two back to back
>> recordings are on different channels and I have system wide padding
>> enabled, it will cut one off to start the next - even if there is a
>> spare tuner available that could start the second recording thus keeping
>> both overlaps.
>>
> That really annoys/puzzles me too.

People, this has been done to death. Search the archives for softpadding.

Also, please don't top post.

Cheers,

Martin.

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


mythtv at longhome

Jan 7, 2007, 9:11 AM

Post #19 of 25 (3408 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

I can see the EITpf being an issue, because of the way tuners are
preallocated by the scheduler. The fact that a program could begin and end
at different to scheduled times could create situations where conflicts
become apparent in realtime, and need to be resolved in realtime instead of
at the next scheduler run. Also, at any point the extent of the conflict may
not be known. For example it may not be able to start recording a higher
prority recording without stopping the existing recording while it still has
EITpf. ITV may play their usual dirty tactics of delaying switching the
signals until after adverts / well into the next timeslot.

I'd imagine some of this could be resolved by running the scheduler at
certain calculated points in time, and adding additional rules to handle all
of the new edge and corner cases.

-----Original Message-----
From: mythtv-dev-bounces[at]mythtv.org [mailto:mythtv-dev-bounces[at]mythtv.org]
On Behalf Of Chris Birkinshaw
Sent: 05 January 2007 12:19
To: Development of mythtv
Subject: Re: [mythtv] UK Freeview "Playback"

On 8/24/06, Stuart Auchterlonie <stuarta[at]squashedfrog.net> wrote:
> On Thu, Aug 24, 2006 at 04:37:32PM +0100, Martin Long wrote:
> >
> > Has anyone managed to get their hands on the technical change
> > specifications for Freeview "Playback"? I know that to support some of
the
> > changes there are plans to introduce some new metadata into the EPG and
> > possibly some MHEG stuff too. This will include such features as:
>
> Not at the moment. I'd bet it's closed at the moment and only
> available to the dtg members.
>
> >

Mythtv is almost compliant, aside from a few areas:

1. Series linking and split events (I have seen people are already
working on this)
2. Recording back to back events should not register a conflict (this
was mentioned ages ago on this list - has it been looked at?)
3. Recording start and stop needs to be controlled by the EITpf. i.e.
start recording when the event to be recorded becomes the EITpf
Present event, and stop when it disappears from the EITpf. Going on
the billed time is not enough, as if a channel is running late the
EITpf update will be delayed by the channel playout automation system.
I have mentioned this loads of time on this list but never got any
answer to my question. In the UK this would be hugely beneficial. No
more missed ends/beginnings of recordings! NB. Note that if an event
is still flagged as the present event in the pf for more than 2 hours
after its billed stop time the recorder should terminate the
recording.

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

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


mythtv at longhome

Jan 7, 2007, 9:21 AM

Post #20 of 25 (3401 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

As soon as I get the chance I intend to work on a patch to do this. It
shouldn’t really be too difficult, and it would solve massive problems when
I keep deleting the start of another show!







_____

From: mythtv-dev-bounces[at]mythtv.org [mailto:mythtv-dev-bounces[at]mythtv.org]
On Behalf Of Søren Dalsgaard
Sent: 05 January 2007 12:48
To: Development of mythtv
Subject: Re: [mythtv] UK Freeview "Playback"





> 2. Recording back to back events should not register a conflict (this
> was mentioned ages ago on this list - has it been looked at?)

I've never, ever seen it happen unless someone is using per recording
padding
in which case it is intended.


Maybe this has been asked and answered before, but what is the problem in
grabbing the same program video stream into two files simultaneously thus
allowing two programs on the same channel with overlapping schedules to not
conflict?

Søren


dm at prolingua

Jan 8, 2007, 4:39 AM

Post #21 of 25 (3386 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

Martin Long wrote:
> I can see the EITpf being an issue, because of the way tuners are
> preallocated by the scheduler. The fact that a program could begin and end
> at different to scheduled times could create situations where conflicts
> become apparent in realtime, and need to be resolved in realtime instead of
> at the next scheduler run. Also, at any point the extent of the conflict may
> not be known. For example it may not be able to start recording a higher
> prority recording without stopping the existing recording while it still has
> EITpf.

I suspect that there are two classes of users with different
requirements for the scheduler. One group schedules many recordings and
wants the scheduler to avoid conflicts at the expense of possibly losing
the end of a programme if it overruns. They would probably not want to
use EITpf for scheduling even if it was available for them. There is
another group, including me, who schedule only a few recordings and
would prefer to have complete recordings at the risk of a greater chance
of conflict.

The current scheduler algorithm which tries to minimise the number of
tuners used caters better for the first group. I think there is a case
for a modified algorithm to cater for the second group. This would
allocate tuners to recordings dynamically. The algorithm might work
something like this.
Start looking for EITpf shortly before the recording is due to start.
Start recording when the show is "present" or at the scheduled time
depending on how reliable EITpf is.
Continue recording on the current tuner until the show is complete even
if it overruns.
If a second recording is due to start while the first is recording
allocate it on a different tuner if that is available otherwise delay
recording until the first finishes. It is probably better to lose the
beginning of a show rather than miss the end of one. Higher priority
recordings should probably pre-empt lower priority since the user has
explicitly said that by setting a priority.

Where EITpf is not available or not reliable soft padding should be
added to the beginning/end of timings possibly resulting in two
different tuners being used for back-to-back recordings. Only if there
is no tuner available and the beginning of a recording would otherwise
be lost should the padding be discarded. Choosing to treat padding in
this way is different from the current algorithm but from the number of
times this comes up I think this is how many people expect it to work.

The existing algorithm should be kept for those who are more concerned
about conflicts but something along the above lines will be needed if
the precise end time of a show is not known in advance.

> ITV may play their usual dirty tactics of delaying switching the
> signals until after adverts / well into the next timeslot.

But if they delay it too long wouldn't that have the effect of losing
the beginning of the next programme? They are more likely to switch
early rather than late since people may sit through the ads before
watching the show they want but will stop watching as soon as the
credits roll.

Once Freeview Playback recorders become generally available the
broadcasters will want to ensure that EITpf is accurate if that is being
used to control recording. They will need to compete with Sky+ and
there will be an incentive to ensure that people don't lose the
beginning or end of their favourite show.

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


nick at craig-wood

Jan 8, 2007, 11:00 AM

Post #22 of 25 (3376 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

On Fri, Jan 05, 2007 at 02:06:35PM +0000, Ashley Bostock wrote:
> On 1/5/07, Richard Conway <ric[at]weirdness.com> wrote:
> >On a slightly similar note, I've noticed that when two back to back
> >recordings are on different channels and I have system wide padding
> >enabled, it will cut one off to start the next - even if there is a
> >spare tuner available that could start the second recording thus keeping
> >both overlaps.
> That really annoys/puzzles me too.

You both might want to read this thread where I brought up the same
question.

http://marc2.theaimsgroup.com/?l=mythtv-users&m=114123027524947&w=4

Use the per-program start early / end late and it will all work as you
desire. The "system wide" padding doesn't do what you think it
does...

--
Nick Craig-Wood <nick[at]craig-wood.com> -- http://www.craig-wood.com/nick
_______________________________________________
mythtv-dev mailing list
mythtv-dev[at]mythtv.org
http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev


abostock at gmail

Jan 9, 2007, 8:06 AM

Post #23 of 25 (3374 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

Well this is how I'd like it to work, note: I have 2 tuners...

Recording schedule is set like:

Show is on channel 1 at 8pm-9pm
Show is on channel 1 at 9pm-10pm
Show is on channel 2 at 8pm-9pm

I want the channel 1 shows to be recorded on tuner 1 with the overlapping
padding to be cut off so that the channel 2 show can still be recorded with
padding.

However if recording schedule is set like:
Show is on channel 1 at 8pm-9pm
Show is on channel 1 at 9pm-10pm

I want tuner 1 to record the first show and tuner 2 to record the second
show both with padding.

MythTV can't do this, which is a shame but it has been discussed a load of
times and I would just have to buy a bigger case and get a 3rd tuner if it
bothered me enough (or wait for multiple recording off a single tuner to be
implemented).

Ash.

On 1/8/07, Nick Craig-Wood <nick[at]craig-wood.com> wrote:
>
> On Fri, Jan 05, 2007 at 02:06:35PM +0000, Ashley Bostock wrote:
> > On 1/5/07, Richard Conway <ric[at]weirdness.com> wrote:
> > >On a slightly similar note, I've noticed that when two back to back
> > >recordings are on different channels and I have system wide padding
> > >enabled, it will cut one off to start the next - even if there is a
> > >spare tuner available that could start the second recording thus
> keeping
> > >both overlaps.
> > That really annoys/puzzles me too.
>
> You both might want to read this thread where I brought up the same
> question.
>
> http://marc2.theaimsgroup.com/?l=mythtv-users&m=114123027524947&w=4
>
> Use the per-program start early / end late and it will all work as you
> desire. The "system wide" padding doesn't do what you think it
> does...
>
> --
> Nick Craig-Wood <nick[at]craig-wood.com> -- http://www.craig-wood.com/nick
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev[at]mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>


bradley.kite at gmail

Jun 4, 2007, 6:56 AM

Post #24 of 25 (2632 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

On 09/01/07, Ashley Bostock <abostock[at]gmail.com> wrote:
>
> Well this is how I'd like it to work, note: I have 2 tuners...
>
> Recording schedule is set like:
>
> Show is on channel 1 at 8pm-9pm
> Show is on channel 1 at 9pm-10pm
> Show is on channel 2 at 8pm-9pm
>
> I want the channel 1 shows to be recorded on tuner 1 with the overlapping
> padding to be cut off so that the channel 2 show can still be recorded with
> padding.
>
> However if recording schedule is set like:
> Show is on channel 1 at 8pm-9pm
> Show is on channel 1 at 9pm-10pm
>
> I want tuner 1 to record the first show and tuner 2 to record the second
> show both with padding.
>
> MythTV can't do this, which is a shame but it has been discussed a load of
> times and I would just have to buy a bigger case and get a 3rd tuner if it
> bothered me enough (or wait for multiple recording off a single tuner to be
> implemented).
>
> Ash.
>
> On 1/8/07, Nick Craig-Wood <nick[at]craig-wood.com> wrote:
> >
> > On Fri, Jan 05, 2007 at 02:06:35PM +0000, Ashley Bostock wrote:
> > > On 1/5/07, Richard Conway <ric[at]weirdness.com> wrote:
> > > >On a slightly similar note, I've noticed that when two back to back
> > > >recordings are on different channels and I have system wide padding
> > > >enabled, it will cut one off to start the next - even if there is a
> > > >spare tuner available that could start the second recording thus
> > keeping
> > > >both overlaps.
> > > That really annoys/puzzles me too.
> >
> > You both might want to read this thread where I brought up the same
> > question.
> >
> > http://marc2.theaimsgroup.com/?l=mythtv-users&m=114123027524947&w=4
> >
> > Use the per-program start early / end late and it will all work as you
> > desire. The "system wide" padding doesn't do what you think it
> > does...
> >
> > --
> > Nick Craig-Wood <nick[at]craig-wood.com> -- http://www.craig-wood.com/nick
> > _______________________________________________
> > mythtv-dev mailing list
> > mythtv-dev[at]mythtv.org
> > http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
> >
>
>
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev[at]mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>
>

This thread hasnt been discussed for a while, and I was just wondering if
thats because "Freeview Playback" compliance has already been implemented
(to an extent) or if its dependant on other developments (like the
mythtv-multirec branch for overlapping start-early/end-late shows?) before
it can be fully implemented?

I am currently running the 0.20-fixes branch, but would consider tracking
-HEAD if these features were implemented there.

Thanks in advance
--
Brad.


bradley.kite at gmail

Feb 12, 2008, 4:03 AM

Post #25 of 25 (1720 views)
Permalink
Re: UK Freeview "Playback" [In reply to]

On 05/01/2007, Janne Grunau <janne-mythtv[at]grunau.be> wrote:
> On Friday 05 January 2007 13:19, Chris Birkinshaw wrote:
> > Mythtv is almost compliant, aside from a few areas:
> >
> > 1. Series linking and split events (I have seen people are already
> > working on this)
> > 2. Recording back to back events should not register a conflict (this
> > was mentioned ages ago on this list - has it been looked at?)
>
> I'm working on this ATM.
>
> > 3. Recording start and stop needs to be controlled by the EITpf. i.e.
> > start recording when the event to be recorded becomes the EITpf
> > Present event, and stop when it disappears from the EITpf.
>
> I hope they use the running status of the event to indicate that. If
> that's the case I had a PoC patch for it before I deleted it
> accidentially. It's not hard and I'll redo it once I'm finished with my
> current tasks.
>
> > Going on
> > the billed time is not enough, as if a channel is running late the
> > EITpf update will be delayed by the channel playout automation
> > system. I have mentioned this loads of time on this list but never
> > got any answer to my question.
>
> I can't remember reading such questions in the last year but I mentioned
> my PoC patch here and on IRC. The last status I heard for UK was that
> using running status is planned but not live (last summer).
>
> Janne
> _______________________________________________
> mythtv-dev mailing list
> mythtv-dev[at]mythtv.org
> http://mythtv.org/cgi-bin/mailman/listinfo/mythtv-dev
>

Hi all

I know this thread is quite old, but now that multirec has been merged
I'd like to see what I can do to implement point 3 above (start/end
recording when EITpf flag is seen).

I've been poking around the code, and these are some of my notes - can
somebody who knows more about this than I do please comment on
correctness or propose a better way that I should be doing this:

Use startEarly and endLate for the schedular to pre-book a tuner (this
is what currently happens any way).
End-Late is to be changed to be the max over-run of a program. Even if the
program ends on-time, the tuner will still be (intially) booked out
for that long.

Introduce a "Will be recoreded if previous program does not over-run" flag.
Introduce a threshold value of 60 or 120 seconds so that if the
recording overruns up to <threshold> seconds then just delay the start
of the next recording by up-to that long.

Get the DVBRecorder to register an EITListener
(DVBStreamData::AddDVBEITListener() ) and only start writing packets
to disk when the program is seen in the EITpf field.

Keep watching the EIT tables while the recording is in progress. When
the program disappears from the EIT table then stop recording, and
re-run the schedular so that any program scheduled to record
afterwards that was set to
"might be recorded" can now be considered.

Recorder must implement a
DVBRecorder::HandleEIT(DVBEventInformationTable *eit) method to look
for Program Flags.

Would this be the right way to go about it? Any other thoughts/comments?

Many thanks.

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

MythTV dev RSS feed   Index | Next | Previous | View Threaded
 
 


Interested in having your list archived? Contact lists@gossamer-threads.com
 
  Web Applications & Managed Hosting Powered by Gossamer Threads Inc.