• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
  • The forum software that supports hummy.tv has been upgraded to XenForo 2.0!

    This is a major upgrade which changes the look and feel of the forum somewhat but brings a host of improvements too. Please bear with us as we continue to tweak things and report any issues or suggestions in Site/Forum Issues.

Undelete does not delete

#1
I've had Undelete installed for several weeks now with the expiry time set to 10 days. "Deleted" items are correctly transferred to the [Deleted Items] folder but they are never permanently deleted. I've tried changing to the default 7 day expiry and I've re-installed Undelete (twice). Here is the latest humaxtv.log:
>>> Contents of /var/log/humaxtv.log 1.52 KiB
-------------------------------------
Initialising Dustbin v1.0
Dustbin debug: 0
Dustbin media root: /mnt/hd2/My Video/
Dustbin path: /mnt/hd2/My Video/[Deleted Items]
-------------------------------------
route: SIOCADDRT: File exists
killall: tinyftp: no process killed
DRV_DSC_Init_Begin
SIOCDELRT failed , ret->-1

GALIO STARTING
./humaxtv --alt-config /usr/browser/config-ocontroller-si-rootfs.txt --config /var/lib/humaxtv/galio-config.txt
User opts: None
OCON | initialising controller
Restore reminders from file failed
Persist reminders to file failed
mom_mda_package_list_handle_event: event 16 list @3c9e38bc pkg reason MDA_OK
IP Address List: 192.168.1.104
mxDLNA [DLNA DMS DmsRunThread] Start (PID:178 TID:1068274896).......
[mxDlnaFileScanner_create] +++++
[mxDlnaFileScanner_addDirectory] SEARCH_LIST_PATH_EXACT_MATCHED
[mxDlnaFileScanner_create] -----
[mxDlnaFileScanner_addDirectory] SEARCH_LIST_PATH_EXACT_MATCHED
[mxDlnaFileScanner_addDirectory] SEARCH_LIST_PATH_EXACT_MATCHED
[mxDlnaFileScanner_addDirectory] SEARCH_LIST_PATH_EXACT_MATCHED
[ifss_start] +++++
mom_mda_package_list_handle_event: event 16 list @3c9e38bc pkg reason MDA_OK
mom_mda_package_list_handle_event: event 16 list @3c9e38bc pkg reason MDA_OK
MEM: used heap 4692528/4702200 flex 820440/25165824
mom_mda_package_list_handle_event: event 16 list @3c9e38bc pkg reason MDA_OK
mom_mda_package_list_handle_event: event 16 list @3c9e38bc pkg reason MDA_OK
mom_mda_package_list_handle_event: event 16 list @3c9e38bc pkg reason MDA_OK

Any ideas anyone?

Thanks
 

af123

Administrator
Staff member
#2
By default the undelete bin emptying process only runs once per day, on the first boot of the day or just after midnight if the box is left on. For most people that's the OTA search boot at 4:30am and the box is up for long enough for undelete to do its thing.

On odd occasions, if you have a lot in the bin, then it won't get through the backlog before the box shuts down again and it can get into the situation where it cannot clear the files as fast as they're aging. The other thing that can cause problems is if you have a very short wake up/sleep period in the early hours of the morning. The emptying doesn't start until the box has been up for 6 minutes so if you have a 10 minute period then it only has four minutes to run through the bin.
 
OP
OP
M

MalcolmC

New Member
#3
By default the undelete bin emptying process only runs once per day, on the first boot of the day or just after midnight if the box is left on. For most people that's the OTA search boot at 4:30am and the box is up for long enough for undelete to do its thing.

On odd occasions, if you have a lot in the bin, then it won't get through the backlog before the box shuts down again and it can get into the situation where it cannot clear the files as fast as they're aging. The other thing that can cause problems is if you have a very short wake up/sleep period in the early hours of the morning. The emptying doesn't start until the box has been up for 6 minutes so if you have a 10 minute period then it only has four minutes to run through the bin.
Thanks for that. My first boot as at 4:15 am for 30 minutes. I would have thought that would be enough, but I'll try setting it to something very long to see if that helps.
 

af123

