Many recordings have wrong synopsis

MofTot

Member
I'm experiencing that many recordings have the wrong synopsis. I can't see a clear pattern but often the synopsis will be the synopsis of the program that is broadcast on the channel when the recording starts - I use 5 min padding before and after.

It appears that the synopsis is correct when I check the WebIf page for scheduled events.

Could this be because Newk and/or convertfiles don't take padding into account and overwrite the synopsis in the .hmt file?
 
The auto-padding is the problem. The synopsis will be correct if you play the recording beyond the point where the programme flag changes (when Accurate Recording would have started recording) and then press the info button. The WebIF (and the Standard User Interface) are just picking up the synopsis data from the start of the recording - how are they supposed to know that's not the programme that was targetted?
 
Thanks but why wouldn't it be consistently incorrect then, assuming that all my recordings start 5 min early?

I'm only using the box for recording, not for viewing, so fast forwarding 5 min wouldn't help me. I view recorded content over DLNA on my Humax HDR-FOX T2. I need the synopsis to be correct because I've written a program that renames the file name to include episode info if this can be found in the synopsis. This makes it easy to pick the correct file on the HDR-FOX T2 DLNA client.

As far as I can see there's no option for the hmt command to set the synopsis, only the file name and title, am I correct?
 
Thanks but why wouldn't it be consistently incorrect then, assuming that all my recordings start 5 min early?

I'm only using the box for recording, not for viewing, so fast forwarding 5 min wouldn't help me. I view recorded content over DLNA on my Humax HDR-FOX T2. I need the synopsis to be correct because I've written a program that renames the file name to include episode info if this can be found in the synopsis. This makes it easy to pick the correct file on the HDR-FOX T2 DLNA client.

As far as I can see there's no option for the hmt command to set the synopsis, only the file name and title, am I correct?


Presumably because the broadcaster had changed the current programme running status at the time the recording started. If I remember correctly every time the running status changes during a recording a new section is added to the .hmt. Download a affected .hmt and open it in a hex editor, look at the ascii table, you should be able to see the multiple synopses, if I did remember correctly :).

That's the only way that you could see different details during replay of a recording.

Format of file


https://myhumax.org/wiki/index.php/Humax_PVR_File_Formats
 
Thanks, I have an example .hmt file that only has one synopsis and it's incorrect. What do you mean by "running status"?

However, I've used the hmt command to change the title of that .hmt file, not sure whether that would remove additional synopsises(?) and only keep what hmt believes is the correct one?
 
