• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Incorrect recording details from RAYDON's web interface?

Merseypub

Merseypub

New Member
I'm running the excellent "Custom Firmware Version : 4.0.8" but I have hit a strange problem: I've got a recording where the Synopsis is showing correctly in the media screens on the telly, but wrongly in Browse Media Files on the web interface.

To provide more details, there were two episodes shown back to back of a series I have on series record, and on the web interface both recordings show the synopsis of the first one.

I'm fairly sure this has happened before, but it's always been an "Oh well, I probably imagined it" sort of situation. This time I've got the offending programme in front of me.

Any thoughts anyone?
 
When you make a recording on the HDR, synopsis information is stored in the .hmt sidecar file. Because of padding you may have a minute or so of the previous program, and at the end a bit of the following program. This means that possibly three synopses will be stored in the .hmt. (1) the preceding program (2) the recorded program (3) the following program. If you make a manual recording spanning several programs there will be a lot more. You can check this out by playing back the recording whilst displaying the iPlate information bar and watch the info change at the precise moment your actual recorded program starts. Not sure exaclty how adrianf36 implemented his hmt parser utility but I don't think it's smart enough to differentiate between them and probably just displays the first epg synopsis block it finds. Mabe af123 can provide more info since he wrote the original hmt parser for the HDR Fox-T2 on which Adrians version is based.
 
Yes, I've had a chance to reverse engineer some of the code now, and that is indeed the case, the hmt file has three synopses in it, the second one being correct, and as you say, the hmt command reports the first one.

The media browser on the box itself gets the right answer, so it must do something smarter, like find the info at the middle of the recording maybe.
 
Merseypub said:
Yes, I've had a chance to reverse engineer some of the code now, and that is indeed the case, the hmt file has three synopses in it, the second one being correct, and as you say, the hmt command reports the first one.

The media browser on the box itself gets the right answer, so it must do something smarter, like find the info at the middle of the recording maybe.
Click to expand...
No, it's even smarter than that, it matches the time of the scheduled recording to the time stamp contained in each EPG block within the .hmt file.
 
Hello. Slow response I know but been on holiday and just having a quick catch up.

Raydon has explained the issue very well. Currently the Foxsat HDR parser actually attempts to find the correct synopsis section of the HMT file by matching the programme name in the header block with the programme name in the EPG block. 99% of the time it gets this right. There has been one other poster before who had an example of an HMT file where it got it wrong.

Raydon - From memory the header block contains the recording start time (actual time of the recording start) and the EPG block contains the programme scheduled start time so these can't be used to find the correct EPG block. Or have I missed something? Was a while ago but I seem to remember the title strings being the only thing that matched between the header and the correct EPG block.

Adrian.
 
I was annoyed to discover I'd accidentally deleted my example, but it only took a moment to find another one. As you suggest, it only happens with two programmes with the same title, but as a fan of American Dad and Family Guy I'm hitting it pretty frequently on BBC3. Any chance of a look at hmt.c, and I'll see if I can work anything out.
 
If you've got an example to hand and you can upload it to somewhere (like 4shared) and send me a link that would be great.

Alternatively, if you fancy doing the investigatory work, copy the HMT file to a PC or Mac and use a hex editor to view the content. The file layout in Raydon's post #6 gives all the information you need to work your way through the HMT file. Basically, what is required is something that ties the header block to the correct EPG block in the file. As stated above, currently the HMT parser takes the program title from the header block (as a string) and attempts to match that to the program title in one of the EPG blocks. If it finds a match it uses the synopsis from the matching EPG block, if not it will use the synopsis from the first EPG block (I think - that last bit from memory and don't have the source available to me right now).
 
I've had a quick look at the hex and I reckon the best bet is to perform as at present unless there are multiple EPG blocks with matching programme title. In that case, select the EPG block who's scheduled start time is closest to the actual start time in the header.

This may fail if programmes are running off schedule which is why I suggest only doing this if the existing method finds more than one EPG block with the correct title.
 
adrianf36 said:
Raydon - From memory the header block contains the recording start time (actual time of the recording start) and the EPG block contains the programme scheduled start time so these can't be used to find the correct EPG block. Or have I missed something? Was a while ago but I seem to remember the title strings being the only thing that matched between the header and the correct EPG block.
Click to expand...
You are correct, there will probably be a small difference in the actual start time in the header block and the scheduled time in the epg block. However, you could parse each of the epg blocks and check if more than one epg block title string matched that in the header block. If a match was found then a futher comparison could be made between the actual start time and the scheduled times of the matching pair. Whichever was closest to the actual start time will in all likelyhood be the one you want.
 
Might have spotted something useful in the HMT. Need to request a favour as my Humax is a little broken at the moment and I don't have any current EPG data for the Web Interface :(

Looks like this programme was recorded in the early hours of this morning which means the data MIGHT still be in the WebIf epg database. Could you go into the EPG 7 Day view on the web interface and set the time back to this morning (or midnight) and see if the information is still displayed for the programme in question. If so, please can you go into the programme details pop-up and click the "show raw epg info" button and post the results. There might be a foolproof way to do this after all.
 
adrianf36 said:
Might have spotted something useful in the HMT. Need to request a favour as my Humax is a little broken at the moment and I don't have any current EPG data for the Web Interface :(

Looks like this programme was recorded in the early hours of this morning which means the data MIGHT still be in the WebIf epg database. Could you go into the EPG 7 Day view on the web interface and set the time back to this morning (or midnight) and see if the information is still displayed for the programme in question. If so, please can you go into the programme details pop-up and click the "show raw epg info" button and post the results. There might be a foolproof way to do this after all.
Click to expand...
Sorry Adrian, but according to my reckoning it was recorded in the early hours of 15th August
50 2A E8 B6 = 15/08/2012 00:09:26
 
Yes - sorry about that. Running a week behind .... probably wishing I was still on holiday!!

No worries .... will sort my EPG problems and then take a look. Thanks anyway.
 
Had a look at a recent hmt and it appears that the hmt epg/guide block format has changed slightly since I did that first analysis back in 2009. However, I noted that event id is written to the header block at offset 0x036B. It is also written to the corresponding EPG block in the 4 bytes preceding the scheduled start time epoch number. So that's how the HDR does it. Going to have a detailed look to determine exactly how the hmt has changed as the epg/guide block parser built into AV2HDR's hmt editor is broken it would seem.
 
You must log in or register to reply here.
Back
Top