Interesting occurence with AR

af123 said:
It's a shame we can't easily look back to see what the CRIDs were set to.
Click to expand...

I know this is not the customized forum but if you used the customized firmware and streamed a program from earlier that day to VLC, setting the verbosity of VLC debug to 2 and checking the message log would the event id (EDIT) or CRID of the 2 programs show up in the debug log.

(Edit) This is an example of the debug log from VLC (verbosity set to 2) from a program searlier that day (it only shows the CSI program after the 9 news) :

ts debug: - short event lang=eng '5 News Update' : 'International and national news update. '
ts debug: * event id=40870 start_time:1364932800 duration=3600 running=0 free_ca=0
ts debug: - tag=0x5f(95)
ts debug: - tag=0x54(84)
ts debug: - tag=0x50(80)
ts debug: - tag=0x50(80)
ts debug: - tag=0x50(80)
ts debug: - tag=0x50(80)
ts debug: - tag=0x76(118)
ts debug: - tag=0x76(118)
ts debug: - short event lang=eng 'New: CSI Crime Scene Investigation' : 'Pick and Roll: New. Crime drama starring Ted Danson. When a basketball coach is found bludgeoned to death in his locker room, DB's son Charlie and his new girlfriend are among the list of su... [AD,S]'
ts debug: * event id=40871 start_time:1364936400 duration=3300 running=0 free_ca=0
ts debug: - tag=0x5f(95)
ts debug: - tag=0x54(84)
ts debug: - tag=0x50(80)
ts debug: - tag=0x50(80)
ts debug: - tag=0x50(80)
ts debug: - tag=0x50(80)
ts debug: - tag=0x76(118)
ts debug: - tag=0x76(118)
ts debug: - short event lang=eng 'CSI: New York' : 'Clean Sweep: American crime drama. The team suspects that a badly burned corpse may have been a cage fighter, but later discovers that he may have faked his own death. [AD,S]'
ts debug: * event id=40872 start_time:1364939700 duration=3600 running=0 free_ca=0
Click to expand...
 
Border said:
I know this is not the customized forum but if you used the customized firmware and streamed a program from earlier that day to VLC, setting the verbosity of VLC debug to 2 and checking the message log would the event id show up. Something like
Click to expand...
:eek:
 
BH,

But in that case, trying to set the post-split segment to record would normally also schedule the pre-split segment, wouldn't it?
Click to expand...

No, I don't think so, given the C5 experience with Neighbours. Setting a recording on the current day for a programme precludes any previous programmes with the same CRID. My paragraph 5.

Martin
 
Border said:
I know this is not the customized forum but if you used the customized firmware and streamed a program from earlier that day to VLC, setting the verbosity of VLC debug to 2 and checking the message log would the event id (EDIT) or CRID of the 2 programs show up in the debug log.

(Edit) This is an example of the debug log from VLC (verbosity set to 2) from a program searlier that day (it only shows the CSI program after the 9 news) :
Click to expand...

Superb point - any recordings which have not been stripped will still have the EIT frames in them. I will have a look!
 
I've done some digging in the recordings from the day.

Here's an extract from the information in the HMT file:

Code: 
Format:SD
Title:Philpott Housefire: The Truth
Channel:5 (Channel 5)
Folder:/mnt/hd2/My Video/Test/
Filename:Philpott Housefire_ The Truth_20130402_2100
Genre:Unknown (128)
Service ID (SID):8500
Transport Stream ID (TSID):8217
Originating Network ID (ONID):9018
Programme Map Table PID (PMTPID):289
Video PID:2950
Audio PID:2851

Here's the CSI event as it originally appeared in the EPG (taken from an archived copy of the RS EPG database):

Code: 
  network_id: 12333
  service_id: 8500
    event_id: 40870
      start: 1364932800
        end: 1364936400
    duration: 3600
        name: New: CSI Crime Scene Investigation
        text: Pick and Roll: New. Crime drama starring Ted Danson. When a basketball coach is found bludgeoned to death in his locker room, DB's son Charlie and his new girlfriend are among the list of su... [AD,S]
    warning:
content_type: 15
    content: Undefined
  event_crid: /V64Z9
series_crid: /RBI7
    rec_crid:

and here's a packet from the live stream near the start of the Philpott programme:

