Hi


You might well be right however there is enough memory free in the Humax to include games (which I suspect very few people use), so things were never that tight and there is probably plenty of slack. Also if the Humax uses good programming methods it should be able to implement autopadding code that is already there and not require much if any extra.

Thanks for the web link, interesting.

Regards

Phil

I sincerely hope not!

As son_t has stated there are problems with their software.

Suggest you read through:

Daewoo Thread


Wharfdale Thread

Not unnecessary - system is broken and needs fixing (one way or another)


You're making the assumption that adding functionality will cause more problems than it resolves. I guess this depends on the coding methods used to implement AR and how they overlap with the auto-padding code (if, indeed, they do overlap - they may be completely separate modules - I suspect they are since we're given the choice of using all or nothing when it comes to AR / autopadding). Either way unless you've seen the programme code I don't think you can make this assumption.


Why - will you be answering my call?

Can you still have the on-time setting without freeview playback being activated? I am on 1.06 and I gave up with padding, when it kept causing following programmes to be recorded, even when they were on the same channel!

I do. But I stopped programming of any sort some time ago so I will leave the implementation of this to younger and fresher minds as mine was burnt out by coding *much* harder problems than this one. Trying to keep track of the interactions between multiple instances of multiple processes in a mix of assembler and low-level languages in ones head takes its toll.

If you have no padding with 1.00.20 then you will be using accurate recording. Some of the previous bugs with padding should also be fixed by the final OTA version of the software due in mid January.

Before there was accurate recording functionality Humax deemed fit to include auto padding to make recordings more reliable.

When auto-tracking was introduced, it was totally optional as it didn't affect seemingly non-dependent functionality. And so many people (according to these forums) turned it off as they didn't find it as reliable.

When series link was introduced, a dilemma was introduced, less "accurate recording" or series recording. There is no obvious reason why they are linked (AFIR someone said earlier betas had it working together) whatsoever.