Code:
00000000  00 00 00 01 02 00 04 00  00 00 00 00 00 00 04 00  |................|
00000010  00 00 66 00 00 00 00 00  00 56 46 4e 24 56 46 5e  |..f......VFN$VF^|
00000020  81 2f 6d 6e 74 2f 68 64  33 2f 56 69 64 65 6f 2f  |./mnt/hd3/Video/|
00000030  47 72 65 61 74 20 43 6f  6e 74 69 6e 65 6e 74 61  |Great Continenta|
00000040  6c 20 52 61 69 6c 77 61  79 20 4a 6f 75 72 6e 65  |l Railway Journe|
00000050  79 73 2f 47 72 65 61 74  20 43 6f 6e 74 69 6e 65  |ys/Great Contine|
00000060  6e 74 61 6c 20 52 61 69  6c 77 61 79 20 4a 6f 75  |ntal Railway Jou|
00000070  72 6e 65 79 73 20 73 30  34 65 30 34 74 30 36 5f  |rneys s04e04t06_|
00000080  32 30 31 35 31 31 31 33  5f 32 30 35 35 00 00 00  |20151113_2055...|
00000090  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000220  00 15 47 72 65 61 74 20  43 6f 6e 74 69 6e 65 6e  |..Great Continen|
00000230  74 61 6c 20 52 61 69 6c  77 61 79 20 4a 6f 75 72  |tal Railway Jour|
00000240  6e 65 79 73 20 28 30 34  7c 30 34 3a 30 36 29 3a  |neys (04|04:06):|
00000250  20 41 74 68 65 6e 73 20  74 6f 20 54 68 65 73 73  | Athens to Thess|
00000260  61 6c 6f 6e 69 6b 69 00  00 00 00 00 00 00 00 00  |aloniki.........|
00000270  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000320  00 42 42 43 20 54 77 6f  20 48 44 00 00 00 00 00  |.BBC Two HD.....|
00000330  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000340  00 00 00 10 69 37 42 42  43 32 20 48 44 00 00 00  |....i7BBC2 HD...|
00000350  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000360  00 00 00 00 00 05 50 00  80 20 00 ca 91 00 00 00  |......P.. ......|
00000370  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000400  00 00 00 00 00 00 00 00  00 00 00 00 00 ff 16 20  |............... |
00000410  00 00 00 00 00 00 00 1b  1c 01 02 15 7c 15 7d 15  |............|.}.|
00000420  7c 15 7f 15 7f 08 02 00  02 00 00 00 00 01 00 00  ||...............|
00000430  00 02 13 d7 18 00 00 00  00 00 00 00 00 00 00 00  |................|
00000440  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000500  46 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |F...............|
00000510  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001000  00 00 00 01 ce 1a 00 00  56 46 48 48 00 00 07 08  |........VFHH....|
00001010  00 00 02 00 00 00 00 00  15 47 72 65 61 74 20 43  |.........Great C|
00001020  6f 6e 74 69 6e 65 6e 74  61 6c 20 52 61 69 6c 77  |ontinental Railw|
00001030  61 79 20 4a 6f 75 72 6e  65 79 73 20 28 30 34 7c  |ay Journeys (04||
00001040  30 34 3a 30 36 29 3a 20  41 74 68 65 6e 73 20 74  |04:06): Athens t|
00001050  6f 20 54 68 65 73 73 61  6c 6f 6e 69 6b 69 00 00  |o Thessaloniki..|
00001060  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001110  00 00 00 00 00 00 00 00  15 31 2f 36 2e 20 43 68  |.........1/6. Ch|
00001120  61 6e 67 69 6e 67 20 54  69 6d 65 73 3a 20 53 65  |anging Times: Se|
00001130  72 69 65 73 20 66 6f 6c  6c 6f 77 69 6e 67 20 74  |ries following t|
00001140  68 65 20 46 61 6c 6b 6c  61 6e 64 20 49 73 6c 61  |he Falkland Isla|
00001150  6e 64 73 27 20 63 6f 6d  6d 75 6e 69 74 79 2e 20  |nds' community. |
00001160  54 68 65 20 52 65 76 20  48 69 6e 65 73 20 70 72  |The Rev Hines pr|
00001170  65 70 61 72 65 73 20 66  6f 72 20 50 61 6c 6d 20  |epares for Palm |
00001180  53 75 6e 64 61 79 2c 20  77 68 69 6c 65 20 48 61  |Sunday, while Ha|
00001190  74 74 69 65 20 61 6e 64  20 4b 65 76 69 6e 20 63  |ttie and Kevin c|
000011a0  6f 6f 6b 20 75 70 20 61  20 66 65 61 73 74 20 66  |ook up a feast f|
000011b0  6f 72 20 74 68 65 69 72  20 65 6e 64 2d 6f 66 2d  |or their end-of-|
000011c0  73 65 61 73 6f 6e 20 70  61 72 74 79 2e 20 5b 48  |season party. [H|
000011d0  44 5d 20 5b 41 44 2c 53  5d 00 00 00 00 00 00 00  |D] [AD,S].......|
000011e0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00001210  00 00 00 00 00 00 00 00  00 01 00 00 05 00 00 00  |................|
00001220  00 00 00 00 00 00 00 b8  00 00 00 b8 00 00 00 04  |................|
00001230  05 0b 0b 00 75 6e 64 00  00 00 00 00 00 00 00 00  |....und.........|
00001240  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001250  00 00 00 00 00 00 00 00  01 2d 28 10 04 42 08 00  |.........-(..B..|
00001260  65 6e 67 00 00 00 00 00  00 00 00 00 00 00 00 00  |eng.............|
00001270  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001280  00 00 00 00 01 2d 28 3c  02 40 07 00 65 6e 67 00  |.....-(<.@..eng.|
00001290  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000012b0  01 2d 28 68 03 14 05 00  65 6e 67 00 00 00 00 00  |.-(h....eng.....|
000012c0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
000012e0

Only one synopsis:

1/6. Changing Times: Series following the Falkland Islands' community. The Rev Hines prepares for Palm Sunday, while Hattie and Kevin cook up a feast for their end-of-season party. [HD] [AD,S]

should have been:

Michael Portillo embarks on a Greek odyssey from the Athens port of Piraeus, north to the city of Thessaloniki, exploring the Acropolis and sampling moussaka and baklava on the way. He also discovers the parlous state of Greek finances at the time of his 1913 Continental Railway Guide, and learns how an aristocratic English poet became a Greek national hero.

I'm aware this synopsis doesn't contain episode info, just an example of where the synopsis is incorrect.
 
Thanks, I have an example .hmt file that only has one synopsis and it's incorrect. What do you mean by "running status"?

However, I've used the hmt command to change the title of that .hmt file, not sure whether that would remove additional synopsises(?) and only keep what hmt believes is the correct one?

The data that is displayed as being now when looking at now/next. The name of the programme displayed when you press info. Accurate recording starts when the now data changes to the name of the recording that is scheduled. I don't have any incorrectly named recordings to check because I have auto set for starts and stops. Try viewing the channel and watching info when a recording is about to start, that should tell you when the now data is incorrect at the start. Don't mess with the .hmt, download at end and look at it. I am viewing info on BBC1 HD during Doctors, it should change to the next programme in about 8 minutes.

I have both Doctors and Follow Up set to record on HDR1000S. The second recording should start when the Foxsat-hdr displays The Coroner.
 
Last edited:
I have started a manual recording on BBC1 HD during The Coroner about 15 mins from the end extending into Escape To the Country. The files are called The Coroner, the .hmt has two synopses one for The Coroner and one for Escape To The Country.
 
Thanks for your help. What I've learnt from this is that there can be multiple synopsises within an .hmt file and I've also learnt about the file structure of the .hmt file.

I've recorded a program now with two synopsises and hmt -p shows the correct one (the second). As always, it's difficult to investigate inconsistent behavior.

I'll keep an eye on future recordings where the synopsis is incorrect. Also I'll make sure to keep a backup of the original .hmt file in case I change the title or file name, either through my own program or WebIf.
 
You are correct. The HMT file can contain multiple synopsises (sp?) if the recording has spanned multiple programmes.

It was a long time ago when I wrote the HMT parser for the Foxsat but from memory, in this situation, the synopsis shown by the Web Interface and picked out by the HMT utility (effectively the same thing) should always be correct for programmes that are part of a series record reservation. This is because there is an ID for the series recording that can be matched up to the correct synopsis in the HMT file. For manual recordings or regular, scheduled, timed recordings that are not "series linked" it's much more hit and miss. We never found anything that would give the correct synopsis where more than one exists in the HMT file. Likewise for Graham's example where a manual record is initiated that spans two programmes. How is anything supposed to "know" which synopsis the the "intended" one when someone pressed record.

Out of interest, what does the Foxsat itself show as the synopsis in the cases you have found where it is not displayed correctly via the Web Interface? Does it show the same one as the Web Interface or does the Foxsat show the correct Synopsis?

If you can provide a HMT file for a series linked recording where more than one synopsis section exists in the HMT and where the incorrect one is picked out by the HMT utility I'll take a look and see if I can spot the problem.
 
Thanks, I have an example .hmt file that only has one synopsis and it's incorrect.
Sorry - missed that bit when scanning through the previous posts.

If this is indeed the case then an incorrect synopsis has been put in the HMT file by the Humax Settop application and there's pretty much nothing that can be done about it I'm afraid. Quite unusual I would have thought though. Perhaps, as others have suggested, it gets "confused" by the padding. Personally I just rely on AR.

In your original post you said that "It appears that the synopsis is correct when I check the WebIf page for scheduled events". This is because it's coming from a different place ..... the EPG data rather than the HMT file.
 
Likewise for Graham's example where a manual record is initiated that spans two programmes. How is anything supposed to "know" which synopsis the the "intended" one when someone pressed record.

I wouldn't expect it to do any meaningful with manual recordings, only for single events and series recordings.

I'll keep an eye on upcoming recorded series linked episodes of "Great Continental Railway Journeys" on BBC2 HD. There might be EPG/recording issues with this because they're broadcast a few times within a few days, reusing the the same ECRID with different SCRIDs:

sqlite3 /opt/epg/epg.db "select eventid, starttime, substr(descr, 1, 40), ECRID, SCRID, RCRID from epg where serviceid=6940 and name='Great Continental Railway Journeys' order by starttime;"

53837|1447748100|4/6. Athens to Thessaloniki: Armed with |/241CI2|/V3FKVG|
52556|1448053200|5/6. The Black Forest to Hannover: Armed|/241CI3|/V1EAQX|
54643|1448134200|5/6. The Black Forest to Hannover: Armed|/241CI3|/V26EXA|
56527|1448352900|5/6. The Black Forest to Hannover: Armed|/241CI3|/V3FKVG|

All 3 airings of episode 5/6 use ECRID 241CI3.

WebIf's Scheduled Events page show the same date for Next Events for all 3, ie the first one, Fri 20 Nov 21:00 GMT.

On AR: Is the Foxsat-HDR good at keeping its system time accurate? I've been using the HDR FOX-T2 for 2.5 years and it's notoriously bad, runs 30s fast after just a few days.
 
I wouldn't expect it to do any meaningful with manual recordings, only for single events and series recordings.

I'll keep an eye on upcoming recorded series linked episodes of "Great Continental Railway Journeys" on BBC2 HD. There might be EPG/recording issues with this because they're broadcast a few times within a few days, reusing the the same ECRID with different SCRIDs:

sqlite3 /opt/epg/epg.db "select eventid, starttime, substr(descr, 1, 40), ECRID, SCRID, RCRID from epg where serviceid=6940 and name='Great Continental Railway Journeys' order by starttime;"

53837|1447748100|4/6. Athens to Thessaloniki: Armed with |/241CI2|/V3FKVG|
52556|1448053200|5/6. The Black Forest to Hannover: Armed|/241CI3|/V1EAQX|
54643|1448134200|5/6. The Black Forest to Hannover: Armed|/241CI3|/V26EXA|
56527|1448352900|5/6. The Black Forest to Hannover: Armed|/241CI3|/V3FKVG|

All 3 airings of episode 5/6 use ECRID 241CI3.

WebIf's Scheduled Events page show the same date for Next Events for all 3, ie the first one, Fri 20 Nov 21:00 GMT.

On AR: Is the Foxsat-HDR good at keeping its system time accurate? I've been using the HDR FOX-T2 for 2.5 years and it's notoriously bad, runs 30s fast after just a few days.

The foxsat wakes up overnight every night to carry out housekeeping so the clock has a max of 24hrs to cover. You can set a short overnight watch recording to resynch the clock on a HDR FOX T2. You need this anyway if using padding as the epg loses a day every day it's not booted. After 8 days there is no epg left.
 
On AR: Is the Foxsat-HDR good at keeping its system time accurate? I've been using the HDR FOX-T2 for 2.5 years and it's notoriously bad, runs 30s fast after just a few days.
What does the system time have to do with AR? For the HDR-FOX: recordings start and stop at the programme flags in the broadcast data, so they are independent of system time. I don't remember whether auto-padding recordings respond to broadcast time or system time (I did some experiments once, they are recorded on the forum somewhere).

In any case, the maximum time difference the HDR-FOX system clock can show compared with broadcast time is 60 seconds - once it reaches that the system clock is automatically resynced to the broadcast time. So auto-padding and manual timer recordings can only be at most a minute out, and you can build that into the padding allowances.

BTW: it's Programme CRID, not Episode CRID.
 
What does the system time have to do with AR? For the HDR-FOX: recordings start and stop at the programme flags in the broadcast data, so they are independent of system time. I don't remember whether auto-padding recordings respond to broadcast time or system time (I did some experiments once, they are recorded on the forum somewhere).

In any case, the maximum time difference the HDR-FOX system clock can show compared with broadcast time is 60 seconds - once it reaches that the system clock is automatically resynced to the broadcast time. So auto-padding and manual timer recordings can only be at most a minute out, and you can build that into the padding allowances.

BTW: it's Programme CRID, not Episode CRID.

If the box is in sby how can it respond to broadcast time ? How can the box resync if it only boots directly to recording from the schedule which only has access to the system clock for longer than 7 days ? If you set auto padding and only boot with the aerial out for a few days, replacing the aerial after returning to sby, the clock gets progressively out (you have to turn of power saving to see it), and the epg does not add any extra days.
 
It that a common use-case?

Of course it is, all you need to do is turn on auto padding and go on holiday for two weeks. If you have no other boot ups programmed like a watch reservation or power on/off timer, when you return the clock will be way out and will have stopped recording after 7 days. Not everyone has the CF installed.
 
I have a timed power on/off set every day 16:00-17:45 on BBC1 HD on my HDR-FOX T2 and I'm afraid it doesn't resynch the clock. The box has been running for 2 days at this point and the time is already 34s ahead. I couldn't get the ntpclient to work either. I'm running CF 3.03.

So I have to remember to manually switch off/on the power on the box every few days, that's the only way I've found I can get it to resynch the clock.
 
I have a timed power on/off set every day 16:00-17:45 on BBC1 HD on my HDR-FOX T2 and I'm afraid it doesn't resynch the clock. The box has been running for 2 days at this point and the time is already 34s ahead. I couldn't get the ntpclient to work either. I'm running CF 3.03.

So I have to remember to manually switch off/on the power on the box every few days, that's the only way I've found I can get it to resynch the clock.

There is something wrong with your box. It should correct the time near instantly when you boot it. Try a reset to factory defaults.
 
Back
Top