On the fly monitoring of AR flag.

Border

Border

Member
I use padding for my recordings but wouldnt it be good if the Humax bookmarked the start and finish of recordings from the transmitted time stamps? I am not inclined to use AR, and am not interested in remote scheduling at present.

I have read in other threads about how difficult it would be to do this 'on the fly' even with the excellent modified software. Has anything changed recently ?

It is a pity that transmitted programs dont have more unique information identifiers (something like the ISBN classification for books) that way you would be able to click on a recording and get its start finish time, epg, series information etc from a centralised server.
 
Nothing has changed. All the real-time processing is performed within the undocumented humaxtv process, including interaction with the hardware (no standard device drivers). The only exceptions so far have been interception of the remote control pathway, which I understand was hard-won, and the control path to the front panel display module. Neither of these are time-critical.
 
Border said:
I use padding for my recordings but wouldnt it be good if the Humax bookmarked the start and finish of recordings from the transmitted time stamps?
Click to expand...
This is a feature that has been available for a number of years on Topfield pvr's, and generally works very well. Anybody who has used MyStuff on a Toppy, has probably been using it.
 
The difference between MyStuff and our custom firmware being that Topfield actively supported MyStuff by providing a documented API.
 
Black Hole said:
The difference between MyStuff and our custom firmware being that Topfield actively supported MyStuff by providing a documented API.
Click to expand...
I wouldn't say that Topfield actively supported anything, they didn't even support their own buggy firmware. Fortunately, a number of Toppy enthusiasts managed to patch it up, and fix almost all of the bugs. The UK distributors even installed a version of patched firmware on the boxes, as the manufacturer would not fix the outstanding issues.
 
Alright then: passively supported MyStuff by providing a documented API.

Or maybe: divested themselves of the need to continue development of the firmware by providing a documented API so that enthusiasts would do it for free.
 
I don't know for sure but I think some of the neater features of MyStuff and the other add-ons such as Extend (which does the actual bookmarking that MyStuff makes use of) came from exploiting some *undocumented* hooks into the firmware with patches adding hooks of their own.

It will be a sad day when they eventually convert the last MUX to DVB-T2 as that will finally be the end of the greatest PVR on the planet.
 
Border said:
I use padding for my recordings but wouldnt it be good if the Humax bookmarked the start and finish of recordings from the transmitted time stamps? I am not inclined to use AR, and am not interested in remote scheduling at present.

I have read in other threads about how difficult it would be to do this 'on the fly' even with the excellent modified software. Has anything changed recently ?
Click to expand...

This is theoretically possible once recordings have been decrypted and not yet stripped. The broadcast now/next data is included in the recording file so it could be parsed to find the point at which the event becomes flagged as running and a bookmark added. As far as I know, nobody has invested time into looking at this though.
 
gomezz said:
I don't know for sure but I think some of the neater features of MyStuff and the other add-ons such as Extend (which does the actual bookmarking that MyStuff makes use of) came from exploiting some *undocumented* hooks into the firmware with patches adding hooks of their own.
Click to expand...
The Accurate BM [Ab] patch adds bookmarks to recordings according to the Accurate Recording signals (i.e. "Now & Next" programme transitions) on that channel.
 
brian said:
The Accurate BM [Ab] patch adds bookmarks to recordings according to the Accurate Recording signals (i.e. "Now & Next" programme transitions) on that channel.
Click to expand...


I wonder if the toppy patch got the now/next information from a recording buffer.

I have noticed when starting a recording on the humax and stopping it immediately that a message “Recordings under 30 seconds may not be saved”. I am assuming that this 30 seconds buffer allows the hardware time to unscramble the transmitted signal into something that can be then played/screened and also stored in the appropriate format.

You would think that the HDR when monitoring the transmitted signal (or recording buffers) it would log changes in the running status flags. Ok customised packages like redring can log the start and finish of a recording but if there was a log of the running status flags transmitted in the EIT then I’m sure it would be easy for Humax HDR developers to create a package like redring that would log when the running status flag updates and when the recording completes include it in the saved file. At least that way the whole recording would not have to be analysed to check when it’s running flag is activated/deactivated.
 
I think it needs 30 seconds or so of recording to fill the buffer to write the first disk cluster.
 
There are two things I have realised since the above post (#11).

First I referred to the 30 seconds ‘recording buffer’.
Border said:
I wonder if the toppy patch got the now/next information from a recording buffer.
Click to expand...
I shouldn’t have called it that as there is already a recording buffer on the Humax (which you can set to up to 120 minutes to record live TV or to record when you pause). Maybe I should have referred to a ‘descrambling buffer’. I was referring to the time lag that the box would need to receive the broadcast signal unscramble it and then organise it into a format suitable for storage.

Secondly I referred to the Humax developers creating a log of the AR flags and using other packages similar to insert those flags into the recorded file.
Border said:
if there was a log of the running status flags transmitted in the EIT then I’m sure it would be easy for Humax HDR developers to create a package like redring that would log when the running status flag updates
Click to expand...
If they had wanted to insert the bookmarks for padded recordings it would have been easy as even when using padded settings the Humax continues to monitor for AR flags (as is evident with multimode package which allows channel specific or program specific AR/Padding settings – e.g. record one program with padding while simultaneously recording another with Accurate Recording).

For a HIDEF recording I calculate that every 2 seconds the Humax deals with 1 MB of data. If using AR the Humax is searching it for 3 bytes for the AR flag and 2 more for the Program event ID. Does that not seem like looking for a needle in a haystack but yet the HDR turns on 15 minutes before a planned recording and searches 30MB per minute and finds those 5 bytes (well most of the time). To ask how it does that ….. that would be a question and a half.

Anyway an easier question what does BYT’s refer to? No don’t answer I have already googled it.
 
I don't think it is. In any case I think the running status flag is stored in a fixed place in the hundred bytes or so of header info at the start of each data block so not a lot of work to check it.
 
It isn't in a fixed place but the process only needs to look at TS packets with a specific PID (which can be checked from the first few bytes) and then only those belonging to the current Mux's now/next table. The tables are offset though and don't necessarily start on a packet boundary which complicates things.





Posted on the move; please excuse any brevity.
 
Bearing in mind the stream encryption only encrypts the payload packets and most if not all of the video handling is dealt with in the Broadcom chip, I still put my money on hardware (or at the least embedded code not part of humaxtv).
 
I found a couple of hours to look at this and now have a copy of stripts that can detect changes in the AR flag on a decrypted and unstripped recording.

Code: 
humax# ./stripts -X /mod/video/House\ Doctor_20130416_0349
Status change at packet 8416: Unknown -> Not running
Status change at packet 1397854: Not running -> Running
Status change at packet 4870550: Running -> Not running

The next challenge is to work out how far into the recording packet X is. I think reference to the .nts sidecar file will be required.
 
I have just uploaded a new version of stripts that can analyse a decrypted, non-stripped recording for AR flag transitions and add bookmarks at the start and end of the programme. I have done some limited testing and it seems to work well but would appreciate it if other people who routinely use padding could try it on a few recordings. If it looks good then I will work out how to add it to the web interface and automatic processing.

Code: 
humax# stripts -X Eggheads_20130416_1758
Found start of programme at packet 348813 (pos 66972096/3fde9c0)
Found end of programme at packet 4449061 (pos 854219712/32ea5bc0)
Start: 158s, End: 1969s
Processed in: 1.84s
 
Seems to work :)

I'm a bit confused about my regional news recordings, it claims they are not padded - which I can understand for Points West which is contiguous with News at Six, but not Wales Today.
 
You must log in or register to reply here.
Back
Top