[flatten] Automatically Removing Programmes from Series Folders

Code:
humax# crontab -l | hexdump -C
00000000  30 20 32 20 2a 20 2a 20  2a 20 2f 6d 6f 64 2f 73  |0 2 * * * /mod/s|
00000010  62 69 6e 2f 61 6e 61 63  72 6f 6e 20 2d 73 20 2d  |bin/anacron -s -|
00000020  64 0a 2a 2f 31 30 20 2a  20 2a 20 2a 20 2a 20 2f  |d.*/10 * * * * /|
00000030  6d 6f 64 2f 77 65 62 69  66 2f 6c 69 62 2f 62 69  |mod/webif/lib/bi|
00000040  6e 2f 61 75 74 6f 20 3e  2f 64 65 76 2f 6e 75 6c  |n/auto >/dev/nul|
00000050  6c 20 32 3e 26 31 0a 2a  2f 31 30 20 2a 20 2a 20  |l 2>&1.*/10 * * |
00000060  2a 20 2a 20 2f 6d 6f 64  2f 73 62 69 6e 2f 72 73  |* * /mod/sbin/rs|
00000070  5f 70 72 6f 63 65 73 73  20 3e 3e 20 2f 6d 6f 64  |_process >> /mod|
00000080  2f 74 6d 70 2f 72 73 2e  6c 6f 67 20 32 3e 26 31  |/tmp/rs.log 2>&1|
00000090  0a 2a 2f 31 35 20 2a 20  2a 20 2a 20 2a 20 2f 6d  |.*/15 * * * * /m|
000000a0  6f 64 2f 73 62 69 6e 2f  66 6c 61 74 74 65 6e 20  |od/sbin/flatten |
000000b0  3e 3e 20 2f 6d 6f 64 2f  74 6d 70 2f 66 6c 61 74  |>> /mod/tmp/flat|
000000c0  74 65 6e 2e 6c 6f 67 20  32 3e 26 31 0a           |ten.log 2>&1.|
000000cd
 
Mods: can we split the posts from #127 into a new topic: "[flatten] Problem - Installed but Not Running"
 
Mods: can we split the posts from #127 into a new topic: "[flatten] Problem - Installed but Not Running"
I don't see any point in moving these posts to a new thread, as they are on topic, and this is not a particularly large thread.
 
I guess it wouldn't be interesting if it were easy?
Nope : )
So you definitely don't see a flatten.log in the diagnostics page?
It seems that cron, which is the process responsible for starting jobs like this, isn't running properly for some reason. It /is/ running because there's a process ID against the first line of the diagnostic output but the flatten job isn't being kicked off.

From the command line, can you run it in debug mode?

Code:
humax# pkill crond
humax# /mod/sbin/crond -f -d8

should do it although I can't get onto my Humax to check at the moment.
 
Unfortunately I'm not able to get onto the Hummy either (unless there's a clever way to power it up remotely - I'm using LogMeIn to a PC at home, then Webif to the Hummy) but will try this tonight.

