If anyone is really having problems, a second Humax will solve most of them, plus it doubles the disk size, doubles the limit of scheduled recordings, gives you a spare remote and looks lovely stacked! The only problem is then getting only one of them to respond to the remote control - a whole new ballpark...
Recording two channels whilest watching a live TV or play-back * Viewing a third channel is limited to the Multiplexes you are currently recording.
That look pretty much to me like we should expect the recording to take priority over watching a third channel.
gtg
But we are not recording two channels, just one! Hence why using two tuners is a waste. The worse case scenario is that the end of one program (if it overruns) will be on the beginning of the next one.
The ideal solution is to stream the output from the one tuner to two files on disk at the overlapping point, this would be a fair bit of work and the hardware might not be able to handle it, say you are already recording another channel as well, that would be three streams it's handling.
There are only two realistic options i can see, dropping the padding or retaining the padding and using another tuner. I think they got it right, some people will prefer the other way.
Sorry Marc for being dense, but are you saying the code works the way it was intended and the release notes are wrong?
I am. The mistake is kind of highlighed even by the example given in the notes i.e. that consecutive recordings of different channels will still drop padding.
I was told at that stage that there was no real time to make it sophisticated as the release was supposed to be about sorting out the lockups problem once and for all with MHEG which was getting even later. Something that .04 failed to do competely, even though .04 at the time was a welcome relief from the BBC lockups issue.
I remember focus was pretty much tied into lockups problem, plus there were problems with the way the machine could corrupt the hard drive potentially leading to lost recordings that was also a major focus. In the end the release materialised with the lockups fix which was the intended purpose; there was also payoff for the work they did on lost recordings included in the release. Some engineers did do some extra things while other engineers concentrated on bugs like the name of recordings being that of the programme before when padding start time fixed, chase play, some autopadding, one or two small enhancements squeezed in.
But we are not recording two channels, just one! Hence why using two tuners is a waste. The worse case scenario is that the end of one program (if it overruns) will be on the beginning of the next one.
I'm not sure I can agree with this statement. We are recording 2 consecutive programs on 2 different muxes that as a result of autopadding will overlap by a few minutes.
If I set the recording manually, the Humax would use 2 tuners. Surely the result with autopadding should be exactly the same?
Anyway, thanks to marcdavis for clearing up the release notes issue.
I would however make one suggestion to marc, given his apparent connection with the Humax engineers.
Regardless of how Humax choose to make the software behave when autopadding is enabled, as the machine is being asked to do things it knows it cannot do, perhaps it should tell us when setting the reservation that there is a problem, giving the user the chance to prioritise their recordings for their desired results.
I'm not sure I can agree with this statement. We are recording 2 consecutive programs on 2 different muxes that as a result of autopadding will overlap by a few minutes.
Equally, when I set it to record Extras and Mitchell and Webb - with padding and it cut Extras short.
and yes the last few minutes of the Extras recording would have been the same as the first few minutes of the M & W recording
In this situation extras and mitchell and webb are both on BBC2, if we look at recs on two different muxes, i would expect the Humax to pad both if the box is off but not if it's on or another recording is also scheduled.
The logic of the padding could be improved but that is something that may come in the future.
My main argument was that using two tuners to record one channel is a complete waste!
I can see that the original post was about progs on different channels so i can see why you thought i was talking about that.
Do you know if it would behave differently if it was left in standby?
Going back to post #5, would the box behave differently if on standby? In my case I was recording corrie on ITV 1930-2000 then eastenders on BBC1 2000-2030 an autopadding was dropped losing the last few secoonds of corrie.
One tuner, 2 recordings - the same as recording BBC1 and BBC2 off the same mux - in this case both channels on the mux happen to be BBC2.
Yes granted it would be able to use one tuner but to record two streams could well be the limit the box can handle, after all it doesn't buffer when recording two things. So regardless of whether you used one tuner or two you still wouldn't be able to record or watch anything else.
Yes granted it would be able to use one tuner but to record two streams could well be the limit the box can handle, after all it doesn't buffer when recording two things. So regardless of whether you used one tuner or two you still wouldn't be able to record or watch anything else.
??? Don't know where you get this from.
The Humax 9200 can quite happily record two channels at the same time and either watch a third channel if its on one of the two muxes (not channels) in use or something from the previously recorded.
So in the case of recording consecutive programs on ITV and BBC - all of mux 1&2 would be available for viewing during the overlap.
The Humax 9200 can quite happily record two channels at the same time and either watch a third channel if its on one of the two muxes (not channels) in use or something from the previously recorded.
So in the case of recording consecutive programs on ITV and BBC - all of mux 1&2 would be available for viewing during the overlap.
I didn't say you couldn't watch another channel, i said you couldn't record or buffer another channel.
Actually i did say watch - my mistake, you would be able to (on certain muxs or all depending on your recs) but not record anything which started at the same time
eg
8-9
9-10
9-10
The point i'm making is that to enable the padding in all situations will restrict the functionality of the box, smart padding is the way to go.
The point i'm making is that to enable the padding in all situations will restrict the functionality of the box, smart padding is the way to go.
I do agree with you on this point.
I was reluctant to post on the autopadding issue as I know that autopadding cannot handle everything. I did however feel the the 2 channel concecutive recording behaviour was a little dissapointing, particularly as the release notes supported my view.
However it's all water under the bridge now, Marc has pointed out that the notes are wrong in this case, and also that work on autopadding is on going so we may well see some improvements in a future release.
I was reluctant to post on the autopadding issue as I know that autopadding cannot handle everything. I did however feel the the 2 channel concecutive recording behaviour was a little dissapointing, particularly as the release notes supported my view.
Yes i agree it can be improved, but i think it should be done in a smart way so that it doesn't stop you doing anything else.
Eg if the box is off and no other recording will clash
However you then have to think about what if the box is then turned on while the padding is going on.
Some people would no doubt like the box to stick exactly to what you have chosen in the options but i think the "smart" elements make the box more useful.
The problem Humax and other manufacturers have is they have to decide one way or the other!
Yes i agree it can be improved, but i think it should be done in a smart way so that it doesn't stop you doing anything else.
Eg if the box is off and no other recording will clash
However you then have to think about what if the box is then turned on while the padding is going on.
Simplicity has to be the key. If the machine behaves in different ways depending whether it is in standby or not, confusion sets it. Again, this is why many twin tuner models have dedicated tuners for recording and viewing/TSR.
Simplicity has to be the key. If the machine behaves in different ways depending whether it is in standby or not, confusion sets it. Again, this is why many twin tuner models have dedicated tuners for recording and viewing/TSR.
But simplicity then means inflexibility, a dedicated rec/watch tuner system would mean you cannot record two channels.
The key is to hide the complexity from the user. The user shouldn't even worry about the padding, if its available the box will do it. The program will still be there in the list as always and they can watch it.
I can see that if there is a program which always overruns then the user might expect it to pad when it doesn't. I think that padding should be seen as an - if available then do it - type feature. If you must have it record a particular time period then surely you should schedule it to record.
There is not much point arguing about it however, thats how i think it should work, if everyone thought the same, the world wouldn't be much fun!
The key is to hide the complexity from the user. The user shouldn't even worry about the padding
I agree, but I don't think Humax have achieved that so far. They way it is at the moment, every time I schedule a recording I have to worry about whether or not the box is going to autopad the way I want it to. The complexity has not been hidden if padding is important to the user, as it is to me.
From what Marc says, they rushed the implementation of autopadding last time round and IMO, based on what I read here, they got it wrong. I shall almost certainly be delaying purchase until I see some feedback on how well their next attempt works.
The 9200 has a good reputation for solid software but I get the feeling this is being eroded somewhat. It sounds like it took them two goes to get the MHEG fix right, and it looks like it's going to take at least that many tries to get autopadding right. I think Humax maybe need to re-focus on quality over features. (Mind you, I suspect this has been said of almost every other PVR manufacturer at some point in the last 12 months!)
Or they could implement both approaches, and give the user the option of changing the default behaviour chosen by the manufacturer.
I agree, but I don't think Humax have achieved that so far. They way it is at the moment, every time I schedule a recording I have to worry about whether or not the box is going to autopad the way I want it to. The complexity has not been hidden if padding is important to the user, as it is to me.
From what Marc says, they rushed the implementation of autopadding last time round and IMO, based on what I read here, they got it wrong. I shall almost certainly be delaying purchase until I see some feedback on how well their next attempt works.
The 9200 has a good reputation for solid software but I get the feeling this is being eroded somewhat. It sounds like it took them two goes to get the MHEG fix right, and it looks like it's going to take at least that many tries to get autopadding right. I think Humax maybe need to re-focus on quality over features. (Mind you, I suspect this has been said of almost every other PVR manufacturer at some point in the last 12 months!)
Yes I think it was a bit of a rush. I was one of the people who suggested it should be taken out but its intended implementation was not thought to be 'wrong', just 'an' implementation of autopadding which people an either make use of if it helps or just not use if it doesnt work for them. The fact that so many people use it probably means that they did actually do something worthwhile even though it wasnt put out with the levels of sophostication that would make it a total solution. If Humax go back over it and make it more than a basic implementation that would be great but they might not - in which case there are other PVRs with certain ways of dealing with autopadding to choose from. I dont have a problem with releasing a basic version of autopadding - I have a choice to make use of it or not - its the bug with consectutive recording that they need to take out for me before they talk about enhancing it. Something they will probably take out in the next version.
Even when we were testing Beta software there were problems which we told them about, but they still carried on and released it.
that beta was from March - the first one with autopadding. the problem highlighted were what they already knew and told us when they sent it to everyone. Those probems got resolved before release - or so they and we thought - until we noticed doing the same thing in reverse order still coused the problem doh.
From what Marc says, they rushed the implementation of autopadding last time round and IMO, based on what I read here, they got it wrong. I shall almost certainly be delaying purchase until I see some feedback on how well their next attempt works.
The 9200 has a good reputation for solid software but I get the feeling this is being eroded somewhat. It sounds like it took them two goes to get the MHEG fix right, and it looks like it's going to take at least that many tries to get autopadding right. I think Humax maybe need to re-focus on quality over features. (Mind you, I suspect this has been said of almost every other PVR manufacturer at some point in the last 12 months!)
The implementation of autopadding was not rushed as such, it was important to get the release out because of the fix for the MHEG problems. We had reservations about autopadding, having had a little time to test it, but it was thought that the fix for the MHEG outweighed any complaints that might arise.........however, seeing the amount of moaning on here lately, this might well have to be reconsidered in future...which may of course lead to delays in further releases.
The MHEG engine used on the 9200T is supplied by a 3rd party, so it is incorrect to state it took Humax two attempts to get it right. I can assure you Humax were just as frustrated as us users that it fell over a 2nd, and indeed 3rd time (BBC, ITV lockups, blanking problem associated with Sky text).
Edit:
Marc has posted whilst I was typing this, and stated his opinions on the release......so I may as well tell you I was for the release, with the added notes, however you will not find me posting info on any further beta releases, or discussions I have with Humax.
The implementation of autopadding was not rushed as such, it was important to get the release out because of the fix for the MHEG problems. We had reservations about autopadding, having had a little time to test it, but it was thought that the fix for the MHEG outweighed any complaints that might arise.........however, seeing the amount of moaning on here lately, this might well have to be reconsidered in future...which may of course lead to delays in further releases.
The MHEG engine used on the 9200T is supplied by a 3rd party, so it is incorrect to state it took Humax two attempts to get it right. I can assure you Humax were just as frustrated as us users that it fell over a 2nd, and indeed 3rd time (BBC, ITV lockups, blanking problem associated with Sky text).
To the point where it would be only fair that the MHEG provider was ditched by Humax for any future work. I remember it got to a stage where it was looking like Humax were going to have to boot out Eldons MHEG engine and stick in the one they had on the 8000t - which wasnt displaying any of the same problems.
The implementation of autopadding was not rushed as such, it was important to get the release out because of the fix for the MHEG problems. We had reservations about autopadding, having had a little time to test it, but it was thought that the fix for the MHEG outweighed any complaints that might arise.........however, seeing the amount of moaning on here lately, this might well have to be reconsidered in future...which may of course lead to delays in further releases.
Barry, my apologies if my posts were seen as "moaning". They were base purely on the Humax not behaving in neither an obvious manner (to me anyway) nor in the way described by the release notes.
I have to applaud Humax for their continued development of the software, and eagerly await the next release.
However after 30 years in the service industry I understand that Humax will not be able to resolve issues they are not aware of and felt the consecutive recording problem warranted discussion.
There are numerous other issues that affect useability that could be discussed, but I feel at this stage only matters affecting the ability of the box to do its job should be raised.
I for one would be more than interested to hear any news of future releases or fixes under development. If we know that the issue of the day is being addressed, then there is no point in wasting bandwidth on these matters.
So anyway, I tried the manual override on my Extras and Mitchell and Webb recordings by manually setting Extras to finish 1 minute later.
I checked this morning and Extraas recording ended after 19'54"
where it switched to the new recording - so applying the auto padding to the start of M&W.
I quess I'll just have to record the whole hour and split it.
I won't know until tonight to check if it gets the Corrie/ Eastenders overlap the way I want it. I have set corrie to end at 20:01.
Comments
If anyone is really having problems, a second Humax will solve most of them, plus it doubles the disk size, doubles the limit of scheduled recordings, gives you a spare remote and looks lovely stacked!
But we are not recording two channels, just one! Hence why using two tuners is a waste. The worse case scenario is that the end of one program (if it overruns) will be on the beginning of the next one.
The ideal solution is to stream the output from the one tuner to two files on disk at the overlapping point, this would be a fair bit of work and the hardware might not be able to handle it, say you are already recording another channel as well, that would be three streams it's handling.
There are only two realistic options i can see, dropping the padding or retaining the padding and using another tuner. I think they got it right, some people will prefer the other way.
I am. The mistake is kind of highlighed even by the example given in the notes i.e. that consecutive recordings of different channels will still drop padding.
When this was released the explanation of how autopadding worked as I and some others are still saying: see my post number 15 on 02-06-2006, 18:03 in: http://www.digitalspy.co.uk/forums/showthread.php?t=390047
Even just before the software was released it was pointed out that this was a basic implementation of autopadding see my post number 94 on 31-05-2006, 19:36 in http://www.digitalspy.co.uk/forums/showthread.php?t=377992
I was told at that stage that there was no real time to make it sophisticated as the release was supposed to be about sorting out the lockups problem once and for all with MHEG which was getting even later. Something that .04 failed to do competely, even though .04 at the time was a welcome relief from the BBC lockups issue.
I remember focus was pretty much tied into lockups problem, plus there were problems with the way the machine could corrupt the hard drive potentially leading to lost recordings that was also a major focus. In the end the release materialised with the lockups fix which was the intended purpose; there was also payoff for the work they did on lost recordings included in the release. Some engineers did do some extra things while other engineers concentrated on bugs like the name of recordings being that of the programme before when padding start time fixed, chase play, some autopadding, one or two small enhancements squeezed in.
I'm not sure I can agree with this statement. We are recording 2 consecutive programs on 2 different muxes that as a result of autopadding will overlap by a few minutes.
If I set the recording manually, the Humax would use 2 tuners. Surely the result with autopadding should be exactly the same?
Anyway, thanks to marcdavis for clearing up the release notes issue.
I would however make one suggestion to marc, given his apparent connection with the Humax engineers.
Regardless of how Humax choose to make the software behave when autopadding is enabled, as the machine is being asked to do things it knows it cannot do, perhaps it should tell us when setting the reservation that there is a problem, giving the user the chance to prioritise their recordings for their desired results.
Thanks
gtg
In this situation extras and mitchell and webb are both on BBC2, if we look at recs on two different muxes, i would expect the Humax to pad both if the box is off but not if it's on or another recording is also scheduled.
The logic of the padding could be improved but that is something that may come in the future.
My main argument was that using two tuners to record one channel is a complete waste!
I can see that the original post was about progs on different channels so i can see why you thought i was talking about that.
Going back to post #5, would the box behave differently if on standby? In my case I was recording corrie on ITV 1930-2000 then eastenders on BBC1 2000-2030 an autopadding was dropped losing the last few secoonds of corrie.
Yes granted it would be able to use one tuner but to record two streams could well be the limit the box can handle, after all it doesn't buffer when recording two things. So regardless of whether you used one tuner or two you still wouldn't be able to record or watch anything else.
??? Don't know where you get this from.
The Humax 9200 can quite happily record two channels at the same time and either watch a third channel if its on one of the two muxes (not channels) in use or something from the previously recorded.
So in the case of recording consecutive programs on ITV and BBC - all of mux 1&2 would be available for viewing during the overlap.
http://www.humaxdigital.com/uk/pdf/PVR-9200T_L.pdf
gtg
I didn't say you couldn't watch another channel, i said you couldn't record or buffer another channel.
Actually i did say watch - my mistake, you would be able to (on certain muxs or all depending on your recs) but not record anything which started at the same time
eg
8-9
9-10
9-10
The point i'm making is that to enable the padding in all situations will restrict the functionality of the box, smart padding is the way to go.
Yes you did.
Yes, i have edited the post above
I do agree with you on this point.
I was reluctant to post on the autopadding issue as I know that autopadding cannot handle everything. I did however feel the the 2 channel concecutive recording behaviour was a little dissapointing, particularly as the release notes supported my view.
However it's all water under the bridge now, Marc has pointed out that the notes are wrong in this case, and also that work on autopadding is on going so we may well see some improvements in a future release.
gtg
Yes i agree it can be improved, but i think it should be done in a smart way so that it doesn't stop you doing anything else.
Eg if the box is off and no other recording will clash
However you then have to think about what if the box is then turned on while the padding is going on.
Some people would no doubt like the box to stick exactly to what you have chosen in the options but i think the "smart" elements make the box more useful.
The problem Humax and other manufacturers have is they have to decide one way or the other!
Simplicity has to be the key. If the machine behaves in different ways depending whether it is in standby or not, confusion sets it. Again, this is why many twin tuner models have dedicated tuners for recording and viewing/TSR.
But simplicity then means inflexibility, a dedicated rec/watch tuner system would mean you cannot record two channels.
The key is to hide the complexity from the user. The user shouldn't even worry about the padding, if its available the box will do it. The program will still be there in the list as always and they can watch it.
I can see that if there is a program which always overruns then the user might expect it to pad when it doesn't. I think that padding should be seen as an - if available then do it - type feature. If you must have it record a particular time period then surely you should schedule it to record.
There is not much point arguing about it however, thats how i think it should work, if everyone thought the same, the world wouldn't be much fun!
Yes, that is what I meant by simplicity.
The usage should be predictable, logical and sensible
I agree, but I don't think Humax have achieved that so far. They way it is at the moment, every time I schedule a recording I have to worry about whether or not the box is going to autopad the way I want it to. The complexity has not been hidden if padding is important to the user, as it is to me.
From what Marc says, they rushed the implementation of autopadding last time round and IMO, based on what I read here, they got it wrong. I shall almost certainly be delaying purchase until I see some feedback on how well their next attempt works.
The 9200 has a good reputation for solid software but I get the feeling this is being eroded somewhat. It sounds like it took them two goes to get the MHEG fix right, and it looks like it's going to take at least that many tries to get autopadding right. I think Humax maybe need to re-focus on quality over features. (Mind you, I suspect this has been said of almost every other PVR manufacturer at some point in the last 12 months!)
Yes I think it was a bit of a rush. I was one of the people who suggested it should be taken out but its intended implementation was not thought to be 'wrong', just 'an' implementation of autopadding which people an either make use of if it helps or just not use if it doesnt work for them. The fact that so many people use it probably means that they did actually do something worthwhile even though it wasnt put out with the levels of sophostication that would make it a total solution. If Humax go back over it and make it more than a basic implementation that would be great but they might not - in which case there are other PVRs with certain ways of dealing with autopadding to choose from. I dont have a problem with releasing a basic version of autopadding - I have a choice to make use of it or not - its the bug with consectutive recording that they need to take out for me before they talk about enhancing it. Something they will probably take out in the next version.
that beta was from March - the first one with autopadding. the problem highlighted were what they already knew and told us when they sent it to everyone. Those probems got resolved before release - or so they and we thought - until we noticed doing the same thing in reverse order still coused the problem doh.
The implementation of autopadding was not rushed as such, it was important to get the release out because of the fix for the MHEG problems. We had reservations about autopadding, having had a little time to test it, but it was thought that the fix for the MHEG outweighed any complaints that might arise.........however, seeing the amount of moaning on here lately, this might well have to be reconsidered in future...which may of course lead to delays in further releases.
The MHEG engine used on the 9200T is supplied by a 3rd party, so it is incorrect to state it took Humax two attempts to get it right. I can assure you Humax were just as frustrated as us users that it fell over a 2nd, and indeed 3rd time (BBC, ITV lockups, blanking problem associated with Sky text).
Edit:
Marc has posted whilst I was typing this, and stated his opinions on the release......so I may as well tell you I was for the release, with the added notes, however you will not find me posting info on any further beta releases, or discussions I have with Humax.
To the point where it would be only fair that the MHEG provider was ditched by Humax for any future work. I remember it got to a stage where it was looking like Humax were going to have to boot out Eldons MHEG engine and stick in the one they had on the 8000t - which wasnt displaying any of the same problems.
Barry, my apologies if my posts were seen as "moaning". They were base purely on the Humax not behaving in neither an obvious manner (to me anyway) nor in the way described by the release notes.
I have to applaud Humax for their continued development of the software, and eagerly await the next release.
However after 30 years in the service industry I understand that Humax will not be able to resolve issues they are not aware of and felt the consecutive recording problem warranted discussion.
There are numerous other issues that affect useability that could be discussed, but I feel at this stage only matters affecting the ability of the box to do its job should be raised.
I for one would be more than interested to hear any news of future releases or fixes under development. If we know that the issue of the day is being addressed, then there is no point in wasting bandwidth on these matters.
gtg
I checked this morning and Extraas recording ended after 19'54"
where it switched to the new recording - so applying the auto padding to the start of M&W.
I quess I'll just have to record the whole hour and split it.
I won't know until tonight to check if it gets the Corrie/ Eastenders overlap the way I want it. I have set corrie to end at 20:01.