Thank you for your comments.

Sorry I did not explain things too well before - the reason for disconnecting the HDD was to see if a menu or anything came through on to the tv - it did not.

The cooling fan is not working either - I dont know if it is dependent on temperature, presence of a functioning HDD - or whether it just runs all the time.

Because of work etc I shall not get a chance to play again until weekend but I should be able to check the HDD in my PC then - sadly I dont have any gizmo to plug into my USB- but maybe Santa will bring one - you never know!

In the meantime if there are any links to service data etc a pointer would be most welcome - thanks again!

You need to know that the filesystem on even a working HDD will not be readable under Windows. Even to see it, you will need to right-click on "my computer", select "manage" and then "disk management". In the bottom pane, it should show up as an uninitialised drive containing unallocated space. It won't be allocated a drive letter.

Been away from the forum for some time (as my 2 DHD 4000s have been working flawlessly), so if I've missed something along the way, please be gentle.

Doug: if you're planning to test the HDD in your PC (by presumably installing it as a second+ IDE drive), try Dan Hope's s/w from here:
http://www.hope.co.nz/projects/fusion/
Boot up from your normal HDD and you will/should be able to peer into the drive to see if all looks well. Just remember that the jumpers are currently set to Cable Select, so will need to be changed back if you have to mess with them.

Ashley

Slightly strange occurence this morning. I programmed today's "Strictly Come Dancing - It Takes Two" last night and this morning there was a message waiting to say that the time had changed. When I checked the EPG and the list of recordings it had not changed, so I don't know what caused that one.

The way it checks stuff that has changed is if the description and/or times change in the overnight EPG. I get it quite often with Panorama where they update the programme name with its content the night before broadcast.

Again thanks for the info and suggestions njp and ash_earwig - I am going to have to do a bit of research before I pronounce on state of HDD!

Got a problem with the DHD4000 tonight - the live pause/trick play buffer is set to 120 mins but it currently is only buffering 87-ish mins, it won't scan back beyond this even though it has been tuned to that channel for longer. Leaving it for a while so that more should be recorded, i.e. so that you should be able to scan back further, does nothing, it still stops scanning back at around 1:27:00

Anyone else had this and know the cause?

Definitely ropey software this version 2.3.9, if you play too close to the end of the trick play buffer, e.g. 119 mins behind real time in my case (though not tonight...) it keeps resetting to the live broadcast position.

You seem to make rather a lot of use of the rewind buffer. Wouldn't it be better just to record the programmes?

Personally, I set the buffer to 70 minutes and regard 60 minutes as the actual limit, to avoid any possibility of encountering the problem you describe. Getting within a few minutes of the start of the buffer is asking for trouble, because the variable nature of the compression means that the live transmission can "catch up", so that the start of the buffer gets overwritten. Somewhat poor design, however - if I'd designed it, I'd have made the buffer a bit bigger than the user specified and not allow him to wind back all the way to the start.

Your point seems to be "why have the rewind buffer at all?". Would prefer suggestions relating to my question. I do so like rewind buffers, especially reliable ones.

In view of your previous problems with the corrupt recording and iffy buffers, I'm inclined to think that the hdd has maybe become unreliable and needs replacing. There are a couple of self-test options in the engineering menus but I don't know if they provide any useful information.

I've indicated the reasons why you hit problems if you wind right back to the start of the buffer, and conceded that this is poor design, and told you how to avoid the problem.

I could speculate about why you aren't getting your full two hours under some conditions (it relates to the different data rates on different channels, combined with how and when the rewind buffers are allocated), but none of that would help you.

I don't think your hard drive is faulty.

I do appreciate you taking the trouble to respond to my post but regretfully I don't find suggestions of "avoid provoking the bug" (by not going too near the end of the live buffer) and "stop using the feature altogether" (by making a discrete recording of the programme instead of using the live buffer) deal with the matter raised. It says "if you have an itchy **** then scratch it" when the original question is represented by "why is my **** itching and what can be done to stop it itching in the first place?".

Sometimes I've had it playing reliably at *beyond* the 2 hour point, I think I've seen 2:05:00 without any resetting, other times it keeps resetting to live from as far away from the buffer end as 1:53:00 (even though it will reverse scan up to 2:00:00, so recording data is definitely present), and on Boxing Day - when I raised the problem here - it wouldn't even reverse-scan beyond 1:27:00 and kept resetting at 1:25:00, even though there was plenty of spare hard drive space.

Just to repeat my original question re: the shrinking buffer issue: "Anyone else had this and know the cause?".

Regarding "the shrinking buffer". The rewind buffer can only reach a set maximum size and this set size has to be guestimated to a certain extent.

So lets say its set to 2 hours and they allocate 1Mb a minute then the 2 hour buffer would be 120Mb. Now lets say you watch a channel that runs on average at less than the 1Mb a minute margin and therefore you would be able to store more than 2 hours in the 120Mb allocated for the buffer. Conversely if the channel being watched runs on average at more than the 1Mb a minute margin then you would only be able to store less than 2 hours in the allocated buffer.

Now the channel bit rate will not remain constant and will vary. So if you are near to the maximum limit of the buffer and the amount of data leaving the buffer (i.e. being watched) matches that of the data being stored (i.e. the current live program) then there will be no problem. However if there is suddenly an intensive scene which pushes up the bit rate for the channle then all of a sudden there is more data to be stored than that which is leaving the buffer and when this occurs the buffer fills up. When it is full there are then three options:-