Whilst I didn't pay for a PVR with auto-padding or series record so I can't, and am not, complaining. Making you chose means I have to sacrifice reliability (admititly due to an overwhelming dependence on C4/BBC channels only on recording has missed the begging in about a week of use, but I can't remember this ever happening in over a year with 2 mins pre padding) in order to use the new very useful functionality.

Whilst I'm happy to get the functionality for free (why else would I download it from the Internet?) it is Humax's fault it isn't as good as it can be. Sure it isn't Humax's fault that accurate recording isn't as good as it can be, but it was Humax's decision to rely on it when only 3 broadcasters had made any commitment whatsoever to supporting it.

I had a quick look through those links but, other than problems with the series link, which could have been due to something other than the software, I couldn't see too much of a problem software-wise.

I was basing my comments on the PVR80 which I owned (which never faltered once, software-wise) but son_t and yourself obviously follow these things closer than I so thanks for putting me straight.

John.

No problem. Barry is the "PVR" man - having multitudes of PVR boxes and subsequently most them being Vestels in one form or another... and he doesn't think much of them...

The Digihome PVR is a very old and basic Vestel box... and it does what it does very well... But the same can not be said of the newer ones having the Freeview Playback features...

I don't have any off these boxes so can't realy say on a first hand basis... but as the PVR80 is only about £50 nowadays... I might get one and have a play with... apparently it uses a Linux FS so can be read on a Linux box (I think you need a kernel that supports the huge blocksize it uses) so I might try my cable mod on it

Other than fitting a fan and taking some pics for my website I didn't dig much deeper. The HD is a standard IDE interface so I see no reason why your mod wouldn't work.

Mine's out on permanent loan now - the Humax wins hands down on picture quality and lack of lock-ups (both of which I think are hardware-related in the Digihome).

John.

Its the meta data ... concentrate ... IT IS THE META DATA.

Situation is unchanged you can choose between auto-padding and FP2.

You are right! but to fix the meta data will take buy-in from all broadcasters, whereas to provide padding with AR <sigh/> will take buy in from just one company - Humax

... and at least 6-12 months work ... by which time the meta data will be much improved.

From what I've gleaned so far in this thread, there's no way for the Humax box to know whether or not the data it uses for AR is reliable since it simply uses the N&N data. So it's always going to be up to the user to decide which channels they can "trust" and which they can't.

So, when marking programmes for recording from the EPG, I'd use 'OK' as it's used now - to store fixed times (with AP, if set) - and I'd use the (intuitive) Record button to schedule using the N&N data (ie, hopefully AR). I can't really see how that would take 6 - 12 months work. I would have thought that actually getting AR to work (which they've already done) was the hard part. The software would only need to store which button set the timer to work out which method to use.

Humax have the choice of following the FP2 spec blindly and hoping other manufacturers do the same or they can try to keep ahead of the competition by adding a bit of useful extra functionality. I don't know if Humax regard the 9200T as a "current" product but, as the same software is used in boxes that are currently being produced, it's not as if they're wasting their time developing code for an obsolete product.

John.

So which broadcasters have said they are "adding" accurate recording data? I wouldn't be surprised if C4/ITV got it working better, but what the otehr broadcasters are doing is perfectly correct, most channels have made no commitments to change their data and make it more accurate than it has been for the last 9 years. As such what grounds do you have for your optimism?

Humax is assuming a greater degree of accuracy of 3rd party data than most channels claim it has, than it has in any of the 9 years it's been arround, and that it is required to do. That's just plain stupid.

You use the term "metadata" as though there is special metadata to do this, which is just misleading. The broadcasters arn't broadcasting inaccurate "accurate record" data, they are broadcasting (as they have done for the past 9 years) fairly accurate listings for the programme scheduled for the current time, and the programme afterwards. It just so happens some channels now broadcast the programme that is actually airing, and the one after that instead, and so some PVRs assume all channels now do this. And there is no meta-meta-data to show wether the meta-data is "accurate" or not.

Plus is the 6-12 months figure just made up (didn't autopadding take less than 6 months from lauch to impliment in the first place?), or do you have any reason to think it will take that long?

If for instance you can detail why autopadding and series record etc.. are so hard to get working together I'm sure it would help us all appricate the issue. At the moment it seems, autopadding is applied as it's needed, not on scheduling, by getting the PVR to wake up x mins early if nessiary, and if possible record x mins early, if not then on time. Then at the end to carry on recording up to y mins late, but stopping when anything else is set to start recording. With series record the Humax obviously stores when the next instance is set to start, end (as this appears in the schedule before the guide is filled). As such how is it a different situation?

There is new functionality in the playout systems that gets passed to the central collator the infrastructure of which was modified recently.

If its not meta data what is it!!!!

A lot more than a bit of of extra functionality.

FP2 removes a lot of the issues many on this forum raised against how auto-padding was implemented.

The real issue must be addressed the META DATA.

Hi


Please quote your sources that told you the meta data will be improved?

As for adding auto padding, you seem to forget the functionality is already programmed into the Humax, no way would it take 6-12 months of developer work, you could reprogram the whole thing in that time.


Nope, as user's seem to reporting the same issues with accurate recording as there were with auto-padding, the accurate recording triggers are ignored on consequtive recordings.


No that is not the "real issue".

The real issue is the majority of channels will not be doing anything to improve the "META DATA" as they never said they would, so there is nothing to address as that is how it was always going to be. Have the BBC and ITV who are experimenting with making Now and Next accurate given any firm commitment to time scales or a service level agreement? If the answer is No or you don't know then your '6-12 months' time span of the META DATA being improved is something you have just made up

Why are you so against improvements to the Humax box? Do you work for Topfield?


Regards

Phil

Thats not actually true.
Ive already posted where my consecutive programmes have recorded fine.
Programme times were 19:30-20:00 on ITV and 20:00-20:30 on BBC1.

Hi


The thing is in that scenerio two tuners are forced as Eastenders starts before the other recording had finished, and is the same as we do on padding by edging the start time of the consecutive recording a minute or so earlier to force two tuners.

It happened to me in testing where accurate recording appeared to be ignored on consecutive recordings, but of course that could just have been accurate recording being wrong, hard to know without seeing the raw data. What with the accurate recording failures and a bug when using chase playback in some scenarios meaning the recording doesn't start, then the realisation as to why I should be doing Humax's testing I have gone back to padding, at least its behaviour is better understood by me Not lost the end or start of a program now back to padding

Hopefully the next version will be better behaved, a shame we can't say the same about the META DATA, as it's all about the META DATA

Regards

Phil

Yeah, but if you just used auto padding without changing the times the ITV recording would have dropped those extra 2 mins and started to record BBC1 at 20:00 missing 1 min from the beggining.
The point I was trying to make was that without editing the start end times and just using Auto Tracking nothing got dropped which would of happened just using Auto padding unedited.
Even on consecutive recordings on the same channel im gettting all the correct programs in the correct recording slots which did not happen with padding.
ie. Tuesdays Eastenders then Holby City, on padding I used to have to see the end of eastenders at the beggining of the holby recording, but since using auto traking on .v20 this has no longer been the case.

You've discovered my secret...

No because what you want is stupid... and degrades the concepts behind FP.

The issue is the META DATA.

Its improving all the time... as reported by others C4 recently had a major revamp.

18 months since the last OTA and that's only projected ... until it appears on DTG site.