Code: 
18 (Cont: 5) TEI/PUS/PRI: 0/1/0 S: None A: No, payload only
00000000: 1a 08 2f 35 33 36 35 32 33 37 76 0b c8 09 2f 34 ../5365237v.../4
00000010: 39 36 37 35 30 38 37 4b cb 1b 8a 4e f0 6c 21 34 9675087K...N.l!4
00000020: e3 00 01 20 19 23 3a 01 4e 9f a6 dc 40 20 00 00 ... .#:.N...@ ..
00000030: 01 00 00 80 51 5f 04 00 00 23 3a 54 02 80 00 50 ....Q_...#:T...P
00000040: 06 f1 03 01 75 6e 64 50 06 f2 03 02 65 6e 67 50 ....undP....engP
00000050: 06 f3 10 05 65 6e 67 76 08 c4 06 2f 56 36 46 30 ....engv.../V6F0
00000060: 43 4d 23 65 6e 67 1d 50 68 69 6c 70 6f 74 74 20 CM#eng.Philpott
00000070: 48 6f 75 73 65 66 69 72 65 3a 20 54 68 65 20 54 Housefire: The T
00000080: 72 75 74 68 01 2e b6 c1 61 88 51 f2 fa 20 bd cb ruth...

the event information section for this programme starts at byte 27:

4e - table ID (this TS, now/next information)
f0 6c - flags & section length
21 34 - service ID (= 5800 in decimal - Channel 5 on my device and matches the EPG extract)
e3 - bit 0 indicates "table valid now" and that is set
00 01 - section numbers
20 19 - TSID (8217 - matches value in final .hmt file)
23 3a - ONID (9018 - matches .hmt)
01 - last section in segment
4e - last table ID
9f a6 - Event ID (40870 - NOTE same event ID as original scheduled CSI episode)
dc 40 20 00 00 - start time, decodes as 8pm on the day (remember BST)
01 00 00 - duration (one hour)
80 - first 3 bits are the "running status" flag. This value indicates that the event is running now.

You can also see the CRIDs for the Philpott programme there - the event CRID is /V6F0C - not the same as the original CSI episode.



Now for the relocated CSI event:

Code: 
Format:SD
Title:New: CSI Crime Scene Investigation
Channel:5 (Channel 5)
Folder:/mnt/hd2/My Video/Test/
Filename:New_ CSI Crime Scene Investigation_20130402_2200
Genre:Drama (240)
EPG:Pick and Roll: New. Crime drama starring Ted Danson. When a basketball coach is found bludgeoned to death in his locker room, DB's son Charlie and his new girlfriend are among the list of su... [AD,S]
Service ID (SID):8500
Transport Stream ID (TSID):8217
Originating Network ID (ONID):9018
Programme Map Table PID (PMTPID):289
Video PID:2950
Audio PID:2851

Code: 
00000030: 63 61 6e 20 61 66 66 6f 72 64 2e d6 30 38 d3 4e  can afford..08.N
00000040: f1 49 21 34 e3 01 01 20 19 23 3a 01 4e a1 1e dc  .I!4... .#:.N...
00000050: 40 21 00 00 00 55 00 21 2e 5f 04 00 00 23 3a 54  @!...U.!._...#:T
00000060: 02 f0 00 50 06 f1 03 01 75 6e 64 50 06 f2 03 02  ...P....undP....
00000070: 65 6e 67 50 06 f2 40 06 65 6e 67 50 06 f3 10 05  engP..@.engP....
00000080: 65 6e 67 76 08 c4 06 2f 56 36 34 5a 39 76 07 c8  engv.../V64Z9v..
00000090: 05 2f 52 42 49 37 4d ef 65 6e 67 22 4e 65 77 3a  ./RBI7M.eng"New:
000000a0: 20 43 53 49 20 43 72 69 6d 65 20 53 63 65 6e 65  CSI Crime Scene
000000b0: 20 49 6e 76 65 73 74 69                          Investi

4e - table ID (this TS, now/next information)
f1 49 - flags & section length
21 34 - service ID (= 5800 in decimal - Channel 5 on my device and matches the EPG extract)
e3 - bit 0 indicates "table valid now" and that is set
00 01 - section numbers
20 19 - TSID (8217 - matches value in final .hmt file)
23 3a - ONID (9018 - matches .hmt)
01 - last section in segment
4e - last table ID
a1 1e - Event ID (41246)
dc 40 21 00 00 - start time, decodes as 9pm on the day (remember BST)
00 55 00 - duration (55 minutes)
21 - first 3 bits are the "running status" flag. The value here (0) is undefined.
 
