Pause, record & playback / storage setting stop!

My Humax Forum » Freeview HD » FVP 4000T, 5000T

Pause, record & playback / storage setting stop!

(30 posts)

grahamlthompson

special member
Joined: Feb '11
Posts: 14,442
offline

Martin Liddle - 3 minutes ago »

grahamlthompson - 46 minutes ago »
Unlike windows Linux FS deletions take longer because the actual recording data is removed.

Can you provide any evidence for that claim? I think you will find the data is still on the hard drive and the slowness is due to the inefficiency of the Ext2/Ext3 file system when dealing with large files.

The Foxsat can take up to 30 mins or more to shutdown if the power button is pressed when a lot of recordings are set to delete.

During this period the Web Interface remains active.

Otherwise if no recordings due it goes into sby almost immediately.

There is no undelete capability either unless the recordings are temporarily copied to a buffer area.

| Thu 25 Apr 2019 14:24:43 #21 |
A1944

special member
Joined: Dec '17
Posts: 1,003
offline

wellnevermind - 32 minutes ago »

A1944 - 23 minutes ago »
Curiously, I tried going to System Settings and attempting to update online from there and it worked first time - no USB stick in sight (in fact I don't even own one!).
Took about 5-10 minutes in all to download, install and restart. As usual when restarting, it initially said that the box contained no recordings, but they soon reappeared.

Was your unit in need of the update? It was already working fine or did you have the same issues as me? Maybe the issue that caused mine to need the update to work properly also caused the auto/online updating not to work?

No, mine was not having any obvious issues, but having not done the previous update, when I heard there was another I thought it was time to give it a go. I am, by the way, using a 5000T.

| Thu 25 Apr 2019 14:30:58 #22 |
wellnevermind

member
Joined: Apr '19
Posts: 12
offline

Regarding Linux, it is my understanding files can be recovered just like they can in Windows, minus the bin

Foremost command I think?

| Thu 25 Apr 2019 14:40:56 #23 |
grahamlthompson

special member
Joined: Feb '11
Posts: 14,442
offline

wellnevermind - 2 minutes ago »
Regarding Linux, it is my understanding files can be recovered just like they can in Windows, minus the bin
Foremost command I think?

https://linuxize.com/post/how-to-remove-files-and-directories-using-linux-command-line/

Be extra careful when removing files or directories with the rm command, because once the file is deleted it cannot be recovered.

| Thu 25 Apr 2019 14:43:47 #24 |
wellnevermind

member
Joined: Apr '19
Posts: 12
offline

grahamlthompson - 4 minutes ago »

wellnevermind - 2 minutes ago »
Regarding Linux, it is my understanding files can be recovered just like they can in Windows, minus the bin
Foremost command I think?

https://linuxize.com/post/how-to-remove-files-and-directories-using-linux-command-line/

Be extra careful when removing files or directories with the rm command, because once the file is deleted it cannot be recovered.

https://linuxtechlab.com/restore-deleted-files-linux-with-foremost/

Note:- We can only restore deleted files in Linux as long as those sectors have not been overwritten on the hard disk.

They say things like be very careful before you delete files on Windows also, and claim you cannot get them back once you do. But it is generally not true, they are just playing it safe.

The fact is, unless you overwrite and overwrite and overwrite files on a disk multiple times (and even then it can be possible to get them back). Or compeltely destroy the disk. It can be possible to recover files.

| Thu 25 Apr 2019 14:49:06 #25 |
wellnevermind

member
Joined: Apr '19
Posts: 12
offline

https://www.computerhope.com/unix/urm.htm

The removal process unlinks a file name in a filesystem from its associated data, and marks that space on the storage device as usable by future writes. In other words, when you remove a file, the data in the file isn't changed, but it's no longer associated with a filename.

The data itself is not destroyed, but after being unlinked with rm, it becomes inaccessible.

Note: If you want is to completely wipe the data on the disk, use the shred command instead. shred will overwrite the file's contents so that they cannot be reconstructed later.

| Thu 25 Apr 2019 15:05:46 #26 |
grahamlthompson

special member
Joined: Feb '11
Posts: 14,442
offline

wellnevermind - 9 minutes ago »
https://www.computerhope.com/unix/urm.htm
The removal process unlinks a file name in a filesystem from its associated data, and marks that space on the storage device as usable by future writes. In other words, when you remove a file, the data in the file isn't changed, but it's no longer associated with a filename.
The data itself is not destroyed, but after being unlinked with rm, it becomes inaccessible.

Note: If you want is to completely wipe the data on the disk, use the shred command instead. shred will overwrite the file's contents so that they cannot be reconstructed later.

If it's merely unlinking the data, why does it take a very long time to process a set of recording deletions set up from the Foxsat-HDR File manager option ?

When you press the power button you get a message saying the box will go to sby when the deletions are processed.

With a lot of recordings I have seen it take up to an hour when cleaning out a 1TB drive.

This link says the data is unrecoverable even when using RM

https://unix.stackexchange.com/questions/10883/where-do-files-go-when-the-rm-command-is-issued

Nowhere, gone, vanished. Well, more specifically, the file gets unlinked. The data is still sitting there on disk, but the link to it is removed. It used to be possible to retrieve the data, but nowadays the metadata is cleared and nothing's recoverable.

So there is no file recovery at all.

So is post 23 accurate or just plain wrong ?

The custom firmware for the HDR-FOX-T2 does give a undelete option, but it presumably merely moves the files to a seperate area of the hard drive and presumably the undelete moves them back again.

| Thu 25 Apr 2019 15:21:18 #27 |
wellnevermind

member
Joined: Apr '19
Posts: 12
offline

Why these Humax units are slow doing things is a different question in my mind. I don't believe it is to do with the operating system as such, but more the processing power and speed of parts used in the units.

The very fact that you can get a custom firmware that gives an undelete function is proof that the files are not actually deleted, but only reference to them.

Files are not moved, only reference to them is deleted or changed. Unless you run a disk defrag to move files on purpose.

There is a difference between saying to a normal user data is not recoverable and saying it to say a proper techie.

Imagine a jigsaw puzzle, that you destroy the guide image for. The jigsaw is the file and the guide image is the reference that you destroyed using the rm command. True it would be a nightmare to get that jigsaw back together with no guide image, but not impossible. And if parts of the jigsaw are still in logical order, as would be parts of a file on a hard disk. Then it might not be as hard as you think, and if you are using software to automate that recovery, then not very hard at all.

| Thu 25 Apr 2019 15:58:05 #28 |
grahamlthompson

special member
Joined: Feb '11
Posts: 14,442
offline

As it happened I cleared out around 1TB of recordings this morning from my HDR-1000S which has a 2TB drive. Unlike the 5000T the UI is pretty responsive. It took ages for the recovered disk space to indicate the recovered recording space. If it is only deleting a few bytes of data why so long ?

| Thu 25 Apr 2019 16:07:26 #29 |
Martin Liddle

special member
Joined: Feb '11
Posts: 4,685
offline

grahamlthompson - 45 minutes ago »
If it's merely unlinking the data, why does it take a very long time to process a set of recording deletions set up from the Foxsat-HDR File manager option ?

The pointers to the actual data locations are held in inodes and the way Humax format the hard drive results in a lot of inodes. Manually formatting the hard drive with much fewer inodes should result in better deletion performance.

. The data is still sitting there on disk, but the link to it is removed.

There are tools to attempt to recover the data but how successful they might be will depend on a number of factors.

So is post 23 accurate or just plain wrong ?

Accurate.

| Thu 25 Apr 2019 16:14:37 #30 |