AR on a per-recording or per-service basis

While I hate to wrangle with The Authority, are you sure? A recording has been nominated from the Guide with auto-padding as the default. The background process spots a new schedule and queues a "convert to AR" job for the next reboot. The next reboot is in fact the t-padding start-recording process previously queued by the Humax timers, so I don't reckon it will matter what the background process does at that point, the recording has already started and the Humax is not looking for AR flags.
 
Hi

Thanks for the information.

Unfortunately the first day of trying the custom firmware with BBC HD set to use AR, Call the Midwife failed to record with an 'unable to track' message and a thumbnail showing 0 minutes. Not sure if it was because the Humax was put into standby while it was recording on AR or a problem with the customised firmware or combination of both. Suffice to say the official firmware has gone back on and we are going to stick with padding as that hasn't failed us that we can recall.

Regards

Phil
 
While I hate to wrangle with The Authority, are you sure?
Fairly, but I initiated an experiment last night and will get the results later.
The first thing the box does after waking up is to work out why it has woken up.. and by the time it does that the schedule has already been changed.
 
My test was with Weatherview. It was scheduled to record with AR at 00:25 today but I queued a conversion to pad 60 seconds either side before I powered off the box for the night.

The recording was made with padding and the next episode is in the schedule for tonight with padding.

I'll try a test the other way around tonight.
 
Could the AR signal be logged?
Then recordings could be recorded with padding to be 'safe' with Bookmarks inserted where the AR toggles.
You could then trim the recording if you wished too. Perhaps some basic checking that the gap between bookmarks is roughly the programme length and if so, the recording is auto trimmed.

Maybe ;)
 
That's the sort of thing I hear can be done on the Topfield, where they made the operating system accessible to third-party developers through TAPs (Topfield Application Programming?). No such accessibility on the Humax, unless somebody reverse-engineers the existing code to find out how it interfaces with the hardware - which is something both difficult and time-consuming, but also a legal line-in-the-sand which the BYTs have not (not in public anyway) crossed.

Unfortunately (for the Topfield fans, and actually we would all have Topfields if they did), Topfield do not yet make a model that does HiDef, and I hear they have changed their minds about an open interface (possibly under pressure from the broadcasters and content providers) and will not do it again.

Reading the runes I think it is quite lucky that, although the Humax interface is "closed", it is as open as it is, and in future such machines will be clamped down not only for the man-in-the-street but also the hacking community - not to please the manufacturer (who is very happy to have an active squad of enthusiasts encouraging more sales and brand loyalty) but to please the content providers who have everything sewn up in licence agreements.
 
Agreed.

Perhaps AR will settle when the network wide change over is complete and the BBC and the like don't need to broadcast on the legacy T1 and just do full spec T2 ;)

Is London the last area? I'm due April 2012. Can't wait, as it means I'll finally get HD on my small local transmitter which currently duplicates every MUX from Crystal Palace excluding the HD ones...!!
 
Perhaps AR will settle when the network wide change over is complete and the BBC and the like don't need to broadcast on the legacy T1 and just do full spec T2 ;)

T1 isn't 'legacy', The BBC (and all other broadcasters) will continue to broadcast T1 because it equates to Standard Definition. T2 is High Definition only (currently 4 channels)
 
My test the other way round worked last night. The last time the box went to sleep it was expecting to record weatherview with padding but there was a pending change to AR that would be processed when it woke up. The padding was only a minute either side.

It woke up at 01:44 - a minute before the scheduled time but recorded from 01:48:30 to 01:53:10 at which point it powered off. The change to AR worked on boot so AR was used. It didn't have the usual 15 minutes to look for the AR signal because the padding was so small but it found it nonetheless. Four minutes out for a 5 minute programme in the middle of the night!

So, my statement stands. It will process the recording type change and then attempt to record it in the new mode. If changing from padding to AR and the original start padding was < 15 minutes, then the AR signal window is reduced accordingly for that one recording - it will be fine after that.
 
Fair enough, useful information.

I've had another quirk though, my probe ARs on C4 (Heston and Baker Boys) that failed last week were failing again this week. The box had been on standby (as it was last week), and the USBs were powered up when I looked at it but no rec symbol (which there should have been). I brought it out of standby and it immediately went into recording - I checked the media status and Heston was a failed recording and Baker Boys only had the duration from when I turned on to when it was due to finish.

My Weatherviews had failures on 20th and 23rd Jan (after midnight), since Christmas. I'm pretty sure the box is on most nights around Weatherview time - I generally have it available to stream from and usually it will be actively streaming around then so the fact that it usually succeeds suggests that isn't the problem, but I have caught it failing when iPlayer is running.

How to explain an AR recording that spontaneously starts when brought out of standby though? All very odd, and that not many others (or possibly nobody else) sees similar goings on... I'm beginning to suspect my HDR is iffy in some way. That experiment running the HD in tandem is getting tempting.
 
Now had three AR faulures, one months ago soon after purchase and two recent over the past two weeks - two episodes of 'the swatm' failed to record due to 'failed to track' issues. All other AR recordings have worked perfectly.
 
Probably BBC HD but I've deleted them now and cannot remember the details. It would have been mid-Jan onwards, during a period I was out of the country. On-line I cannot find any mention of recent repeats, but they were shown in the schedule as I set 'record entire series'. Strange, maybe it was a schedule mistake and they were not actually broadcast.
 
Hi

Maybe this is already planed!

Can the Padding mode be adapted to include individual setting for each padded channel.
e.g
BBC One (5,5)
ITV1 (1,1)
Fiver (2,2)

Hodgy
 
just to add

/var/lib/humaxtv/mm.db
channel table could have post and pre feilds
e.g.
---------------------------
| lcn | type | pre | post |
---------------------------
| 1 | pad | 300 | 300 |
| 3 | pad | 60 | 60 |
| 5 | pad | 120 | 120 |
---------------------------

then the settings table would not be needed
 
Not sure if this is the right place to throw this in. If you generally use "auto" padding but edit the start or stop time for a partuicular reservation (say, extending the end time to include two successive programmes in a single recording, or because you think the default padding will not be enough for that programme) then all the padding is lost and you need to be sure to manually pad both start and stop. This is not such a problem once you know how it works. However, when reviewing your schedule there is no way to tell whether a reservation has never been edited and so still has auto padding or if it has been edited and does not. If you set the start and stop times back to the EPG values the auto padding is not re-instated. Could the web interface schedule display include a flag to show whether auto padding is in effect for each reservation? And better still, a way re-instate the auto padding?
 
If you use the standard user interface to modify the start and/or end times, the schedule entry becomes a manual one and will no longer respond to EPG changes - it will start and stop at the specified times. You can tell on the schedule list (Guide >> Yellow) because, when highlighted, the information at the top of the screen does not include the clock symbol.

I don't know if it is possible to restore the EPG properties, the only idea I have is to use the WebIF to change it to AR and then back to padding again (needing a reboot each time). I would simply delete the reservation and instate a new one through the SUI.
 
Back
Top