I've used a lot of freeware over the last quarter of a century and it generally works but there's always rough edges. I'm not trying to put it down but it's far from the rosy picture of perfection you seem to be trying to paint. The best you can say for 90% of it is 'It works as long as you don't get too adventurous'.

Hardly. Trying to estimate anything without access to source code is a fool's errand. Even having the source code to a project you're familiar with doesn't ensure an accurate estimate. That's why software development projects are notorious for overruns. I couldn't begin to guess how long a 'typical' HDR related issue takes to resolve. My experience suggests that this would probably be one of the easier things to address - but 'easier than something that I don't know' doesn't help.

How do you know? You haven't seen the source code.

Anyway I suspect the real delay is as the last poster wrote - they are working on other things. Sadly that's the way it goes when hardware manufacturers also produce the software. It's why I look with dismay at the mobile phone industry. We still have Android as an independent (sort of) outlet but even that shows signs of becoming locked down.

What would concern me most about trying to guess at the complexity of this is that the HDR is basically 'embedded programming'. That means there are almost certainly quite strict resource limitations in force. With a full blown computer you can pretty much have any size <list of something> you want. Neither memory nor (in general terms) CPU power to iterate it is in scarce supply. If you want to add another UI event then you just do. You can afford to waste CPU cycles on housekeeping (or just defer it for when the machine is idle) whereas embedded systems often have to make assumptions rather than try and figure things out at runtime and housekeeping has to be continuous.

In an embedded system lists tend to be fixed size. Quite often with optimised access through some form of hashing (ie;fitting within a single page of memory). For all we know adding one more option might break the existing access hashing algorithm and require a new one to be created. That might push the size of a list beyond its ideal size. Maybe they index events using 5 bits and this would be event number 32.

In this case one of two things is probably needed:
* Extend the information stored for all timers so that a 'hidden' flag can be added.
or
* Create a second list containing just the hidden items and remove them from the primary list.

The first one could significantly increase the schedule memory footprint. If their coders have been careless and used byte offsets rather than structures then changing the structure definition could invalidate reams of other code. If they have used hardcoded or defined values for the size of the structure instead of sizeof() then moving them around is at risk.

Creating a second list might reduce a lot of the above problems but then any code that works with timers has to to know to check and update both lists. If the lists are linked rather than vectors then what impact does fragmentation have on the system when there is another list?

Then for the UI: Do we have any spare buttons at that point? Is that true for all use cases? Is there enough space in the event/control map to add this function? Is there even an event/control map - perhaps it's just a collection switch/case blocks.

That much I can think up in barely ten minutes. If I wanted to spend half an hour on it I could probably fill the screen with 'what ifs' and 'gotchas'.

It works great,
I use Comodo AV and Firewall

teamviewer for remote desktop (works better than MS)

XnView for image editing (coded by a lone person for Win, Mac and Linux)

Media player home cinema (works far better than WMP)

At least half a dozen other programs, I know theres bad freeware out there but the ones I use are fantastic.

Theres no excuse for Humax not having a good user experience, thats why they will remain a niche name and not something you associate with quality.

Exactly, its taken a back seat as they want more money for the new product.

The thing is people arent going to upgrade their current box as they know the newer one will have lots of bugs and niggles.

If they fixed the old box, theyd earn a lot of money from repeat purchases from people happy with them.

As it is, if my box goes boom, I will not buy another Humax unless I have no choice.

Good luck with choosing a PVR from one of the other 'quality' freesat manufacturers.

What exactly is wrong with peoples boxes, mine one is perfect .. bar the usb 1.0 device (which I don't use).

What usb1.0 device ?. I can easily stream 19mbps HD content from my hdr's usb port.

I agree with your assessment of the reality of the development cycle, including both technical challenges and the configuration management overhead to which you alluded earlier.

Don't you just love the inspired amateur - at least on a forum it presents less of a challenge than an end user sponsor with a little bit of knowledge, but a lack of understanding of the whole process

It acts like one, when copying content off the built in HDD

Couldn't agree more

I was going to buy the Samsung but judging by the number of bugs it's not fit for purpose, and it will take them years to sort it out.

I've already got the Bust HD Freesat receiver and it's the biggest pile of poo that's ever sat under any TV I've owned, so I wouldn't touch the Bush with yours (if you'll pardon the pun!).

Goodman is from the same stable as Bush - pants that is.

That leaves me with the good old Humax. I've been waiting for version 2 of this for ages, but I'm about to take the plunge with version 1 and add a cheap BluRay player (like the Sony 370) to handle DNLA streaming from my PC and playback of divx/xvid from USB.

That's not a limitation of the usb port it's because the cpu is doing lots of other processing at the same time. It's still way quicker than usb 1.0. A 10mbps HD 1 hour recording takes about 15 minutes to copy to my 1TB sata drive over usb. That's a data transfer speed of 40mbps. USB 1.0 was capable of just 1.5mbps. The one hour recording would take nearly 7hrs to copy using usb 1.0

I havent looked into the market but if there was a manufacturer that I trusted then Id buy that, as I said, I only get another Humax if there was no choice.

As for the box, the hardware is great but the GUI is so illogical and niggly. Loads of little things are wrong but would be so easy to put right. Thats what makes it so annoying, it can be great but they wont put a small bit of effort into it.

eg, if I have to manually change the stop or start time, the recording then doesnt show up in the EPG but does in the schedule.

I see logic isnt your strong point.

As pointed out, amateurs can write a multiplatform program, with millions of hardware combos without any noticeable bugs in their spare time yet a professional company cant be bothered to fix things with a single configuration.

Therefore if amateurs can do it for a more difficult job, Humax should be able to fix very minor things.

What I love are the 'inspired amateurs who can't tell the difference between the utterly trivial and the fiendishly difficult and treat, for example, recording from the buffer and altering the timeout on numeric channel entry as if they were of equivalent difficulty.

I just set a one off recording of the Weakest Link and converted it to a manual recording by setting it to start 3 mins early and finish 3 minutes late. It's still flagged in the epg

Someone who chooses to write software in their spare time isn't necessarily an amateur. Who knows what their day job is?

Well they arent getting paid for doing that job.

Even if that is their job, they are still doing in their spare time after a 35-40 hour working week, something Humax cant even do with many times the man hours.

Thats because you set it early and then record after it finished, try setting it to start 15 mins into the program which is what I often do when Im recording football.

Can't argue that they do it in there spare time. I wonder how long it takes them.

Not sure but if 1 person can do it in their spare time and its a much, much bigger job, youd have thought a team of professionals could manage a few bug fixes it in their 35-40 hour week.

You have no idea of the other demands on a professional's time that leads them to pulling their hair out at times.

So? Then its a management fault. I dont really care, as a customer, it should be fixed.

Glad you agree that it is a not necessarily a question of programming competence.

I never said it was, I said it cant take too long to do these simple fixes.

Theyve had thousands of man hours available to do it but decide not too.

A bit like a games manufacturer releasing a bug ridden game and then dropping all support to work on next years instalment expecting people to fork out again.

You are guessing.

ROFLMAO.

Guesses? That's what around 60% of the posts on this forum are. At a guess.