Tvheadend

I did some looking using dvbsnoop and the PDC event doesn't seem to appear.

However, I notice that each event in the EIT has a 'Running_status' shown in dvbsnoop. Could Freeview+ use this 'running_status' to determine when to start recording?

Event_ID: 60522 (0xec6a)
    Start_time: 0xdc09223000 [= 2013-02-06 22:30:00 (UTC)]
    Duration: 0x0020000 [=  02:00:00 (UTC)]
    Running_status: 1 (0x01)  [= not running]
    Free_CA_mode: 0 (0x00)  [= unscrambled]
    Descriptors_loop_length: 96 (0x60)

DVB-DescriptorTag: 84 (0x54)  [= content_descriptor]
            descriptor_length: 2 (0x02)
               Content_nibble_level_1: 0 (0x00)
               Content_nibble_level_2: 0 (0x00)
                  [= reserved]               User_nibble_1: 0 (0x00)
               User_nibble_2: 0 (0x00)

DVB-DescriptorTag: 77 (0x4d)  [= short_event_descriptor]
            descriptor_length: 90 (0x5a)
              ISO639_2_language_code:  eng
            event_name_length: 14 (0x0e)
            event_name: "Racing Replay"  -- Charset: reserved
            text_length: 71 (0x47)
            text_char: "A round up of today's racing action from Carlisle, Ludlow and Kempton."  -- Charset: 
reserved

Most of this, can be done using EITpf. I'm not exactly sure how Free* does it. It has been requested before and it is on my list of things to investigate, but unlike the well controlled environment of a Free* STB the more general nature of TVH present a few additional challenges that have to be worked out.

EIT processing is obviously done within TVH, however the installation of table handlers is handled by the EIT code rather than in dvb_tables.c.

Adam

If my understanding is correct it looks like the EITpf information is transmitted in the 'Extended Event table 0x4E' within the EIT, which is parsed within '_eit_desc_ext_event'.

I'll see if I can familiarise myself with the code to see how this could be added.

Presumably the code would need to:

1) Before start recording wait until the EIT 'present' programme matches the one to record
2) During recording keep monitoring the EIT 'present' programme and don't stop recording until it changes

I'm not yet familiar with the code, but presumably this would have to be done in a way which is compatible with recordings not using the EITpf, and there may be threading issues if EIT etc is read in another thread to the recording thread.

Colin

Colin,

EITpf is transmitted in table 0x4E (this mux) and 0x4F (other mux). That is quite distinct from descriptors (which are within tables). The table is already processed, however we don't use the actual changeover time (which is what you need) to define the event time.

Normally EIT events have a start/stop time defined. With EITpf, the idea is this contains the present and next events. And that for accurate timing (diff to the scheduled time) the present/next events will be updated at the exact time that the next event starts.

That in itself is not a big problem, all the code necessary to detect the changes is already there. The problem is integrating that into a very generic system that must cope with all manner of different configurations, some of which might not have/use EIT. Starting early is trivial, IF you get an EITpf update before the scheduled time then that represents the start. However late is trickier, given that you might not be able to rely on EITpf when do you give up and timeout? probably too late. So you need a way of knowing the EITpf is present, signalling that to the DVR code and then acting on that if and only if its present.

All doable and all part of my DVR rewrite plans, just not had a chance to get around to it yet.

Adam

Hi,

Sorry to re-open an old thread but did this go anywhere - since becoming frustrated with my Set top box I want to see if I can use TVHeadend instead but at the moment the skipping time at the beginning of a recording and time cut off at the end is a bit of a deal breaker for the family as it isn't as user friendly as the current box.

Neil

Neil,

I didn't feel qualified to reply but as nobody else has - I think the short answer is there has been no change.

I'll just do a dump of my notes here:

I did an experiment myself by hacking a different EIT parser and the "now and next" information definitely updates accurately when the programme starts with UK terrestrial Freeview - this shows how some UK BBC1 programs start a bit early :

---TIME 18:29:11 Channel: 4220 Event: 48928 Start: start="2013-10-03 18:30:00"
---TIME 18:57:54 Channel: 4220 Event: 48453 Start: start="2013-10-03 19:00:00"

This was obtained (as suggested above by Adam) by looking at Section 0 of EIT table 0x4e. The event running_status is set to 4 whenever the programme is running.

I need to study the tvheadend code more to be able to make modifications to add this.

A sketchy braindump of my notes so far are:

eit parser (src/epggrab/module/eit.c) has some kind of reschedule thing in it - what is save2 etc?

/* Find broadcast */
  ebc  = epg_broadcast_find_by_time(svc->s_ch, start, stop, eid, 1, &save2);
  tvhtrace("eit", "eid=%5d, start=%"PRItime_t", stop=%"PRItime_t", ebc=%p",
         eid, start, stop, ebc);
  if (!ebc) return dllen + 12;

/* Mark re-schedule detect (only now/next) */
  if (save2 && tableid < 0x50) *resched = 1;

This ultimately calls 'epggrab_resched()' which I don't think does anything.

dvr/dvr_rec.c seems to be the thread that performs dvr recordings and actually writing to the file. It waits for a 'streaming_message' from a 'streaming queue'. This thread calls muxer_write_pkt etc depending on the message received - SMT_START or SMT_MPEGTS etc

The recording thread is created from dvr_rec_subscribe(), which takes a dvr_entry_t. This is called from dvr_timer_start_recording() in dvr_db.c, which in turn is called from dvr_entry_set_timer() which sets a timer via gtimer_arm_abs().

This is set from dvr_entry_link and dvr_entry_update

service_restart() sends the SMT_START service messages. Perhaps store the currently running event_id in the service? This restart message is sent from psi_parse_pmt() which looks for changes in elementary streams etc.

RECORDING STOP:
---------------
When the recording is started a timer is set for the end time.

dvr_thread stops running when an SMT_EXIT message is received. This is created from dvr_rec_unsubscribe via streaming_target_deliver() from dvr_stop_recording() from dvr_timer_stop_recording(). This is called from dvr_timer_start_recording() and sets the timer as the stop time, plus however minutes extra are configured.

DVR_RS_WAIT_PROGRAM_START is a dvr_entry_t->de_rec_state entry

I think that ts_remux() adds SMT_MPEGTS data via streaming_pad_deliver from ts_recv_packet0, from ts_recv_packet1() or ts_recv_packet2 which are called from dvb_adapter_input_dvr() which actually reads data from the /dev/dvrX device and which is created from dvb_adapter_start().

Bit sketchy I know, but just sharing this (quite probably incorrect) brain dump just now in case anyone is interested!

Colin

Hi,

Following on from my brain dump notes I wondered if something like the following would be feasible:

Into the struct service add either the current DVB event ID, or alternatively a link into the program guide structure for the currently running program. This is updated from the EIT parser.

Whenever this changes, send a new streaming_message_t EIT_EVENT_CHANGED or similar.

By default, the DVR would be set with a reasonably large time margin ahead and at the end of the programs. The DVR would listen for this EIT_EVENT_CHANGED message and start recording if the event matched the one it was waiting for, and stop recording if it didn't. The stop recording would only happen if it had been started by the event changed - which I think would avoid the problem Adam mentioned.

Does this approach sound feasible? I'm not sure how the threading would work out.

Colin

Hi Colin,

Sorry for the delay. I've not looked at the code yet. Regarding the general idea - only stopping if started from the schedule sounds right or maybe also take into account the original length - after all a 2 hour programme that starts early/late will still be 2 hours so you can put a sensible stop after 2 hours 10 mins I'd imagine. I wonder if you need to say "this recording uses the flag" yes/no as the problem is if you wait for a flag it might never come and you miss the recording that you could have started manually. One other thing I was thinking... I wonder if you can start the recording as per the timer i.e. 10 mins before or something and then monitor the signal - if you then get a "start" signal throw away what you've recorded so far and start now.

I've got quad turners so will usually have a spare but don't know what this would be like on a single tuner system - what do you think?

I guess one other question what are the chances that a program starts early - do we need to consider that? Probably not in the UK but no idea in the rest of the world.

Other thought - is there any kind of "programme interception" i.e. we stop this for news but the program starts again after the bulletin? Probably too rare to worry about and also if it's important enough to stop the program we probably don't care about our recording anymore!

Also do we still have films that start before the news and finish after? If so wonder how they would appear in the guide...

Hello !

First sorry for my bad english, normaly I speak french

This feature would be very usefull and cool (I'm in Switzerland and as I know, the PDC is also given in our TV streams )

I'm actualy testing (from last week) tvheadend on my Synology DS213j with a DVB-C TBS-5860CI card; At this time, I'm very impressed about the simplicity and the stability of tvheadend !

I would say also that I haven't any experience in DVB descpritors... but perhaps I could have good idea ?!?

what are the chances that a program starts early ...

I personnaly never seen that on TV (and I never lost the begin of a programm with a pre-time of 1 min).... if you could check the next event from 15min before the EPG start time, I think it would be enough...

For the stop, if I understand right the etsi, in the EIT (with event_ID, event_duration, and running_status, and more) the descriptor 0x4E will provide you the actual stream ID. Until this ID is the one we want to record, don't stop the recorder...
.... or perhaps an other way: until the actual ID has a running_status 4, don't stop recording !!!
To save a possible "bug" with this system and in the case of no more EIT datas are readable after the start of the record, you could perhaps have a rule like: max record duration would be program EPG duration + 1 hour -> then, stop the record.

The only "conflict" I see you could have with this, is in case of two schedules records on different multiplex (with one DVB card); if the start of the first one is delayed and its end is delayed after the start of the second one.... in this case, a priority must be set !

In case of programm interception, I don't think providers send an other ID for this interception... The logical running_status of ID we want to record would only change to 3 (pausing) ! Just wait the running_status come back to 4 to resume the record.

But if they send a different id for the interception programm, my idea would be to compare the recorded lenght with EPG theorical lenght.... If the recorded lenght is less than 90% of theorical EPG lenght, the recorder will continue to read the EIT in case the recorded programm ID comes back with running_status of 4 (because when the programm come back, the event ID would be logicaly the same to be like the "first part" and EPG programm ID). But an other rule could be: when the time comes to another start of scheduled record, abort the last program "survey".

I hope my english is "understandable" and ideas with my very poor experience would be usefull

Best regards !
JD.

Hey Colin,

Do you have your patch that you developed handy? I've now downloaded the code but as a Java developer by trade any help deciphering C will be much appreciated!

Is there any update on this at all and whether it's possible? It would certainly be a very useful feature if added, especially in the UK (and I think Germany and Austria as well as Switzerland amongst other countries).

I've seen it in practice on a YouView box and that always seems to get the start of the programmes perfectly.

Very old thread but i found no answer till now. Seems its not possible to get recordings managed by epg running status? On my Windows machine i'm using dvbviewer service, which is very good and it uses running status to start and stop recordings exactly when programme realy starts and stops, never have to set some minutes before or after. Its nearly the only reason to have additional windows machine for recording

This feature would definitely make a difference.

I can confirm as I also get Swiss TV via satellite that they use the feature in the same way as the UK terrestrial stations do, and that support for it would be really useful as Swiss TV seems to run quite late sometimes and not according to the EPG.

This would be a mixed bag in my opinion... I remember when I tried PDC (the equivalent of Accurate Recording/AR in the pre-DVB-T days) and it was all over the place. ITV still apparently has problems broadcasting the correct AR signal, although the BBC is supposed to be pretty good. And then you have the capacity for broadcasters to send a nonsense programme identifier as a form of primitive copy-protection - apparently, some of the music channels do this. So be aware that it's not all perfect, even if the concept appeals.

I recall this coming up before somewhere, to which he conclusion was 'if you're using EIT and the EPG updates correctly then your recording should also update'. Not ideal, I know, and I personally rely on quite large pre/post-recording buffers /just to make sure/...

I see a new version of TVHeadend has been released so I've raised a new feature request in the hope that this can be added to TVHeadend.

https://tvheadend.org/issues/3228

At the moment without this my TVHeadend install is just left unused.