1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

Undelete does not delete

Discussion in 'HD/HDR-FOX T2 Customised Firmware' started by MalcolmC, Nov 20, 2012.

  1. MalcolmC

    MalcolmC New Member

    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
     
  2. af123

    af123 Administrator Staff Member

    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.
     
  3. MalcolmC

    MalcolmC New Member

    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.
     
  4. af123

    af123 Administrator Staff Member

    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.
     
  5. Ezra Pound

    Ezra Pound Well-Known Member

    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
     
  6. af123

    af123 Administrator Staff Member

    The diagnostic should work now.
     
  7. Ezra Pound

    Ezra Pound Well-Known Member

    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
     
  8. af123

    af123 Administrator Staff Member

    No, it just runs the standard empty process - so in your case deleting everything over a day old.
     
  9. Ezra Pound

    Ezra Pound Well-Known Member

    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?
     
  10. xyz321

    xyz321 Well-Known Member

    That should be: 'touch /var/lib/humaxtv/mod/debugtv'.
     
  11. prpr

    prpr Well-Known Member

    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.
     
  12. Ezra Pound

    Ezra Pound Well-Known Member

    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
     
  13. xyz321

    xyz321 Well-Known Member

    Either 2 or 3 should work since '/mod/boot' is a symlink to '/var/lib/humaxtv/mod'
     
    Ezra Pound likes this.
  14. af123

    af123 Administrator Staff Member

    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?

    What did the old one print in the wrong order?

    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.

    Thanks - my mistake.
     
  15. Ezra Pound

    Ezra Pound Well-Known Member

    Thanks xyz321, spot on, I can leave the notes in the WiKi (humaxtv.log) as they are then (No.2)
     
  16. prpr

    prpr Well-Known Member

    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:
    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.

    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.
     
  17. MalcolmC

    MalcolmC New Member

    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. cloud9

    cloud9 Member

    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).
     
  19. Ezra Pound

    Ezra Pound Well-Known Member

    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