On the fly monitoring of AR flag.

If it says that the recording is not padded then it means that the first now/next table for that MUX found in the file says that the programme is already running (i.e. the first bookmark would be placed at the start)..
 
There may be still a flag to look for at the end - that there isn't one at the start is no guarantee it is an AR recording.
 
I have run it on a padded recording from one box and the book marks are identical (well maybe a fraction of a second out) to the start / finish of the same CITV recording from another box using Accurate recording.

Working well for BBC recordings.

It takes 1 second for every 10 minutes recording. However for one 30 minute recording the process took 70 seconds.
 
Border said:
I have run it on a padded recording from one box and the book marks are identical (well maybe a fraction of a second out) to the start / finish of the same CITV recording from another box using Accurate recording.
Click to expand...
Excellent news, thanks for testing to that level!

It takes 1 second for every 10 minutes recording. However for one 30 minute recording the process took 70 seconds.
Click to expand...
Did it detect the start point very quickly but take some time to find the end?
Could you run it with debug level 1 against that recording if you still have it?
(stripts -_ -d -X recording) - the -_ allows it to run against a recording which already has bookmarks.
 
af123 said:
Did it detect the start point very quickly but take some time to find the end?
Could you run it with debug level 1 against that recording if you still have it?
(stripts -_ -d -X recording) - the -_ allows it to run against a recording which already has bookmarks.
Click to expand...

It didnt find an end on the ordinary stripts -X command. that might have been due a quality issue in the recording. The recording didnt over run either.
I have emailed you the debug level 1 readings but this is what the ordinary stripts -X line got :

Found start of programme at packet 315065 (pos 60492480/39b0ac0)
Start: 59s, End: 0s
Processed in: 83.32s
Click to expand...
 
Border said:
It didnt find an end on the ordinary stripts -X command. that might have been due a quality issue in the recording. The recording didnt over run either.
I have emailed you the debug level 1 readings but this is what the ordinary stripts -X line got :
Click to expand...
Thanks - could you try version 1.2.1?
 
af123 said:
Thanks - could you try version 1.2.1?
Click to expand...
now it finds start and finish in the Hidef file. (This is a 30 minute recording)

Found start of programme at packet 315065 (pos 60492480/39b0ac0)
Found end of programme at packet 4972548 (pos 954729216/38e80300)
Start: 59s, End: 1201s
Processed in: 58.65s
Click to expand...
 
I've uploaded a new package called arbookmarks. It plugs into the automatic decryption mechanism in the web interface such that this new AR bookmarking process is triggered for each recording that is successfully decrypted. I would imagine that this is the most useful way to hook it in for most people given the decrypted file requirement.

I've provided a catch-up diagnostic, also called arbookmarks, which will scan your existing recordings and set bookmarks where possible (any decrypted, non-shrunk, padding recordings which do not have any bookmarks).

I'll post a new thread for this package in a few days if all looks good.
 
I'll put it on my padding machine (HDR3) and see what gives. Does it skip a contiguous recording or set bookmarks anyway?
 
I don't suppose it matters, but the diagnostic has tried to process the recycle bin (as well as [] folders)!

I don't like the "not padded, cannot process" bit.
 
Black Hole said:
I don't like the "not padded, cannot process" bit.
Click to expand...

Do you mean the wording or the fact that it doesn't try and find an end point if the start point isn't offset? I didn't see the point in setting just an end point and I do want it to just skip native AR recordings.


Posted on the move; please excuse any brevity.
 
If bookmarks were set regardless, it would then be possible to auto-crop padding recordings to the AR points.
 
Saw the new package listed on twitter, sounds interesting :)

Would it ever be possible to autodetect advert breaks and bookmark them as well ? I do use nice splice etc and manual bookmarks to skip them :)

Regards

Damian
 
The arbookmarks package sounds great and I will be installing it shortly.
The only other thing I thought would improve padding was to use AR between two consecutive programmes on the same channel.

Instead of;
Padding Start - Scheduled End (Prog 1)
Scheduled Start - Padding End (Prog 2)

You would get;
Padding Start - AR Switch (Prog 1)
AR Switch - Padding End (Prog 2)

Is that even possible? Or is padding/AR set at recording level rather than start/stop level?
 
It's set at the recording level.

I have thought of an interesting twist though: consecutive recordings go to separate files but (with padding) the change-over points are not usually ideal. By combining them into one file (post-recording) and then setting bookmarks based on AR, the file could be split again at the right places.
 
That is how a Topfield running Mystuff works putting consecutive recordings in one merged file. You can then use the Cutfile app to split it into separate files using the bookmarks as the dividing points.
 
You must log in or register to reply here.
Back
Top