FoxSat HDR Deleting Its Own Files

Jellyroll

Established Member
Joined
Apr 13, 2011
Messages
142
Reaction score
7
Points
44
Last night I deleted a recording from my Foxsat HDR. It's an upgraded unit with a 2TB disk (that's been working flawlessly since I installed it over a year ago) and Raydon's 4.04 firmware bundle (that's been working flawlessly since I installed it over a month ago). I then went to delete another recording and it told me that it couldn't delete while another deletion was taking place. I waited, and the deletion icon stayed on-screen.

That was odd, so I tried to put the unit into standby. It told me "Power will turn off after deleting file." I waited a little longer, then started to worry. I checked the media listing again. Disk usage was down from 85% (when I had asked it to delete one SP 30-minute recording) to 74%. That's over 200GB of recordings that had apparently disappeared.

I telnetted in and rebooted. The unit went into standby, but not into power-saving mode, as though a recording were in progress. I powered on and checked. No recordings were taking place. I tried to put it into standby. "Power will turn off after deleting file." Aauugghh!!

I tried various combinations of reboot, power off, hard power off, pulling the power plug completely, reflashing the firmware with a USB stick, but after every attempt the Foxsat would power up and just carry on deleting. I lost another 40GB or so in those experiments.

I've left it powered off, and won't touch it until I get home from work tonight. The only other thing I can think to try is to reflash its firmware back to the Humax default, but if that cures things it places an unfortunate "post hoc propter hoc" question mark for Raydon. I'd rather find a cure that identifies the cause for certain.

Any suggestions? Anyone ever seen (or heard of) the like?
 
Sorry I can't help, but if you want to keep the recordings get the drive out and copy the contents to your PC before turning the Foxsat back on.
 
Check that in the HDR setup you do not have the option set to automatically delete files. (Which should only do anything when your disk is nearly full)
Did you install the housekepper utility? I guess not, as I am sure you would remember.
The power cycle was a good idea.
 
Sorry I can't help, but if you want to keep the recordings get the drive out and copy the contents to your PC before turning the Foxsat back on.
OMG!! Sorry to hear about this. I'm not over-familiar with Linux stuff but I hope a disk utility out there may be able to recover the deleted files, too?

Best of Luck!
 