Administrator
Staff member
#4
Yes, that should be long enough already. If you want to run the process by hand to see if it is encountering errors, try running the dustbin/empty diagnostic and see what comes up on the screen.
 

Ezra Pound

Well-Known Member
#5
af123 could you remind me about the humaxtv.log file, is this file always created and if not how is it enabled, as I used to have one but it has gone. Also dustbin/empty diagnostic seems to be bounced
EDIT
Sorry, just found a previous reference Here :- "f you touch the /var/lib/humaxtv/debugtv file then there will be a log in /tmp/humaxtv.log which might contain something relevant.."

But I still don't get a humaxtv.log file after two reboots
 

Ezra Pound

Well-Known Member
#7
I presumed the dustbin/empty would force an immediate 'empty' but it just seems to report on the settings e.g. :-

Code:
>>> Beginning diagnostic dustbin/empty
Running: dustbin/empty
Keeping deleted files for 1 day(s).
Dustbin: /mnt/hd2/My Video/[Deleted]
Processing dustbin... (0)
 
>>> Ending diagnostic dustbin/empty
Also, still no /tmp/humaxtv.log
 

Ezra Pound

Well-Known Member
#9
Yes, sorry I expected it to say 'Deleted XXX, YYY and ZZZ. It has correctly removed half of the files in the 'dustbin' e.g. the ones that were deleted more than an 1 Day ago. Any thoughts on the humaxtv.log?
 

xyz321

Well-Known Member
#10
af123 could you remind me about the humaxtv.log file, is this file always created and if not how is it enabled, as I used to have one but it has gone. Also dustbin/empty diagnostic seems to be bounced
EDIT
Sorry, just found a previous reference Here :- "f you touch the /var/lib/humaxtv/debugtv file then there will be a log in /tmp/humaxtv.log which might contain something relevant.."

But I still don't get a humaxtv.log file after two reboots
That should be: 'touch /var/lib/humaxtv/mod/debugtv'.
 

prpr

Well-Known Member
#11
af123,

I have edited my /mod/sbin/empty-dustbin file:
Code:
humax# diff -u empty_dustbin.old empty_dustbin
--- empty_dustbin.old
+++ empty_dustbin
@@ -2,12 +2,14 @@
 
export PATH=/mod/bin:/mod/usr/bin:/mod/bin/busybox:/bin:/sbin
 
+echo "Emptying dustbin at `date`"
conf=/mod/etc/undelete.conf
 
[ -f $conf ] && keep=`grep '^keep' $conf | awk '{print $2}'`
[ -z "$keep" ] && keep=7
 
-echo "Keeping deleted files for $((keep--)) day(s)."
+echo "Keeping deleted files for $keep day(s)."
+keep=$((keep*1440))
 
if [ "`cat /etc/model`" = HD ]; then
        mediaroot=/media/drive1/Video
@@ -30,9 +32,9 @@
 
echo "Processing dustbin... ($keep)"
 
-find . -type f -mtime +$keep -exec trm {} \; -print
-find . -type d -exec rmdir {} \; 2>>/dev/null
-find . -type d -exec rmdir {} \; 2>>/dev/null
+find . -type f -mmin +$keep -print -exec trm {} \;
+find . -type d -print -exec rmdir {} \;
+find . -type d -print -exec rmdir {} \;
 
# Remove any orphaned HMT files.
find . -type f -name \*.hmt | sed 's/\.hmt$//' | while read base; do
@@ -42,6 +44,6 @@
                rm -f "$base.hmt"
        fi
done
-
+echo "================================================"
exit 0
 
humax#
This seems to work better using -mmin instead of -mtime (which I don't really understand) and gets rid of that horrible post-decrement on $keep.
It also prints things in the correct order now.

I amended the relevant line in /mod/etc/anacrontab as follows:
1 6 empty_dustbin /mod/sbin/empty_dustbin >>/var/log/empty_dustbin.log 2>&1

It now logs nicely and is viewable in the Web-if. Perhaps you would consider modifying the official package?

BTW, anacron runs at 2am, not midnight, so empty-dustbin runs at 02:06.
 

Ezra Pound

Well-Known Member
#12
That should be: 'touch/var/lib/humaxtv/mod/debugtv'.
Thanks for that, I will try it out when the current recording has finished and I can carry out a reboot, I think this must have changed a few times, as I have found reference to 3 locations for the debugtv file to be created, I'm guessing no.3 is the current one e.g.

1) /var/lib/humaxtv/debugtv
2) /mod/boot/debugtv
3) /var/lib/humaxtv/mod/debugtv
 

af123

Administrator
Staff member
#14
I have edited my /mod/sbin/empty-dustbin file:
...
This seems to work better using -mmin instead of -mtime (which I don't really understand) and gets rid of that horrible post-decrement on $keep.
There should be no difference. -mtime just expects its argument in days whereas -mmin expects minutes. In the source code for busybox (findutils/find.c) one invokes:
time_t mtime_secs = ap->mtime_days * 24*60*60;
whereas the other does
time_t mmin_secs = ap->mmin_mins * 60;

What do you mean by better?

It also prints things in the correct order now.
What did the old one print in the wrong order?

I amended the relevant line in /mod/etc/anacrontab as follows:
1 6 empty_dustbin /mod/sbin/empty_dustbin >>/var/log/empty_dustbin.log 2>&1

It now logs nicely and is viewable in the Web-if. Perhaps you would consider modifying the official package?
I like the idea of adding logging. I will put the log under /mod/tmp though so that it is persistent between reboots and add automatic rotation.

BTW, anacron runs at 2am, not midnight, so empty-dustbin runs at 02:06.
Thanks - my mistake.
 

prpr

Well-Known Member
#16
There should be no difference. -mtime just expects its argument in days whereas -mmin expects minutes. In the source code for busybox (findutils/find.c) one invokes:
time_t mtime_secs = ap->mtime_days * 24*60*60;
whereas the other does
time_t mmin_secs = ap->mmin_mins * 60;

What do you mean by better?
I was running with $keep set to 1. Then you have that post-decrement of $keep which makes it into 0 as passed to find. Why was this done?
Then I read this about find:
-mtime n
File's data was last modified n*24 hours ago. See the comments for -atime to understand how rounding affects the interpretation of file modification times.

-atime n
File was last accessed n*24 hours ago. When find figures out how many 24-hour periods ago the file was last accessed, any fractional part is ignored, so to match -atime +1, a file has to have been accessed at least two days ago.
and decided that this was all much too clunky and unpredictable and it would be better operating in hours than days. I haven't looked at the source code, but perhaps this apparent 1 offset mentioned was the result for that decrement? Nasty stuff whatever.

What did the old one print in the wrong order?
When I removed the redirection to /dev/null from the attempts to delete the directories and added a -print like is done for files, then it printed the error message before the directory, which was confusing.
Even though trm doesn't apparently print anything, in general it seems sensible to put the -print before the -exec rather than after it.
 
OP
OP
M

MalcolmC

New Member
#17
Yes, that should be long enough already. If you want to run the process by hand to see if it is encountering errors, try running the dustbin/empty diagnostic and see what comes up on the screen.
Again, thanks. I ran the diagnostic repeatedly, starting at the longest "keep" time and working my way down. Nothing happened for 7 days or more (I'm pretty confident that there are files in there that were deleted more than a week ago). Unfortunately at this point I got impatient and jumped to 2 days. Then a lot of files were deleted. So I'll leave it at that setting and see what happens, then slowly increase the "keep" time back to the value I want to use. A good deal of my problem might simply be that with a 10 day keep time I had a lot of files in the bin and I can't remember when I actually "deleted" them! I'm now reassured to see that deleting does actually happen.
 
#18
A quick question about undelete. Since it doesn't actually delete things straight away I assume the disk usage stays the same when you select delete? (the only alternative I can see is if the HDR disk usage is just reporting the usage of the media subtree and the undelete area is outside that or something similar).
 

Ezra Pound

Well-Known Member
#19
Deleted files are moved to to an holding area and deleted from there 1 - 10 days later, so you shouldn't expect the disk usage to change while the files are still on the HDD because they are still taking up space