I'm starting to wonder if rs is working properly for me too - as I've not seen any recordings appear from the search function (I have a load of QI's it's found queued up at the top of the rs webpage in the "Queued commands" rather the "Scheduled events on the Humax" section. I've already got a couple of daily Wake-Ups scheduled and just put some test recordings in for today, tomorrow and Sunday - I'll let you know if any of these succeed or fail.

The last seen status is changing regularly - currently 2:05am today.

I appreciate this is the flatten thread - but I wonder if there's a more fundamental underlying problem affecting rs and flatten that I should be looking for?
 
Just ran the command - I'm not sure if it's finished, it's been about 30 mins since I started it?
Code:
humax# pkill crond
humax# /mod/sbin/crond -f -d8
crond: crond (busybox 1.20.2) started, log level 8
crond: USER root pid 932 cmd /mod/webif/lib/bin/auto >/dev/null 2>&1
crond: USER root pid 933 cmd /mod/sbin/rs_process >> /mod/tmp/rs.log 2>&1
/bin/sh: can't create /mod/tmp/rs.log: nonexistent directory
crond: USER root pid 937 cmd /mod/sbin/flatten >> /mod/tmp/flatten.log 2>&1
/bin/sh: can't create /mod/tmp/flatten.log: nonexistent directory
crond: USER root pid 938 cmd /mod/webif/lib/bin/auto >/dev/null 2>&1
crond: USER root pid 939 cmd /mod/sbin/rs_process >> /mod/tmp/rs.log 2>&1
/bin/sh: can't create /mod/tmp/rs.log: nonexistent directory
crond: USER root pid 943 cmd /mod/webif/lib/bin/auto >/dev/null 2>&1
crond: USER root pid 944 cmd /mod/sbin/rs_process >> /mod/tmp/rs.log 2>&1
/bin/sh: can't create /mod/tmp/rs.log: nonexistent directory
crond: USER root pid 945 cmd /mod/sbin/flatten >> /mod/tmp/flatten.log 2>&1
/bin/sh: can't create /mod/tmp/flatten.log: nonexistent directory
crond: USER root pid 949 cmd /mod/webif/lib/bin/auto >/dev/null 2>&1
crond: USER root pid 950 cmd /mod/sbin/rs_process >> /mod/tmp/rs.log 2>&1
/bin/sh: can't create /mod/tmp/rs.log: nonexistent directory
crond: USER root pid 954 cmd /mod/sbin/flatten >> /mod/tmp/flatten.log 2>&1
/bin/sh: can't create /mod/tmp/flatten.log: nonexistent directory
I can't see a flatten log (unless it's behind a button I can't see for looking!) - screen dump of the webif Diag pge here in case it helps: http://bit.ly/133DfLm
Since setting some specific recordings this morning, I've just checked and whilst the rs page has seen the Humax since scheduling them in the rs webpage today (at 2.38pm) and before the recordings were scheduled, it hasn't recorded them, nor are the other recordings due on Sat and Sun appearing in the schedule. So I'm guessing there's a bigger problem than just flatten.
I'm tempted just to remove the custom firmware and start again - I'll look up whether to use the RMA or custom firmware removal button in the Wiki - but any advice before I do this in light of the diag output above and rs problem would as ever be appreciated.
Thanks
Jim
 
There have been a few instances lately where a directory is missing and I'm guessing it is the same in your case, can you check if you have a directory called /mod/tmp? If it is missing enter :-
Code:
mkdir /mod/tmp

And then re-run the two command lines in #170
 
Umm I tried my basic windows knowledge and tried dir from the Telnet command prompt but that didn't work. How should I check?

Edit - sorry I don't know how I misread your post, just following the instructions will repost in a minute or two... Edit~2 make that a few more minutes, it looks like it takes a while to run...

Looks like it's still running but repeating itself? results so far:
Code:
humax# mkdir /mod/tmp
humax# pkill crond
humax# /mod/sbin/crond -f -d8
crond: crond (busybox 1.20.2) started, log level 8
crond: USER root pid 1039 cmd /mod/webif/lib/bin/auto >/dev/null 2>&1
crond: USER root pid 1040 cmd /mod/sbin/rs_process >> /mod/tmp/rs.log 2>&1
crond: USER root pid 1041 cmd /mod/sbin/flatten >> /mod/tmp/flatten.log 2>&1
crond: USER root pid 1145 cmd /mod/webif/lib/bin/auto >/dev/null 2>&1
crond: USER root pid 1146 cmd /mod/sbin/rs_process >> /mod/tmp/rs.log 2>&1
crond: USER root pid 1188 cmd /mod/sbin/flatten >> /mod/tmp/flatten.log 2>&1
crond: USER root pid 1191 cmd /mod/webif/lib/bin/auto >/dev/null 2>&1
crond: USER root pid 1192 cmd /mod/sbin/rs_process >> /mod/tmp/rs.log 2>&1
crond: USER root pid 1237 cmd /mod/webif/lib/bin/auto >/dev/null 2>&1
crond: USER root pid 1238 cmd /mod/sbin/rs_process >> /mod/tmp/rs.log 2>&1
crond: USER root pid 1239 cmd /mod/sbin/flatten >> /mod/tmp/flatten.log 2>&1
Should I just restart the box and run the instruction in #175 instead?
 
Try this and look for a directory called tmp, just enter ls -al /mod/
Code:
humax# ls -al /mod/
total 116
drwx------ 13 root root  4096 May 24 17:49 .
drwxr-xr-x  9 root root  4096 May 24 17:52 ..
-rw-rw-rw-  1 root root  108 Apr  2 12:38 .env
-rw-rw-rw-  1 root root    0 Oct  3  2012 .epgkeyword
-rw-------  1 root root  617 Oct 22  2012 .toprc
-rw-rw-rw-  1 root root    0 May 24 17:49 .unprotect.last
drwxr-xr-x  3 root root  4096 Apr 30 00:53 bin
lrwxrwxrwx  1 root root    20 May 24 17:49 boot -> /var/lib/humaxtv/mod
-rw-------  1 root root    0 Feb  6 19:16 dummyfile.txt
drwxr-xr-x  7 root root  4096 May 24 18:40 etc
drwxr-xr-x  2 root root 57344 May 13 21:16 img
drwxr-xr-x  6 root root  4096 Apr 13  2011 lib
lrwxrwxrwx  1 root root    27 Oct 24  2012 mipsel-linux -> mipsel-unknown-linux-uclibc
drwxr-xr-x  4 root root  4096 Oct 24  2012 mipsel-unknown-linux-uclibc
drwx------  4 root root  4096 Apr  3 00:11 monitor
drwxr-xr-x  2 root root  4096 Apr 10 23:59 sbin
drwxr-xr-x 17 root root  4096 Apr 30 22:59 screensaver
drwxr-xr-x  5 root root  4096 Feb  7  2012 share
drwxrwxrwt  5 root root  4096 May 20 00:15 tmp
drwxr-xr-x  6 root root  4096 Jul  8  2011 var
lrwxrwxrwx  1 root root    12 Apr 30 00:53 webif -> var/mongoose
humax#
 
OK this looks promising, the box went into standby which was perhaps why the output in #174 was taking so long?

Anyway, I've woken it up and immediately in the rs.huumypkg.org.uk page I can see the Humax had been seen straight away - and better still the recordings queued in the rs schedule are now finally in the Humax's recording schedule. There's one flatten non excluded folder in the media folder at the moment, I'll check in 30 mins time to see if it gets flattened. Edit: flattened a few minutes later! woo hoo!!

I wonder if this is a run once prompted by the making the directory and running the mod/sbin/crond command, or if the packages will now run automatically?

I then ran the ls -al /mod/ as directed above and can see a tmp directory apparently created / modified today at 7.30 which ties in with the commands earlier:
Code:
humax# ls -al /mod/
drwxrwxrwx    8 root    root          4096 May 24 20:08 .
drwxr-xr-x    7 root    root          4096 May 20 22:21 ..
-rw-rw-rw-    1 root    root          108 May 20 22:21 .env
drwxr-xr-x    3 root    root          4096 May 21 10:15 bin
lrwxrwxrwx    1 root    root            20 May 24 20:08 boot -> /var/lib/humaxt  v/mod
drwxr-xr-x    5 root    root          4096 May 24 20:10 etc
drwxr-xr-x    3 root    root          4096 May 20 22:42 lib
drwxr-xr-x    2 root    root          4096 May 22 09:56 sbin
drwx------    3 root    root          4096 May 24 19:30 tmp
drwxr-xr-x    6 root    root          4096 Sep  7  2011 var
lrwxrwxrwx    1 root    root            12 May 20 22:24 webif -> var/mongoose
humax#

Thanks again fellas
 
Should I just restart the box and run the instruction in #175 instead?
Yes, re-start the Humax, enter ls -al /mod/, if you don't have a tmp directory enter mkdir /mod/tmp. This may fix all your problems and after another re-start you may be able to see a flatten.log in the Web-If, if so you probably won't need to re-run the two lines in #170
 
I wonder if this is a run once prompted by the making the directory and running the mod/sbin/crond command, or if the packages will now run automatically?

Most likely everything was fixed by creating the /mod/tmp file, this area is used by lots for packages including rs and flatten. af123 has said that in the next version of the Web-If a check will be made to ensure /mod/tmp is present, once it is generated it is used by multiple packages but it looks like if you haven't installed other packages in the past, for example redring or something else that creates /mod/tmp then there is a problem
 
but it looks like if you haven't installed other packages in the past, for example redring or something else that creates /mod/tmp then there is a problem

You're right, it's a fairly new box and I've only installed the base firmware, webif, rs and flatten so I guess the folder must get generated by one of the other popular packages. Bundling the tmp folder check / creation if missing into the webif install sounds a good way to avoid anyone else coming a cropper.

Thanks again for all your help folks. This is a brilliant community and awesome functionality you've grafted on.
 
Can I suggest a couple of enhancements to flatten;

1. Add date/time stamps to the log output. It's quite tricky to tell when flatten has done things without it
2. If auto-decrypt is enabled, flatten should only work on decrypted files

With point 2. my impression is that if flatten runs before auto-decrypt you can wait ages for the DLNA index to be refreshed.
Without flatten, recordings can be auto-decrypted almost immediately after the recording has finished.
(I would guess that the recording process automatically adds the file to the DLNA index)
 
Back
Top