Originally Posted by JohnH77:
“I find that series links still work even if the next episode is missing in the EPG.”
Under the current way it works even with gaps it is virtually impossible for it to be missed. I was talking about a small risk if the software was changed how you suggested not the software as it is now.
Originally Posted by JohnH77:
“ The worry is what happens if I add two "same time" recordings, and the gaps fill and I now have a clash with a series linked program. I am pretty sure that I once ended up having three programs being recorded at the same time (presumably just from one or two multiplexes).”
Yes you may have experienced this. It can occur with a full epg. The freeview + spec specifies that clashed are checked with a new timer when it is first created. The Humax software does this and no more than that. If there are 3 existing series timers that clash in the 2nd or subsequent weeks then it will not warn you.
Originally Posted by JohnH77:
“I also find that if I am tuned to a multiplex, then that multiplex often goes out the full 7/8 days. BBC repeatedly does this. So, when I am going away, I have resorted to leaving it on each multiplex for a few hours to populate that multiplex's EPG, and then set my recordings on that multiplex.”
That is also my experience with the 9200T when all multipexes are tuned to. But if I miss out 1 multiplex when tuning then its more like 30 minutes rather than 3 hours. Other than that I can only sympathies with you.
Originally Posted by JohnH77:
“I am also surprised that, if it is a "lack of processor power" problem as we suspect, that Humax didn't recode such that it first did one multiplex to completion, then another, then a third etc. I would have thought that they could have spread the load over a longer time - it would take longer to complete, but it would complete. As it is, we seem to be running into overload problems when it just stalls. Of course, it could be that it is the quantity of EPG data in a single multiplex which is casing the problem, in which case my ideas can be consigned to "write-only memory", aka the hollow, round cylindrical object in the corner of most rooms.”
The original 2005 software for the 9200T was quiet primitive compared to later versions. At the time of first release the hardware was adequate for the functionality and for both the content and the size of the epg.
The epg is on a 4 1/2 to 5 minute broadcast cycle on each multiplex. The 9200T used to take 2 cycles (9 minutes) to populate the epg and did so from scratch every time it was switched on. This was OK at first but well before the gaps started to appear in 2012 there was a slow down of remote control commands during those initial 9 minutes. Humax rectified the slow down (in early 2010?) by spreading out the population of the epg over far more than 9 minutes and also cashing the epg to disk to minimise the inconvenience at startup. That also meant that it was only after a reset, a full retune, or a week of zero usage did the 92000T have to populate the epg from scratch. That was fine until the 2nd half of 2012 when the gaps started to appear how ever long and however often the 9200T was switched on.
My view is that there was something that could have been done but for a product 7 years old it may have been too big a rewrite of the code to be of benefit even for a bit more PR. My understanding was that the Topfield 5800 and Humax 9200 were supposed to be very similar in some of their internal design. The native Topfields began to suffer from an inability to cope with the size of the freeview epg in the spring of 2012. Topfield had allowed an API interface for user code. There were a few user written EPGs for the Topfield and the method most of them used unintentionally got round the native memory limit.