Firmware 1.00.23 (the latest/current) is very old now, last OAD over a year ago(?) for the 9200T.
I would be very surprised if any 9200 (where the default to auto-update has been user-disabled) is not up-to-date, though it is not entirely impossible.
However, for "general sluggishness" I would look (if the firmware is current) to doing a "defaults setting" (wiping timers, schedule, and reverting any user changes, but keeping recordings intact) and carefully tuning in local channels.
Firmware 1.00.23 (the latest/current) is very old now, last OAD over a year ago(?) for the 9200T.
I would be very surprised if any 9200 (where the default to auto-update has been user-disabled) is not up-to-date, though it is not entirely impossible.
However, for "general sluggishness" I would look (if the firmware is current) to doing a "defaults setting" (wiping timers, schedule, and reverting any user changes, but keeping recordings intact) and carefully tuning in local channels.
Not at home right now - I'll check tonight, but I'm pretty sure there was a 2007 date stamp on the firmware mine seemed to be running - but I'll double check.
The OTA auto update stuff seemed to be all checked but I've never been aware of an update happening on it
Yeah I have done all the local manual tuning thing and it does help a little. It seems ok at the moment - but with the clocks about to change again will have to do it all over again - it's just fiddly and annoying
Do you put your box into standby at night? If not that would explain the failure to update.
Why do you need to retune when the clocks change?
Every time the clock change happens the box really plays up, wont record anything and has to be retuned - it's quite a common bug I believe - definitely seen others talking about it on here.
No it's always just on - not on standby so could very well be it.
So a firmware update should improve matters then?
It's not the primary box - we use the freesat box for primary tv viewing - but the freeview does all the recordings and want to make the recording more reliable.
Every time the clock change happens the box really plays up, wont record anything and has to be retuned - it's quite a common bug I believe - definitely seen others talking about it on here.
No it's always just on - not on standby so could very well be it.
So a firmware update should improve matters then?
It's not the primary box - we use the freesat box for primary tv viewing - but the freeview does all the recordings and want to make the recording more reliable.
The box certainly does not have to be retuned just because the clocks change, wherever did you get that idea from? There is an issue with the 9xx0 boxes in the week after the clock change where some series links go astray but then reappear the week after. In the week before the clock change the EPG entries for after the clock change show an hour out but this is corrected after the clock change. Don't make any manual timer reservations during this period, use Accurate-Recording.
The box needs to be in STANDBY to pick up automatic OTA software updates, this is clearly stated in the manual. If your box has software from 2007 it may be 1.00.15 which didn't support Accurate-Recording (or Series-Link), this is probably why your box appears to play up around clock change time.
Well series link works ok - so it's not the very first version, I'll check the firmware version tonight.
If I am as I suspect far behind on firmware then I will purchase the USB - COM Null Modem thing and try a manual install
The firmware version is 1.00.21 rev 1.0 Dec 2007, so yeah it is way behined
v23 will make the box more responsive but your missed recordings might be down to something else. Try doing the Manual Search using my instructions if you haven't already done so.
The firmware version is 1.00.21 rev 1.0 Dec 2007, so yeah it is way behined
There has only been one update following 1.00.21 namely 1.00.23 first transmitted from May 2010 details here. This should provide significant improvement to freezing of response to Remote Control commands which was a common problem for 1.00.21 users. Also this latest software results in the EPG data being cached to the HDD during standby and is therefore rapidly made available when coming out of standby rather than a delay of at least 5 minutes previously.
This should provide significant improvement to freezing of response to Remote Control commands which was a common problem for 1.00.21 users.
But not a complete cure for sluggish and freezing. I find that the remote control often freezes for about 20 seconds at a time in the first few minutes after bringing the 9200T out of standby. Initially the remote control is fine, but then it goes sluggish for a few minutes, then it is fine for the rest of the evening. Same thing happens next evening, and the next, and the next ...
My guess is that when the Humax comes out of standby, it populates the EPG with the stored data on the disk. It then checks the EPG against the broadcast EPG and finds lots of changes, or lots of missing stuff (the 9200T has been on standby for 18 hours or so, and hasn't been looking at the broadcast EPG). The remote control freezes while it downloads these changes.
But not a complete cure for sluggish and freezing. I find that the remote control often freezes for about 20 seconds at a time in the first few minutes after bringing the 9200T out of standby. Initially the remote control is fine, but then it goes sluggish for a few minutes, then it is fine for the rest of the evening. Same thing happens next evening, and the next, and the next ...
My guess is that when the Humax comes out of standby, it populates the EPG with the stored data on the disk. It then checks the EPG against the broadcast EPG and finds lots of changes, or lots of missing stuff (the 9200T has been on standby for 18 hours or so, and hasn't been looking at the broadcast EPG). The remote control freezes while it downloads these changes.
I also get occasional freezing particularly after coming out of standby. But nothing as bad as it was prior to the .23 update. I get the impression that it did not occur for the first year or so after the ,23 update. There are other issues with .23 such that the EPG takes a very long time to detect programme schedule changes which results in strange EPG entries but these get corrected when the broadcast starts so I don't find it prevents recording of the affected programmes.
There are other issues with .23 such that the EPG takes a very long time to detect programme schedule changes which results in strange EPG entries but these get corrected when the broadcast starts so I don't find it prevents recording of the affected programmes.
Colin
I agree with your comments.
Also, if my understanding is correct, 9200T recording does not use the EPG. 9200T recording seems to be based on the "Now and next" signal which is continuously, repetitively and very frequently transmitted by Freeview. I seem to recall reading that a complete cycle of "Now and next" for all channels takes about 90 seconds and it is then immediately repeated.
If the 9200T is on standby, and it has a reservation to record programme XYZ with a nominal start time of 9pm, I think the following happens:
1 15 minutes (by the internal clock) before the nominal start time, the 9200T "comes on" (but not comes out of standby) and a tuner starts monitoring the "Now and Next" signal. This is why if you bring it out of standby during these 15 minutes it does so immediately, without the normal startup delay. It is also why "Now and Next" get filled in the EPG differently from later programmes. For example, if the EPG is completely empty, Now and Next programmes get put into the EPG very quickly.
2 When it sees the Program start signal for the 9pm program, it starts recording. I think there is a specific "Programme start" signal transmitted which should be used but I think that the 9200T does not use it. Instead the 9200T seems to start recording when the Programme Information Panel (which is presumably what is transmitted by the "Now and next" signal) changes such that the "Now" programme is programme XYZ.
C5 seems consistently to change the information panel to the next programme well before - sometimes over a minute before - the end of the previous programme and this is why I often lose the last minute or more of a C5 recorded programme. I guess C5 decided it was more important for a recording to include the adverts before it than the adverts after it.
I agree with your comments.
Also, if my understanding is correct, 9200T recording does not use the EPG. 9200T recording seems to be based on the "Now and next" signal which is continuously, repetitively and very frequently transmitted by Freeview. I seem to recall reading that a complete cycle of "Now and next" for all channels takes about 90 seconds and it is then immediately repeated.
Yes the start and end of recordings is controlled by the Now/Next data. The requirements for the transmission of this data are documented in the "Digital Video Broadcasting (DVB); Guidelines on implementation and usage of Service Information (SI) DVB Document A005, October 2011" (the Blue Book). The data stream which carries this information is defined as the Event Information Tables (EITp/f [present/future]). For the channels on the currently tuned MUX(s) the Blue Book specifies that the data is transmitted at least every 2s. The start and stop signals are not specific events but are based on the status of the EITp/f. The start of recordings is signalled when the EITp/f data changes to show the subject programme as the "present" programme and the end of the recording is signalled when the data changes to show the following programme as "present".
If the 9200T is on standby, and it has a reservation to record programme XYZ with a nominal start time of 9pm, I think the following happens:
1 15 minutes (by the internal clock) before the nominal start time, the 9200T "comes on" (but not comes out of standby) and a tuner starts monitoring the "Now and Next" signal. This is why if you bring it out of standby during these 15 minutes it does so immediately, without the normal startup delay. It is also why "Now and Next" get filled in the EPG differently from later programmes. For example, if the EPG is completely empty, Now and Next programmes get put into the EPG very quickly.
The EPG data is transmitted in the" EIT Schedule table" data stream. The Blue Book defines that for the first full day for the currently tuned MUXs the data should be transmitted at least every 10s. However, the Humax SD PVRs are not very good at detecting and/or displaying changes in this data as a result of programme scheduling changes.
2 When it sees the Program start signal for the 9pm program, it starts recording. I think there is a specific "Programme start" signal transmitted which should be used but I think that the 9200T does not use it. Instead the 9200T seems to start recording when the Programme Information Panel (which is presumably what is transmitted by the "Now and next" signal) changes such that the "Now" programme is programme XYZ.
The Now/Next information displayed by the PVR when on live TV and the "Info" button is pressed is derived from the EPG data and is thus synchronised to the scheduled times for the programme and not the transmitted EITp/f data. However, the 9200 does use the EITp/f to control recordings, albeit not very accurately when starting recordings, resulting in delayed starts.
C5 seems consistently to change the information panel to the next programme well before - sometimes over a minute before - the end of the previous programme and this is why I often lose the last minute or more of a C5 recorded programme. I guess C5 decided it was more important for a recording to include the adverts before it than the adverts after it.
C5 has a very poor reputation for providing Accurate Recording data.
If you go to the Humax web site you will eventually find that most of the problems have been fixed in v 26 of the software, BUT this is only available for the 9150 and 9300
I have been in touch with Humax for a long while now, since soon after v 26 came out and I have asked when we can expect v 26 for the 9200
I have explained that my wife thinks it's now as useful as the proverbial "chocolate teapot" :-)
They have assured me that the 9200 is still supported, but have never came up with any good reason why the software has now been updated for the 9200
I have even suggested that they release it as open source so that some bright sparks out there can fix it for us. But they declined to comment on this.
If you go to the Humax web site you will eventually find that most of the problems have been fixed in v 26 of the software, BUT this is only available for the 9150 and 9300
Actually if you go over to Myhumax.org you will find Barry asking for volunteers to test a new version for the 9150/9300 to fix a problem introduced at 1.00.26.
Actually if you go over to Myhumax.org you will find Barry asking for volunteers to test a new version for the 9150/9300 to fix a problem introduced at 1.00.26.
Martin
a) v 26 fixes problems seen with v 23 (v 26 may have other issues of it's own)
b) I can't find said firmware on myhumax.org
c) Even if I could, wouldn't be any use to me as I have a 9200
My 9200 seems to have got far worse recently in missing recordings. Andrew Marr every week, as well as other BBC shows. C4 and C5 seem not to exhibit the issue.
It used to be so reliable - I'm not sure what has changed!
My 9200 seems to have got far worse recently in missing recordings. Andrew Marr every week, as well as other BBC shows. C4 and C5 seem not to exhibit the issue.
It used to be so reliable - I'm not sure what has changed!
Do you have any channels starting at channel number 800?
My 9200 seems to have got far worse recently in missing recordings. Andrew Marr every week, as well as other BBC shows. C4 and C5 seem not to exhibit the issue.
It used to be so reliable - I'm not sure what has changed!
My personal opinion is that the broadcasters are sending the Now/Next information in a format that is in-compatible with V21 of the 9200's software.
I suspect they are transmitting using a newer standard, which V21 can't cope with.
As I said this is my personal opinion, my justification is that if you look at the release notes for v26 on the humax site (for 9150 and 9300) you will see that the 9200's bugs are fixed.
Also the bugs did not show up before DSO when the broadcasters changed the method of transmission when there were no analogue channels.
Apologies for mentioning v21 in earlier posts, my humax is on v23. I would not like to go back to v21 as the lack of response on the remote was awful.
Comments
I would be very surprised if any 9200 (where the default to auto-update has been user-disabled) is not up-to-date, though it is not entirely impossible.
However, for "general sluggishness" I would look (if the firmware is current) to doing a "defaults setting" (wiping timers, schedule, and reverting any user changes, but keeping recordings intact) and carefully tuning in local channels.
Not at home right now - I'll check tonight, but I'm pretty sure there was a 2007 date stamp on the firmware mine seemed to be running - but I'll double check.
The OTA auto update stuff seemed to be all checked but I've never been aware of an update happening on it
Yeah I have done all the local manual tuning thing and it does help a little. It seems ok at the moment - but with the clocks about to change again will have to do it all over again - it's just fiddly and annoying
Why do you need to retune when the clocks change?
Every time the clock change happens the box really plays up, wont record anything and has to be retuned - it's quite a common bug I believe - definitely seen others talking about it on here.
No it's always just on - not on standby so could very well be it.
So a firmware update should improve matters then?
It's not the primary box - we use the freesat box for primary tv viewing - but the freeview does all the recordings and want to make the recording more reliable.
The box certainly does not have to be retuned just because the clocks change, wherever did you get that idea from? There is an issue with the 9xx0 boxes in the week after the clock change where some series links go astray but then reappear the week after. In the week before the clock change the EPG entries for after the clock change show an hour out but this is corrected after the clock change. Don't make any manual timer reservations during this period, use Accurate-Recording.
The box needs to be in STANDBY to pick up automatic OTA software updates, this is clearly stated in the manual. If your box has software from 2007 it may be 1.00.15 which didn't support Accurate-Recording (or Series-Link), this is probably why your box appears to play up around clock change time.
If I am as I suspect far behind on firmware then I will purchase the USB - COM Null Modem thing and try a manual install
v23 will make the box more responsive but your missed recordings might be down to something else. Try doing the Manual Search using my instructions if you haven't already done so.
Colin.
Edit:- Beaten to the post by Big-Les again.
But not a complete cure for sluggish and freezing. I find that the remote control often freezes for about 20 seconds at a time in the first few minutes after bringing the 9200T out of standby. Initially the remote control is fine, but then it goes sluggish for a few minutes, then it is fine for the rest of the evening. Same thing happens next evening, and the next, and the next ...
My guess is that when the Humax comes out of standby, it populates the EPG with the stored data on the disk. It then checks the EPG against the broadcast EPG and finds lots of changes, or lots of missing stuff (the 9200T has been on standby for 18 hours or so, and hasn't been looking at the broadcast EPG). The remote control freezes while it downloads these changes.
But you've included more information whereas I had my butties to make.
Colin
Colin
I agree with your comments.
Also, if my understanding is correct, 9200T recording does not use the EPG. 9200T recording seems to be based on the "Now and next" signal which is continuously, repetitively and very frequently transmitted by Freeview. I seem to recall reading that a complete cycle of "Now and next" for all channels takes about 90 seconds and it is then immediately repeated.
If the 9200T is on standby, and it has a reservation to record programme XYZ with a nominal start time of 9pm, I think the following happens:
1 15 minutes (by the internal clock) before the nominal start time, the 9200T "comes on" (but not comes out of standby) and a tuner starts monitoring the "Now and Next" signal. This is why if you bring it out of standby during these 15 minutes it does so immediately, without the normal startup delay. It is also why "Now and Next" get filled in the EPG differently from later programmes. For example, if the EPG is completely empty, Now and Next programmes get put into the EPG very quickly.
2 When it sees the Program start signal for the 9pm program, it starts recording. I think there is a specific "Programme start" signal transmitted which should be used but I think that the 9200T does not use it. Instead the 9200T seems to start recording when the Programme Information Panel (which is presumably what is transmitted by the "Now and next" signal) changes such that the "Now" programme is programme XYZ.
C5 seems consistently to change the information panel to the next programme well before - sometimes over a minute before - the end of the previous programme and this is why I often lose the last minute or more of a C5 recorded programme. I guess C5 decided it was more important for a recording to include the adverts before it than the adverts after it.
The EPG data is transmitted in the" EIT Schedule table" data stream. The Blue Book defines that for the first full day for the currently tuned MUXs the data should be transmitted at least every 10s. However, the Humax SD PVRs are not very good at detecting and/or displaying changes in this data as a result of programme scheduling changes. The Now/Next information displayed by the PVR when on live TV and the "Info" button is pressed is derived from the EPG data and is thus synchronised to the scheduled times for the programme and not the transmitted EITp/f data. However, the 9200 does use the EITp/f to control recordings, albeit not very accurately when starting recordings, resulting in delayed starts. C5 has a very poor reputation for providing Accurate Recording data.
Colin
If you go to the Humax web site you will eventually find that most of the problems have been fixed in v 26 of the software, BUT this is only available for the 9150 and 9300
I have been in touch with Humax for a long while now, since soon after v 26 came out and I have asked when we can expect v 26 for the 9200
I have explained that my wife thinks it's now as useful as the proverbial "chocolate teapot" :-)
They have assured me that the 9200 is still supported, but have never came up with any good reason why the software has now been updated for the 9200
I have even suggested that they release it as open source so that some bright sparks out there can fix it for us. But they declined to comment on this.
Release notes for 9150
Release notes for 9300
Release notes for 9200
Martin
a) v 26 fixes problems seen with v 23 (v 26 may have other issues of it's own)
b) I can't find said firmware on myhumax.org
c) Even if I could, wouldn't be any use to me as I have a 9200
It used to be so reliable - I'm not sure what has changed!
Do you have any channels starting at channel number 800?
I suspect they are transmitting using a newer standard, which V21 can't cope with.
Had to be asked.
Also the bugs did not show up before DSO when the broadcasters changed the method of transmission when there were no analogue channels.
Apologies for mentioning v21 in earlier posts, my humax is on v23. I would not like to go back to v21 as the lack of response on the remote was awful.