Getting back the deleted files is not something I'm so worried about - they're just things I hadn't got around to seeing or listening to, nothing I'd miss (or that won't be repeated, eventually). I'd back up the disk if I had a spare 1.5TB of storage, but I don't. I'll cope without for now, see if anyone can think of anything.
 
Disconnect the HDD, does the box boot normally (it will report the the lack of access to the HDD) It should do so but should otherwise function as a non recording freesat-HD box. This should at least allow you to reflash the firmware.
 
Thanks, Graham. As stated, I'd sooner find the cause than a cure in the first instance, in case it's something that needs to be addressed by Humax, by Raydon and his co-geniuses, by the makers of Mongoose, or who knows who else. I don't have a spare "U"-spec SATA drive (the 2TB upgrade was because the original disk in the unit was on its way out). Plenty of IDE ones, but that doesn't help. I may have to order a spare online, but that's not going to arrive in a hurry. Once it does I can plug it in, and see if the urge to delete everything in sight remains.

I suppose I could also pull the existing drive and see if it's got something daft sitting in an INI of CFG file somewhere. I certainly hadn't set auto-delete or housekeeping, Repassac. Auto-delete may have enabled itself somehow, but as you say, that shouldn't kick in at 85% (unless the 2TB drive has severely confused its algorithm).

I shall try to check these things.
 
I tried various combinations of reboot, power off, hard power off, pulling the power plug completely, reflashing the firmware with a USB stick, but after every attempt the Foxsat would power up and just carry on deleting. I lost another 40GB or so in those experiments.
Did you actually succeed in reflashing the firmware ?
If you can still telnet in, you can stop all of the custom apps using the 'service' command. Use 'service' on its own to list what is running, then stop whatever else i.e. 'service stop mongoose'. I would suggest you leave telnet running or you will completely lock yourself out.
I've left it powered off, and won't touch it until I get home from work tonight. The only other thing I can think to try is to reflash its firmware back to the Humax default, but if that cures things it places an unfortunate "post hoc propter hoc" question mark for Raydon. I'd rather find a cure that identifies the cause for certain.
And did you try this in order to exclude the CFW from the list of possible causes ?
 
It went through its on-screen count (10-20-30 etc.), but did it quickly, so may not have re-applied the update.

I stopped the services other than mongoose and telnet using mongoose's interface, and set them all not to auto-start other than telnet. I think I restarted, and that it had no effect, but it was getting late. The box remains off to see if anything occurs to anyone. If not, I'm thinking of ordering a new drive (can't really justify the cost, and not sure whether just to get an external drive rather than a dedicated AV-spec one), so may back-up first, but I'll power it on, see if continues to delete (and I'll check the service statuses), and if it does, flash back to stock, see what happens.

Are there any diagnostics or backups you want me to take before I do? I can't do the whole drive, but could take a snapshot of /opt, /etc or anything else you will want to check if the deletion stops? It may well not, of course. I just want to be ready either way.
 
It went through its on-screen count (10-20-30 etc.), but did it quickly, so may not have re-applied the update.
Reflashing over the same firmware has that effect. It goes very quickly as nothing is being changed. Only when there are differences does it take more time.
......but I'll power it on, see if continues to delete (and I'll check the service statuses), and if it does, flash back to stock, see what happens.
Agree, reflashing back to stock will eliminate the custom firmware from the equation.
Are there any diagnostics or backups you want me to take before I do? I can't do the whole drive, but could take a snapshot of /opt, /etc or anything else you will want to check if the deletion stops? It may well not, of course. I just want to be ready either way.
To be honest, I can't see the custom firmware being the source of your problem. There's nothing in it that would delete a recording apart from the housekeeper utility, and you don't even have that installed. One possibility could be corruption of the hard disk. Regardless, there's no harm in taking a snapshot of the /opt directory before you reflash stock. Also a 'ps' command from telnet will display the full process list, which could be useful.
 
OK, I'll grab those before doing anything else, and report back.

But, if anyone else wants to throw more ideas into the pot, please do. I'd just as soon rescue my recordings if I can.
 
Back in April, I thought I had a 60 minute recording but is was actually a 24 hour recording.

It occupied 266GB of my 2TB drive. This was an aberation in the middle of a series I was recording through the series link. For details see my earlier message Humax FOXSAT-HDR Freeesat+ Owners thread Part 3 #399

It was not obvious to me from the HDR media listing.

I noticed it while trying to skip through the adverts but my usual 4 forward jumps took it into the next program rather than through the advertising break. Is it possible that a similar thing has happened here and it is a single very large recording that is being deleted?

I know it's extremely unlikely but could the HDR firmware/busybox not waiting to delete the whole file before returning blocks of storage and resuming the deletion after a reboot?

[I deleted the file from my PC using XP through a samba connection I knew it would take a long time and left it running when I was out of the house so I've no idea how long it took.]
 
Last edited:
Don't think it was that, Murray, but I've got the drive attached to a PC now, so I can have a look.

But here's a thing! A file in /Recording Sched called "deletefile.info" (zipped and attached) that refers to the file I was trying to delete. Does anyone have that file in that partition in their Foxsat HDR? If not, I shall delete it and see if the madness stops. If they have (in other words it refers to the current or previous deletion), then I need to concentrate on backing up.
 

Attachments

  • deletefile_info.zip
    181 bytes · Views: 57
Don't think it was that, Murray, but I've got the drive attached to a PC now, so I can have a look.

But here's a thing! A file in /Recording Sched called "deletefile.info" (zipped and attached) that refers to the file I was trying to delete. Does anyone have that file in that partition in their Foxsat HDR? If not, I shall delete it and see if the madness stops. If they have (in other words it refers to the current or previous deletion), then I need to concentrate on backing up.

Don't have the folder or the file - It might be created when a delete is in progress and removed when complete - let us know if it solves your problem or not.
 
The file is in the same location as "reserve.info", which is the file that holds the recording schedule. Does everyone else have the "reserve.info" only, with no other file in the same place?
 
The file is in the same location as "reserve.info", which is the file that holds the recording schedule. Does everyone else have the "reserve.info" only, with no other file in the same place?
Assume we're talking folder /mnt/hd1, and in there I've only ever seen the file reserve.info with the recording schedules.
 
Does the file /mnt/hd3/Video/Top of the Pops_ 1976/ as listed in deletefile.info still exist and if so what size is it ?
 
I'm not defeated yet! (Nor, rest assured, am I doing anything other than keeping an open mind on the possible cause, and trying my best not to destroy any forensics.)

So, here's my "Recording Sched" partition (I won't call it /mnt/hd1 because it's /dev/sdb1 when attached externally via USB on my Ubuntu box):
Code:
total 745
drwxr-xr-x 2 root root   4096 2011-11-24 23:19 .
drwxr-xr-x 8 root root   1024 2011-11-27 13:05 ..
-rw-r--r-- 1 root root    510 2011-11-24 23:19 deletefile.info
-rw-r--r-- 1 root root 745920 2011-11-25 00:15 reserve.info
Here's my TOTP1976 directory in /Video (wherever it's mounted):
Code:
total 2146756
drwxr-xr-x   2 root root       4096 2011-11-24 22:56 .
drwxr-xr-x 107 root root      12288 2011-11-24 23:20 ..
-rw-r--r--   1 root root       5476 2011-11-24 23:19 Top of the Pops_ 1976_20111124_1930.hmt
-rw-r--r--   1 root root    1438720 2011-11-24 20:00 Top of the Pops_ 1976_20111124_1930.nts
-rw-r--r--   1 root root 1154951424 2011-11-24 20:00 Top of the Pops_ 1976_20111124_1930.ts
-rw-r--r--   1 root root       4788 2011-11-24 23:23 Top of the Pops_ 1976_20111124_2256.hmt
-rw-r--r--   1 root root    1312896 2011-11-24 23:23 Top of the Pops_ 1976_20111124_2256.nts
-rw-r--r--   1 root root 1038369024 2011-11-24 23:23 Top of the Pops_ 1976_20111124_2256.ts
Looks like everything is still there. :confused:

I've had a quick look through, and although DF indicates that many files have disappeared, I can't at first glance see which ones they are. I'll manually add up all the files sizes from a recursive "ls -la" and see whether there's a discrepancy between the directory entries and the inodes (I guess - I'm not a Linux filesystem guru) that means my files are either there, but claiming not to be, or vice versa.

More soon.
 
I've looked through the filesystem, and while it's hard to notice what's missing in among everything that isn't, I really can't see anything that's glaringly absent.

I've renamed "deletefile.info" (to "nodeletefile.info"), and I'm going to plug it all back in and see what happens.
 
It switched on, didn't show any signs of deleting anything, and went into standby without hesitation. Phew!

I won't post anything else for a while - I have a whole lot of diagnostics and checks to run.
 
I can't see anything missing. :eek:

I checked the box out. It did indeed come up with only the telnet service enabled. I watched a recording, deleted that recording, made another, all seems well. I deleted the TOTP1976 directory and contents via telnet. I wasn't risking anything !

Before removing the drive from my Linux box I did an fsck on all four partitions. All four came up clean. I didn't want to force a check (even though fear of discovering data loss doesn't prevent data loss having happened).

I have a theory, in two parts, to explain what's just happened.

Firstly, I think the fact that the box came up repeatedly saying that it was deleting a file might be because it creates a file to indicate it is doing a deletion. The presence of this file is the trigger for the on-screen waste-basket logo and the power-off-delayed message, and if the file gets left behind when the deleting process terminates, the box will show the logo and message even if it's not actually deleting anything. The file is removed by the deletion process, and the deletion process won't start unless there's no file. Therefore the process is liable to deadlock.

I tried to test this. Pop a file in place and see if the message appears. Dump it again and see if the message goes. It looks like the file may need to be valid and to refer to existing files, though, as simply catting a blank line into an appropriately named file didn't do anything the Humax ignored this.

I'll try copying a recording to external storage, deleting it and copying the .info file created by the process, then copying back both media files and .info file, see if it causes the Humax any headaches.

Secondly, I think that I may not have lost any files. I think that, in spite of my having been very careful not to power the Humax box off, it still managed to accumulate some disk errors, and when I went to delete the Top of the Pops it decided to fix them. It recovered (or restored access to) 200GB of disk space (that's, what, 30-odd hours of HD recording?) through some fsck process, triggered by the request to delete the recording, and because I panicked and switched it off before it had finished I got back the disk space but got left with the deletion flag.

This is a silly notion. How can I have lost 10% of my hard disk without just powering it down every day? Could I somehow have stranded a dozen or more 18GB 0.ts files, scattering their bytes to the four corners of my hard disk, only to be recovered when I least expected it?

I dunno. In a sense I hope never to find out, because I never want to see my disk space freed in quite that way ever again, whether it resulted from or in data loss or not. I'd be happy if someone else did the research on this one. :rolleyes:
 
I have lost recordings. A lot of fillums I was waiting for a "round tuit" to watch, such as Danny Boyle's "Sunshine", have gone. I had them in a manually created directory tree, and it seems as though the Humax was nibbling away at that. The "/Video/Fillums/SF & Fantasy" directory is a bit of a mess.
Code:
Foxsat-HDR/mnt/hd3/Video/Fillums# ls -la "SF & Fantasy"
total 19408516
drwxr-xr-x    4 root     root           4096 Nov 24 23:48 .
drwxr-xr-x    8 root     root          20480 Nov 24 23:37 ..
drwxr-xr-x    2 root     root           4096 May 30 03:02 .Equilibrium_20110530_0010
drwxr-xr-x    2 root     root           4096 Aug 18 03:02 .Twilight_20110817_1959
-rw-r--r--    1 root     root     2535331776 Apr 14  2011 Destination Moon_20110414_1220.ts
-rw-r--r--    1 root     root     2774640576 May 30 02:05 Equilibrium_20110530_0010.ts
-rw-r--r--    1 root     root        5759104 May  9  2011 First Men in the Moon_20110509_1235.nts
-rw-r--r--    1 root     root     2968339200 May  9  2011 First Men in the Moon_20110509_1235.ts
-rw-r--r--    1 root     root     5902522368 Nov 25 00:15 King Arthur_20110730_2201.ts
-rw-r--r--    1 root     root     2146575360 Aug  7 02:11 Saturn 3_20110807_0047.ts
-rw-r--r--    1 root     root           5258 Jul 27 13:53 Stardust_20100313_1900.hmt
-rw-r--r--    1 root     root     3494760384 Apr  6  2011 Stardust_20100313_1900.ts
-rw-r--r--    1 root     root       26885312 Aug 17 22:20 Twilight_20110817_1959.nts
I can rescue the .ts files, but the Humax only shows Stardust in its file listing.

At the risk of being told off for swearing...Oh bugger! :(
 
Last edited:
Hi Jellyroll, thanks for the report out. Have had a go at replicating:

Firstly, I think the fact that the box came up repeatedly saying that it was deleting a file might be because it creates a file to indicate it is doing a deletion. The presence of this file is the trigger for the on-screen waste-basket logo and the power-off-delayed message, and if the file gets left behind when the deleting process terminates, the box will show the logo and message even if it's not actually deleting anything. The file is removed by the deletion process, and the deletion process won't start unless there's no file. Therefore the process is liable to deadlock.
I can confirm this - I just manually deleted a file using HDR remote, and while the trashcan was still at the top of the screen, a file /mnt/hd1/delete.info was present. Similar format to what you had, and for me contained the absolute path of the folder, plus the absolute paths to each of the .ts, .nts and .hmt files. Once the HDR had completed the delete this file was also deleted.

I tried to test this. Pop a file in place and see if the message appears. Dump it again and see if the message goes. It looks like the file may need to be valid and to refer to existing files, though, as simply catting a blank line into an appropriately named file didn't do anything the Humax ignored this.

I'll try copying a recording to external storage, deleting it and copying the .info file created by the process, then copying back both media files and .info file, see if it causes the Humax any headaches.
Had a go at this albeit with internal HDD; results as follows:

  • Copied my original recording back to HDR incl. nts/hmt and thumbnail folder.
  • FTPed the previously created delete.info to /mnt/hd1. No impact, even though the files reference in delete.info did exist on the HDR's HDD.
  • Put the HDR into standby with remote. Didn't stop me by saying it was deleting a file.
  • Restarted HDR from standby with remote. Screen came up including animated trashcan icon as though files were being deleted.
  • Trashcan icon disappeared after a few seconds and the files had at least been deleted (at least the ts/mts/hmt; the thumbnail folder was still there).
  • Looked in /mnt/hd1 and the file delete.info was no longer there.
I then tried to replicate what you had, ie. copied back a delete.info into /mnt/hd1 without the referenced recording files existing on the HDR:

  • Firstly then tried to delete another recording to see if the HDR checked for existence of delete.info. No impact, ie. the other recording was deleted as normal (assuming that delete.info was overwritten in the process; didn't check). Afterwards delete.info was deleted by the HDR.
  • So manually copied back my original delete.info and put HDR into standby with remote.
  • Started up HDR again from remote. No trashcan symbol on on-screen display. Checked /mnt/hd1 and delete.info had been removed by HDR.
Based on this I would conclude the following:

  1. When deleting a recording via on-screen display, the HDR creates a file /mnt/hd1/delete.info containing the paths to the ts/hmt/nts files to be deleted. When the recording deletion is complete then delete.info is removed.
  2. If /mnt/hd1/delete.info exists when the HDR starts up, it checks for existence of the files contained in delete.info. If these exist then they are removed and then delete.info is also removed. If they don't exist then delete.info is removed anyway.
.....so if this is the design behaviour then seems pretty robust to me.

Sounds like you indeed had some kind of problem with your HDD (I'm not an expert here) which messed up the HDR's internal logic around this in the settop binary?

Agree that if this would reoccur then a safe attempt to get out of jail is to remove /mnt/hd1/delete.info. Easy to do via telnet/ftp if the custom firmware is installed. Otherwise the internal HDD needs to be removed from the HDR and mounted to a different computer.
 
Hi jellyroll,
in one of your posts you say
I have lost recordings. A lot of fillums I was waiting for a "round tuit" to watch, such as Danny Boyle's "Sunshine", have gone. I had them in a manually created directory tree, and it seems as though the Humax was nibbling away at that. The "/Video/Fillums/SF & Fantasy" directory is a bit of a mess.
It may not mean anything of course but your directory has "SF & Fantasy" now if the Hummy on screen display gets it knickers in a twist it may be the "&" that is causing it some problems. The & in unix/linux if not quoted will instruct the shell to put the command into background, normal job control.
eg if you enter ls -la SF & Fantasy without quotes the command ls -la SF will go to background eg
ls -al SF & Fantasy
ls: SF: No such file or directory
/bin/sh: Fantasy: not found
[1] + Done(1) ls -al SF

It may be just possible that the built in stuff is doing similar???

Edited:
I also would point out it may be that the software "might" just escape blanks e.g. using ls -la SF\ &\ Fantasy which has the same effect. Just speculating of course :devil:
 
Last edited:

The latest video from AVForums

TV Buying Guide - Which TV Is Best For You?
Subscribe to our YouTube channel
Back
Top Bottom