So, I would conclude that the sequence of events is something like this:

Humax wakes from standby 15 minutes before the scheduled start time;
Humax sees the running status for event ID 40870 change to running so starts recording.
We know from experimentation that the Humax does not update its EPG while recording;
At the end of the recording, the Humax looks for the next episode in the series (using the series CRID) and finds the moved episode. It knows that it has not recorded that episode yet (by CRID)* so records it too.

*The Humax maintains a field in the schedule database called szRecordedProgCrid which contains a list of recently recorded event CRIDs. For the CSI event mine currently has:

WWW.FIVE.TV/V64Z9
WWW.FIVE.TV/V64Z8
WWW.FIVE.TV/V64Z7
WWW.FIVE.TV/V64Z6
WWW.FIVE.TV/V64Z4

Z9 was this episode that was displaced. This history goes back five episodes though and suggests that it would not record any duplicate showings of these.
 
Oh, and since the duration of CSI changed from one hour in the original EPG to 55 minutes, they must have cut some adverts too.
 
af123 said:
At the end of the recording, the Humax looks for the next episode in the series (using the series CRID) and finds the moved episode. It knows that it has not recorded that episode yet (by CRID)* so records it too.
Click to expand...

When the recording stops the schedule is updated with the S-CRID (i.e. CSI). (EDIT: Or is it the next event ID of that S-CRID that is updated ??). In this instance as the box was still running, the box detecting the running flag (CSI event ID) as on started recording the new scheduling of the series at 10 p.m.

When the PHTT program concluded (and it had its on S-CRID) why was it not put into its own series folder? Probably because when a scheduled recording starts it is placed a folder (based on the series CRID from the Humax schedule) for that series, or if it is a new series a new folder is created. In this case although the humax schedules' S-CRID (i.e.CSI) was different from the transmitted PHTT S-CRID it was not considered a new series so a new folder was not created for PHTT.

Also what triggers the scheduler to update? As this was a late change in the schedule even updating the EPG 15 minutes before the program started would probally have made no difference. that is probally why both programs had to be transmitted with the same event event ID.

However if a series schedule is changed with 1 or 2 days notice how does the Humax cope with those type of changes ?

Ezra Pound said:
The EPG is re-checked every day for 3 months and if no new series item is found during that time, the series schedule will be deleted
Click to expand...

This presumes (or is it assumes) that the box powers on or boots to allow the scheduler to check the EPG, or (as usually happens) a new program in a series is made, finishes and prompts a new entry in the schedule and a schedule update (of that series and at the same time all other series in the schedule).

Maybe it would be important to power on the box for 15 minutes every day to update schedules ?
 
We are able to modify the target folder in the recording schedule, so the folder must be determined at the time the schedule is set by the user.

Border said:
Maybe it would be important to power on the box for 15 minutes every day to update schedules ?
Click to expand...
This is a long-standing recommendation - see Things Every... section 4.
 
Border said:
When the recording stops the schedule is updated with the S-CRID (i.e. CSI). (EDIT: Or is it the next event ID of that S-CRID that is updated ??).
Click to expand...
You can look at the raw contents of the schedule table on your Humax by clicking the Raw Database View button at the bottom of the schedule page in the web interface. You'll see that each scheduled event has a single Event ID which is the next occurrence to record but also szEventToRecord which is a list of matching CRIDs in the next seven days and aulEventToRecordInfo which is a list of matching events in the next seven days as service ID, start time, end time, event ID (you can't read them directly as they're stored in raw form). These fields are updated at least following a boot, as long as it isn't a boot straight into a padded recording, but may also be updated at other times. I haven't experimented.

The PHTT programme didn't have an Series CRID at all, just an event CRID. Its event CRID doesn't appear in the list of recently recorded episodes. The decision as to which folder is used is made at the start of the recording when the files are created so it saw the next CSI event ID start showing and recorded it. At the end of the recording it must have realised that the series ID didn't match the CSI one so didn't add it to the list of recorded episodes. This may be more by accident than design.
 
If I understand all the above at some basic level then when there are two episodes of something on the same day (say ep. 5 & 6 and in that order), and you set the HDR up during that day to series record 5 it will grab 6 as well. But if you set it to series record 6 it won't take 5.
However, if, for example, 5 is tomorrow and 6 the day after that then setting a series record on either today will grab both.
And this is done by the HDR being clever rather than the broadcasters, yes?

If that is correct, and AF says the replacement programme has indeed ended up in the CSI folder, it sounds as though C5 have given the replacement programme the original 9pm CSI IDs and then incremented all the following CSI IDs by 1. (Whether that would have been deliberate or by accident (automatic software?) heaven knows of course.) That fits my differing recording result from AF's anyway.
 
af123 said:
At the end of the recording it must have realised that the series ID didn't match the CSI one so didn't add it to the list of recorded episodes. This may be more by accident than design.
Click to expand...

PPHT was not a series it makes sense it had no series CRID. But if it had and was different to the series CRID of CSI would the box not have ignored it ???

If a series CRID is changed mid series the schedule is not updated.
Erza said http://hummy.tv/forum/threads/rs-remote-scheduling-portal.563/page-42
Post 827

I can confirm that this fails because the Broadcaster has changed the Series CRID for some reason, every example of a failed series recording I have looked into has been because of this.
Click to expand...

So when the program finishes the Series CRID of the recording is irrelevant to the schedule.


Another thing I was wondering was if the event ID on duplicate shows or series reruns the same

Ezra Pound said:
I can confirm that, a few weeks back I recorded a series called 'Rory and Will - Champions Of World' but didn't remove the series recording request, the Humax is now re-recording the same repeated series, I'm not sure how it normally avoids recording duplicates, but there must be something that triggers the deletion of a 'duplicate log'
Click to expand...
 
Border said:
PPHT was not a series it makes sense it had no series CRID. But if it had and was different to the series CRID of CSI would the box not have ignored it ???
Click to expand...
No, because the box appears to use event IDs when recording and the replacement programme had the event ID that was originally assigned to CSI. It only uses the series CRID to find upcoming events to record.
 
af123 said:
I ended up with two separate one hour recordings.
Click to expand...
I did too, having exactly the same experience as you. In fact I also recorded CSI on 5+1 as a series recording, but for some reason I couldn't see it in the programme listing when I set things up at the weekend, so ended up with 2 copies plus the Philpott doco ...
 
MartinOnline said:
BH,



No, I don't think so, given the C5 experience with Neighbours. Setting a recording on the current day for a programme precludes any previous programmes with the same CRID. My paragraph 5.

Martin
Click to expand...

That is not what I have had happen, I have set up something as a series recording, picking it up somewhere in the middle of the week (doing the set up over the weekend) and it turned out the program was a series that played every day that week, and it started the recording on Monday. An easy thing to check out this trick is the BBC news, or something similar that happens every day.
 
antipodean said:
That is not what I have had happen, I have set up something as a series recording, picking it up somewhere in the middle of the week (doing the set up over the weekend) and it turned out the program was a series that played every day that week, and it started the recording on Monday. An easy thing to check out this trick is the BBC news, or something similar that happens every day.
Click to expand...

MartinOnline was referring reruns of Neighbours during the same day. This would be slightly different to reruns of programs during the week.

The Series CRID of Neighbours remains the same but the Program CRID changes every day. With the NEWS the Program CRID changes through the day.

When you set up a schedule the Humax puts the selected event ID into the schedule and may ignore all other event IDs with the same combination of Series CRID and Prog CRID. For each Series CRID/Prog CRID it will only schedule one event ID (i.e. it will ignore all reruns of Neighbours on that Day).

edit in the PHTT/CSI case it recorded both programs with identical event IDs but that was because each event ID had a different Series CRID / PROG CRID combination.

What links the 13.45 re-run of Neighbours on one day to the 13.45 rerun on the next ? Does it base this on the start time of the scheduled event?
 
I've been busy for the last few days so not had time to digest af123's analysis. It seems very sound.

antipodean said:
That is not what I have had happen, I have set up something as a series recording, picking it up somewhere in the middle of the week (doing the set up over the weekend) and it turned out the program was a series that played every day that week, and it started the recording on Monday. An easy thing to check out this trick is the BBC news, or something similar that happens every day.
Click to expand...

As Border has pointed out that post was about repeats during the day. My earlier post #17 pointed out what happens if you set up a series recording later in the week and that was in reference to, though not specified, the same channel.

However, I am getting some interesting results when I set scheduled recordings for the same C5 soap on both the C5 and C5+1 channels.

Martin
 
You must log in or register to reply here.
Back
Top