• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

Recordings cut short

Hello

A new problem to report.

Last night watching some older material. Press Stop at the end and a 'pop up' appeared with a message to the affect to 'Format the HDD to use recording functions', sorry, I can't remember the exact wording. There was an OK button which said it would open Disk Tools, pressing OK seemed to do nothing so I pressed Standby, the Humax shut down and I went to bed.

This morning I come back to it. Humax starts up normally, HDD test passed with no errors and both old and newer recordings play normally. I set a test reservation from morning TV, this was in the list as "Recording failed - lack of signal" OKing this it plays, well 32x fast plays, fine and is the correct length. The channel I used shows 70% strength and 100% quality and shows live without any glitches.

I will have to monitor this but has anyone seen this message before, does it suggest the HDD might be getting 'tired'? BTW the Humax seems subjectively more responsive opening the media list etc then it was before the latest incident.

Thanks for any ideas.
Will
 
I will have to monitor this but has anyone seen this message before, does it suggest the HDD might be getting 'tired'? BTW the Humax seems subjectively more responsive opening the media list etc then it was before the latest incident.
It is really hard to answer the question "is the hard drive getting tired" without access to the SMART data. It could be the drive is getting near to end of life or it could be that a single sector in a critical location became marginal and eventually got mapped out (which might explain the box being a bit more responsive). If you want an informed guess as to which is more likely then remove the hard drive and attach it to a PC and extract the SMART data and post it here.
 
Last edited:
Hello Martin

That's rather what I thought from my experience with PCs. I think I will leave it be for now unless anything else odd happens or the clipped recording issue worsens. I'll also have another look for the paperwork just in case there is any warranty left before opening the box up. Are the drives in these boxes a standard PC type or the 'AV' duty ones that I understand some recorders need?

BH: I called it this way as I thought an 'ify' HDD could well explain the recording issues that I started this thread about. I still don't know that that problem is over as I've one more cut short but very close to the scheduled end so it could have bee a broadcaster issue with that.

Thanks everyone for sharing your experience.
Will
 
Hello

I haven't been using the box much so haven't had anything to report but have now had another cut recording.

It occurred to me that there might be a clue as to what is going on in the "sidecar" files so I have copied the failed rec and thus it's sidecars onto a USB pen to make them available. I could post the files here or would have a look for myself but don't know what I need to open these files or what I might be looking for.

Thanks for any pointers.
Will
 
I have a 2000T and have just realized that that various scheduled recordings have been cut randomly short. I first noticed that Gardener's World 15-5-20 was cut off at 39mins of 60 and Monkman and Seagull on18th cut about in half, looking back in the Media list various episodes of series from most channels are randomly short. This seems to have been happening going back 2-3 months perhaps, and older material from late last year and early this seems to have recorded correctly.

Have the broadcasters been messing with AR during the recent schedule disruption?

For now, I have turned on auto padding. will this override AR?

Will the new padding setting be applied to series reservations already in the schedule?

If others haven't had problems is there anything I can try with my Humax that might correct things?

Thanks for any help
William

Yes padding disables AR. Yes the daily briefings have failed a lot of recordings. Recordings are made at the scheduled time adjusted by padding settings. Box no longer wakes up early to watch for AR start recording signal. Yes AR will affect all set series recordings.
 
Hello

I haven't been using the box much so haven't had anything to report but have now had another cut recording.

It occurred to me that there might be a clue as to what is going on in the "sidecar" files so I have copied the failed rec and thus it's sidecars onto a USB pen to make them available. I could post the files here or would have a look for myself but don't know what I need to open these files or what I might be looking for.

Thanks for any pointers.
Will


The .nts is a binary file. There's a lot of asci text in the .hmt you can read using a text editor. Guessing the problem is the .nts file
 
Hello

Taking these from the bottom

Trev: ~15mins into a 1hr programme. Fast viewing what I did get it was just as an ad break cut back to programme - probably a red herring though as I've had the same kind of problems with BBC material so no breaks. This recording was AR though I've tried padding and still had problems - the whole annoying saga is in the first page of this now over-long thread.

Graham: I've tried both files with a couple of text editors that won't display anything. Would some thing like Ghex do the job?

Bye for now
William
 
I've tried both files with a couple of text editors that won't display anything.
They are binary files, even if there is ascii text embedded in them. If a text editor comes across byte that happens to be the equivalent of an EOF character, it will assume that's the end of text.

If you want to look inside, you need a hex editor (or an editor with binary capability), such as Notepad++ (or maybe Ghex, I don't know it).
 
Even if Teleadict can open and 'read' the file, unless he knows what he is looking for, it's a waste of time trying.
 
Even if Teleadict can open and 'read' the file, unless he knows what he is looking for, it's a waste of time trying.
Yes, quite. He doesn't know what he's looking for and the information he is looking for isn't there to start with, so doubly pointless.
 
Even if Teleadict can open and 'read' the file, unless he knows what he is looking for, it's a waste of time trying.
Yes, quite. He doesn't know what he's looking for and the information he is looking for isn't there to start with, so doubly pointless.
That wasn't my point: I was informing about trying to use a text editor on a binary file. That (hopefully) has taught the OP something, where otherwise he has been taught nothing.

I made no comment about its rationality in these circumstances, other than it being inappropriate to use a text editor.
 
Yes, quite. He doesn't know what he's looking for and the information he is looking for isn't there to start with, so doubly pointless.
Even if the information is in the .hmt file it requires some effort to make sense of it. The only useful information I can see (possibly) relevant to this problem would be "length of recording" at 0x0288 and the "failed recording code" at 0x0290. Perhaps one of af123's tools can extract this information.
 
That might have helped me if I knew what 0x0288 or 0x2990 meant.
:oops: That post was really aimed at prpr. (Message to self: Write answers in a form that the target audience ["The Dumb One"] understands). ;):D
Yes. I could also have pointed out that the recording length (time) is in the 4 bytes starting at the 648th byte (0x0288) in the .hmt file and the failed recording code is in the 656th byte (0x0290). See also HMT File Format.
 
Hello

Well, I've installed Ghex hex editor and grappled with an unfamiliar interface and as far as I can see byte 0x0290 is 00 which acording to Raydn's work means no failure code set. The four groups starting with 0x0288 are F7 02 00 00 but translating these into actual time is beyond me, sorry.

I have also found more short recordings all made with padding on, all I can think of now is to try some manual reservations so as to cut out any use of the schedule data.

Thanks
Will
 
The four groups starting with 0x0288 are F7 02 00 00 but translating these into actual time is beyond me, sorry.
I just patched a file of mine and ran those digits. 12 minutes 39 seconds is what I get. That sounds in line with what you said in post #30. With no failure code and this time - something is very odd.
Is this problem occurring on all channels or just one?
Have you tried to manually record a programme? Pick a 1/2 hr or 1 hr programme, wait for it to start, then press record and see what happens. Does that also pack up after ~15m?
 
Back
Top