Undelete / dustbin...

Status
Not open for further replies.
I think I have found the answer to my dustbin renaming issue. I have just deleted a test file, and now have a New dustbin folder named [Recycle Bin] which has just appeared, this was the name that I chose for it.:D

My original "_dustbin" folder was still there complete with its contents so I decided to move these deleted files to my [Recycle Bin] by selecting all and then moving them. This caused the box to reboot, but when I tried it again it worked. I then deleted my empty "_dustbin" folder, and tried deleting another recording which seems to have gone completely so I seem to have broken undelete by removing the _dustbin folder.:rolleyes:
 
I think that I have fixed it now by removing the undelete package and reinstalling it. Deleted files are now going into my [Recycle Bin] so all I need now is to see if they start to auto delete after 1 day.
 
I'm running a sweep on how long it will be before somebody complains their deleted recordings keep reappearing in the My Video folder!
 
I have just installed undelete on my other HDR, this was a very straight forward procedure, and worked first time.:) I can recommend this package, particularly to fellow Toppy owners who are running MyStuff, they will know why I have decided to change my dustbin name to [Recycle Bin].;)

P.S. I like the Dustbin symbol on the folder icon in webif Browse Media Files, it's a pity that we can't have one on the Humax native folder icon for the bin.
 
Setting a new name for the bin and then rebooting just leaves the old bin as normal folder - which you can manually delete (which will move it to the new bin) or move as you did. It shouldn't have crashed though; I'll have to do some more testing to see if I can reproduce that.

Brian's setup breaking is due to a feature in the beta undelete package. As a safeguard, I have made it disable itself if the Humax software crashes for any reason. I didn't want anyone to end up with a box in a loop where it crashes as soon as it boots. That will change for the release.

I'm going to change the default name of the dustbin to [Deleted Items] but still retain the option for people to choose their own name.
 
af123 said:
Setting a new name for the bin and then rebooting just leaves the old bin as normal folder - which you can manually delete (which will move it to the new bin) or move as you did. It shouldn't have crashed though; I'll have to do some more testing to see if I can reproduce that.

Brian's setup breaking is due to a feature in the beta undelete package. As a safeguard, I have made it disable itself if the Humax software crashes for any reason. I didn't want anyone to end up with a box in a loop where it crashes as soon as it boots. That will change for the release.

I'm going to change the default name of the dustbin to [Deleted Items] but still retain the option for people to choose their own name.
Click to expand...
It was strange that after creating the new bin it worked straight away, but after deleting the old bin, the new bin no longer worked.:confused: When the box crashed whilst trying to move files from the old to new bins, I was moving about 20 GiB of files. This move worked after the box had rebooted, so may be hard to reproduce.

I quite like the name [Deleted Items] although I will stick with [Recycle Bin] myself.:D
 
After switching on this morning, I checked my [Recycle Bin] to see if anything had been auto deleted, but it was still indicating 14 files, the same as yesterday. On opening the folder, I saw that 5 of the files dated 12/01 had lost their thumbnails and were replaced by a grey image of 2 frames of film angled on a grey background. When selected to play they come up with "Recording failed: unknown error.".

When viewed in webif Browse Media Files, the 5 files have a grey icon with lightning flash, and looking at the file names, they are ".hmt" files.

A further check via FileZilla shows that for each of the 5 recordings, the ".nts", ".thm", & ".ts" files have been deleted, but Not the ".hmt" files.

FileZilla shows that the ".hmt" files were last modified on 15/01/2012 at 02:54:00 AM, whilst I was in bed, and my box was left recording a film in standby, which according to webif Media Details, finished at 02:53:37 AM, could this have something to do with it?

Hopefully this is something that can be fixed easily.:)
 
It will certainly be possible to sort it out one way or another. When files are moved to the bin, theIr time stamps are updated to reflect the current time so, in theory, the four files that make up a recording should be removed together. Something seems to update the hmt files in the background though - perhaps the nightly thumbnail generator is involved? I have a few things in my bin now so I'll see what happens.
 
This morning, the remainder of the files in my bin have been removed, except for the 5 .hmt files mentioned earlier.
 
Yes, they are now dated 16/01/2012 1:37:00 AM, which is around the time that a film I was recording ended (Mon Jan 16 01:37:25 2012 GMT).
 
Version 0.5 of undelete should solve this. I'm still not sure why the HMT files are being touched every day, but this new version removes any orphaned HMT files from the bin regardless of age.

Same update process as before
Code: 
humax# opkg update
humax# diag upgrade_dustbin

This one also has a less sensitive crash protection mechanism.

This one is the release candidate!
 
af123 said:
I'm still not sure why the HMT files are being touched every day,
Click to expand...
I think it is the auto-unprotect startup script. It runs the unprotect script on all hmt files updated since the last reboot. The idea was to catch anything that was missed by the usual mechanism.
 
I've been having similar problem with left over hmt files. Some of the recordings are gone but some still remain but just as hmt files. I'll upgrade again when I get chance.
 
xyz321 said:
I think it is the auto-unprotect startup script. It runs the unprotect script on all hmt files updated since the last reboot. The idea was to catch anything that was missed by the usual mechanism.
Click to expand...

I thought the same, but the startup script should only modify files which are High Definition, although it does it regardless of whether it has anything to do (possible improvement there?).. Maybe that covers Brian's test recordings.

Either way, the new undelete will handle orphaned HMTs.
 
Probably shutting the door after the horse has bolted, but one answer might be to look at the timestamp on <filename>.ts only, and then delete <filename>.*
 
af123 said:
I thought the same, but the startup script should only modify files which are High Definition, although it does it regardless of whether it has anything to do (possible improvement there?).. Maybe that covers Brian's test recordings.

Either way, the new undelete will handle orphaned HMTs.
Click to expand...
All of my files are HD, as I only have four HD channels tuned into my box.

I will update to the new version when I get home later.
 
I have updated to undelete 0.5, and have noticed a problem when deleting a film from my "noflatten" Film folder. I have 8 films in this folder (50.00 GiB), I deleted one of them (5.78 GiB) then checked my bin and was surprised to see that it contained a Films folder (5.8 GiB) containing the deleted film, was this created by the deletion process? I was even more surprised when I checked my Film folder containing my other 7 films, this was now showing as (5.8 GiB). Opening this folder showed 7 films remaining with a total size of (44.2 GiB) so something is wrong here.

I moved this film back to my Films folder which was now showing as (4.0 KiB), but when opened contains the 8 films with a total size of (50.0 GiB). Going back to my bin folder, it contains an empty Films folder showing as (4.0 KiB). If I delete this folder, and exit my bin I see that my Films folder is now showing as (50.0 GiB) again.

This can be repeated at will with the same results.

P.S. All of the folder sizes in brackets are as seen viewing the media files via the webif.
 
I wonder if this is just the webif getting mixed up between folders with the same name in different parts of the tree...
Yes, the folder structure is created by the deletion process, it duplicates the original tree into the bin.

I'll do some digging tomorrow and see what's going on, thanks.
 
Status
Not open for further replies.
Back
Top