Who moved my recordings?

Pixel Eyes

Member
I have just noticed that the entire contents of one directory (some 34 recordings) has been moved to another one. I don't think any other files are affected.

Why would this happen and should I be concerned that it is an early warning of more problems to come?

Custom firmware version: 3.10 (build 2734)
Humax Version: 1.03.12 (kernel HDR_CFW_3.10)
Loader Version: a7.30
 
Thanks for the suggestion Luke. It's not Sweeper.

I can't imagine that it would have any effect, but yesterday I changed the setting for Detectads from traditional to chaserun. However, the recordings were all made and processed some time ago so really I am clutching at straws.
 
Sorry if my response appeared dismissive of your suggestion, Luke! I did carefully consider the only two Sweeper rules I had in place:

The first, applied to the whole My Video directory, was one I had actually forgotten about. A silly experiment when I first installed Sweeper:

Code:
# Dummy rule
or {lcn 11 lcn 135 } action {settitle {How do they make it?}}
# Dummy rule 2
lastrule "" action {renamefile How_do_they_make_it_}
# Dummy rule 3
lastrule "" action lock
# Dummy rule 4
lastrule "" action {move Nerdy}

The second, applied to the Coronation Street directory:

Code:
# rename
!filename y action {renamefile {%title - %hhmm %longday %date %shortmonth %year}}
# rename2
!title y action {settitle {%title - %longday}}

(Actually, this rule has not been working for some time, for a reason which I can't fathom.) I have just now removed the Sweeper package altogether.

The recordings which appear to have spontaneously relocated were all movies, recorded from various channels (but none from lcn 11 or lcn 135) in a directory called Films. They now show in a directory called Barry's Lunch Club with BBC Radio 4 recordings of the same name. The Films directory now contains 0 files.

To my eye, it doesn't look like Sweeper is the cause of the sudden file move. I can't think of anything other that the Detectads change I mentioned, or some corruption of the database perhaps caused by a failing HDD.
 
I ran fix-disk and got this:

Code:
Running /bin/fix-disk
Custom firmware version 3.10


Checking disk sda (512 byte sectors)

Unmounted /dev/sda1
Unmounted /dev/sda2
Unmounted /dev/sda3


Running short disk self test

No pending sectors found - skipping sector repair

Checking partition tables...

MBR Status: MBR only
GPT Status: not present

Using superblock 0 on sda1
Using superblock 0 on sda2
Using superblock 0 on sda3


Checking partition /dev/sda3...
e2fsck 1.42.13 (17-May-2015)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda3: 17/655776 files (0.0% non-contiguous), 203879/2622611 blocks

Checking partition /dev/sda1...
e2fsck 1.42.13 (17-May-2015)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda1: 15/65808 files (6.7% non-contiguous), 15463/263064 blocks

Creating swap file...
Setting up swapspace version 1, size = 1073737728 bytes
UUID=e2618122-629f-4a44-a27b-8b9cccdcadfc

Checking partition /dev/sda2...
e2fsck 1.42.13 (17-May-2015)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/sda2: 9060/29860704 files (14.7% non-contiguous), 103929162/119209984 block                                             s
Removing extra swap space.
Are you having problems with a delete loop? [Y/N]: n
Skipped

Finished

Is there anything there which I should be concerned about?
 
Back
Top