1. Stop recording the live scene and lose the remainder of the live program.
2. Drop enough of the stored buffer to continue recording the live program however there will then be a jump in the viewing as you lose the chunk of the buffered program.
3. Jump to the live program.

Hopefully this clears up the issue and demonstrates why you get unreliable behaviour when using the rewind buffer. I'd go with a similar theory to the above and only rely on having the past 1 and a half hours buffered. I don't quite understand why you don't record the program in the first place cause then you know you will definitely be able to watch all of it.

Note: All the above figures regarding buffer sizes and bit rates have been made up just to demonstrate the point (and keep the maths easy).

Thanks all. I wonder if Thomson will update the box for the new Teletext Extra service as is happening for a number of other boxes - it'd be an opportunity to fix the problem, assuming it is a bug which affects everyone rather than just my unit (which is what I'm out to discover along with whether anyone's found a workaround or cause).

Re: the fixed buffer sizes running out with variable transmission bit rates theory, the box doesn't seem to operate in this way. One great way to free up hard disk space is to change channels twice to ones different from the last two watched (making sure both are at the live position). This frees the old live buffers and starts afresh, which (if you're out of space) usually gives a chance to get another recording or two added to the list as you suddenly get a whole lot of new free space as shown by menu-3. You can then keep monitoring the disk space to see it slowly go back down as the two new channels are being live-buffered until they hit the buffer time limit chosen - this wouldn't happen if the buffers were pre-allocated, different to Sky+ which does pre-allocate if I remember rightly.

I was aware of this behaviour, which is why I wrote that I would only be speculating as to the precise cause of the problem. There could simply be a bug in the algorithm which determines the amount of free space, rather than variable buffer sizes.

But whilst it would be intellectually satisfying to know the answer, the software on the DHD4000 isn't going to change now, so I just live with its little quirks rather than spending my time trying to understand them!

Yeah I think I have noticed something like this but as I have a 2.5" 120G hard disk fitted which gives approximately 80 hours of space I have never paid much attention to the used, reserved and free space

It would be useful to know what provokes the buffer to suddenly reduce in size from 2 hrs to (on one occasion) less than 1hr30mins, and I very much appreciate you're not in a position to answer that.

It doesn't happen often, once a month say, which is why avoiding using the buffer by setting a recording, or not running too near the end of the buffer, are not solutions - you don't know when to do either unless you know when the problem will happen, which is what my question is about. If anyone's tied down some kind of predictability to it, maybe a chain of events that provokes it, that would be useful to know as it might be possible to avoid it or predict it at least. And if no one else has had it happen ever then I may swap in another hard drive and reformat it to see if that solves it. All very useful information which would be gratefully received. The truth is out there!

Ok, it's probably clear to you by now that I don't much care about "solving" the problem, because it never affects me.

However, if I did care, my approach would be to first determine if the observed symptoms are consistent with fixed buffer size / variable bit rate. My working hypothesis would be that the apparent freeing of disk space when the buffers are cleared by changing channels is merely a bug that stops you scheduling recordings when you ought to be able to (you could test that hypothesis by checking whether the "new" buffers allocated in this situation really are shorter than usual - in which case you have another possible explanation!)

Then I'd run a series of tests in which I measured the "true" buffer length on many different channels, along with the average bit rate for that channel. The bit rate could be looked up (I think) or determined by making recordings and looking at the file sizes on a PC. I'd do this enough times to be reasonably sure I'd captured all the outliers... I'd do the sums to see if the results implied a fixed buffer size. I'd check whether my previously observed minimum buffer length fell within the range expected from my experiments...

I could go on, but you get the general idea. My eyes are glazing over just writing about it, let alone doing it!

njp, I would be grateful if you could leave some space for those who may have experienced this problem, or who are at least in a higher position than yours of "not much caring about it", to come in on this subthread. At the moment I see the thread as having bloated with paragraphs of not-especially-helpful speculation and answers to different questions to those originally asked. I don't really like asking people to sit on their own goodwill, but would you mind doing so on this occasion?

Whatever. I predict that nobody else either knows or cares.

And before you get so snooty about what should or should not go into a thread, you might like to reflect on the fact that you did not choose to start a new thread for your own peculiar problem, but instead merely tacked it onto the end of an existing thread.

Others may be grateful to know that I will address these matters directly with "njp" in private, which I perhaps should have done previously - I apologise to those to whom those posts were not relevant for failing to do so.

Next time it happens make a note of how much free space is left on the drive so we might decide on its relevance.

Actually I had that info - (post #62):


Anyway it more or less seems that no one else has had this happen, judging more by what has not been said than what has. It's ok if the box does it every now and again, but to cut Morecambe and Wise in half, as it did, is pure criminal.

Could there be a corrupted buffer file? Maybe impulse interference has disrupted the signal? (hasn't affected my machine, as far as I know).

The other 'nuisance' problem concerning watching close to the buffer limit has caught me out too.

I think there is 'time slippage' when watching via the buffer. For example, you might rewind the live buffer to maybe 40 seconds behind 'live', but the time via the on-screen display might flutter between 40-41-40-41-40-41 seconds, etc then all of a sudden it jumps to 42 seconds.

The reason might be that a fast moving scene is taking a little longer to process.

I went to put my Tommy on and it wouldn't come out of standby. The red light was on and nothing could get it to power on. I tried the remote and the power button on the front. I thought maybe the overnight update had screwed it up.

I decided to unplug it and now I get nothing when I plug it in. There is no light on the front at all and it doesn't do anything to switch on.

It is 4 years old now and has been near perfect in operation.