Recorded titles are 0.00 bytes? - Help requested


Hi guys. I'm a new member and a relatively new Humax HDR Fox T2 owner
I've installed the latest customized firmware and some of the packages that I thought would be useful to me
Everything seemed to be OK until recently I noticed that some of the (most recent) recorded titles are showing as 0.00 bytes
I am also using hummypkg as I am overseas at the moment so do not have local control
This is a bit worrying as I set several scheduled recordings and it seems as though nothing will actually record
Is there someone who can possible help me with this issue
Any advice/help would be most welcome :)

PS - There is an image attached
zero bytes rec.JPG
If you are using Accurate Recording these are probably examples of the AR system letting you down. See "AR" in the Glossary and "AR v Padding" in the Index (links below).
I don't know if this is related, but has anyone else experienced this problem?

I have had several instances where I have set a recording but have actually been there at the time. I have pressed Stop and the recording has stopped, but then a zero length file has been created. I cannot then delete this file from the TV interface. The only way is to FTP or Telnet in and remove it.
First of all thanks for the Black Hole - I have now changed a couple of schedules (for later today) from AR to Padding to see what happens, appreciate the advice
I am also attaching a couple more screen-shots to illustrate what's happening...the 1st is from my FTP and it shows the file info for 3 schedules of 'deal or no deal' (I know....very sad...they're for the wife! honestly ;) ) ….these clearly show 0 bytes for the 2 events that failed (11th and yesterday)……..and also on the 2nd pic it shows that all was OK on 10th June (Sunday) but the next 2 series recordings (11th and 12th) are on 0.00 bytes which assumes they didn’t record. All very odd!
FTP view.JPG Hummy RS view.JPG
That is very strange. A recording which fails due to AR would be indicated by a zero byte .hmt file and no associated .ts/.nts/.thm files. This something I haven't seen before.
Does FTP show them as zero bytes too?

Sorry, 0 minutes not bytes. On trying to delete, message is "Recording (less than 30 secs) may not be stored." (On pressing OK button for the context menu.)

The files are NOT 0 bytes in FTP but can be deleted there.


(a) set a timer
(b) watch that channel (necessary?)
(c) wait for recording memo to flash on and off
(d) immediately press Stop button.

The associated files are created too.
Are you aborting recordings then?

Yes, as I said, stop the recording a few seconds after it starts. On the Foxsat HDR, the files are deleted, but it seems as though on the T2 the files are created but are inaccessible apart from via FTP/Telnet/SSH. This is possibly true up to recordings of 30 seconds, but is certainly true if you abort as soon as the recording starts.
I have started a new thread HERE in case this is not a customized f/w problem.
Update - Just checked if the first schedule (which I changed from AR to padding) actually recorded..... and it did. This is good in the sense that at least I know that I can rely on the unit to actually record what I ask it to but raises the question as to why should an option such as AR become so unreliable that if it’s going to miss the thing it’s supposed to do why would anyone ever trust it? And also, it doesn’t really explain af123's earlier opinion regarding the creation of 0 byte files for anything other than a .hmt? My thinking now is that I must change all of my schedule to padding.....does this seem the most logical solution?
... raises the question as to why should an option such as AR become so unreliable that if it’s going to miss the thing it’s supposed to do why would anyone ever trust it?

I would have to say AR works well for most users, It is not really understood why a few uses (BH being the No. 1) have such a bad time with AR, but it is known that AR is effected by duplicate channels (e.g. 800 and above) and I personally think it may have something to do with the clock on the Humax being not in sync. with real time.
With reference to post #12, these points are thoroughly discussed in the links I indicated before.

Lack of clock sync? Maybe, but as we have some evidence that the clock drifts since the last cold start it should affect most people.
Lack of clock sync? Maybe, but as we have some evidence that the clock drifts since the last cold start it should affect most people.

The point being that maybe some of the Real Time Clock crystals allow drifting at a much faster rate than others
Not sure if any of this is relevant but it may help understand what is happening (and why)......I did not buy my T2 new and when I got it I never actually changed anything as everything seemed to work as soon as I hooked it up. Maybe I needed to retune the channels and set the clock? Also, what changed between 10th (success) and 11th (fail)? See post 5......One more thing: when I first started experimenting with foxy and FTP etc etc (and not really that sure what I was doing) I may have inadvertently deleted some of the files in some of the media folders and the parent folder......but I assumed that they would rebuild themselves so didn’t think too much about it
Clock - not a problem as long as you have an aerial connected (that's not as daft as it sounds), the rest is hypothesis.

Certainly you should do a proper tuning (but note it will destroy your recording schedule - back it up in the WebIF first). Try an automatic scan, and then if you have ANY services at 800 and up carry out a manual tune for ONE TRANSMITTER ONLY as per instructions (see Index, link below).

There is no real damage you could do fiddling around with the standard FTP server, as it gives you a restricted view of the file system.
Thank you Black Hole for helpful and constructive advice which I will follow and report back results. Incidentally, all schedules which were changed from AR to padding were clearly making some progress
You might prefer to set padding as your default (Menu >> Settings...). I have padding as my default and then use the WebIF to change very select schedules to AR (when the programme is on one of the main channels and there is a significant risk of overrun or overrun of a previous programme). Your padding values need to account for slight broadcast timing variations (which can be early) and the clock drift: I recommend -2 +5, though actually I use -2 +10. If you have consecutive programmes or tuner over-subscription induced by padding, the recording times revert to "as published" in the conflict zone.
Thanks again BH for your knowledgeable advice. I am overseas for another 2 weeks but will make all these system changes when I return to the UK as I don’t think I can do them remotely.....unless you tell me differently :rolleyes: