[WebIF] 1.2.2

Black Hole

Black Hole

May contain traces of nut
Here's a funny thing: I set auto-MPG on a folder, and it started working through the folder converting .ts to .MPG. I then decided I would run out of disk space before the job was complete and turned off auto-MPG, to set up an auxiliary folder and do the conversion in batches.

The MPG conversion has continued in the original folder, not the new folder.
 
A reboot seems to have sorted it, although even then it looks like some conversions happened in the original folder after the reboot. Anybody confirm this?
 
WebIf 1.2.2-5 removes Mongoose.
It tries to delete /mod/etc/init.d/S01mongoose but complains that it can't be found.
This is indeed true because the file has been renamed to Z01mongoose somewhere along the line...

There's a symbolic link at /mod/var/mongoose as well. Is this redundant?
 
I've just tried a schedule restore with 1.2.2-5 and found my manual recording which was set for 11:59 to 13:05 has now changed its start time to 12:59 on the WebIf. The .rbk file says 20150415115900. The SUI (I dislike that term) correctly still says 11:59.
 
prpr said:
It tries to delete /mod/etc/init.d/S01mongoose but complains that it can't be found.
Click to expand...
It's a harmless error message though - the Z01mongoose was done when lighttpd went in and will be automatically removed in the next version, although there's nothing to stop you removing it now.
There's a symbolic link at /mod/var/mongoose as well. Is this redundant?
Click to expand...
NO. Several plugins still install themselves using that path.
 
Fix for some broken HTML:
Code: 
humax /mnt/hd2/mod/webif/html/sched # diff -u assets.jim~ assets.jim
--- assets.jim~
+++ assets.jim
@@ -137,8 +137,6 @@
  placeholder="Defaults to channel name"
  class="text ui-widget-content ui-corner-all">
  </td>
-  </tr><tr>
-  </td>
  </tr>
  </table>
  </form>
 
prpr said:
I've just tried a schedule restore with 1.2.2-5 and found my manual recording which was set for 11:59 to 13:05 has now changed its start time to 12:59 on the WebIf. The .rbk file says 20150415115900. The SUI (I dislike that term) correctly still says 11:59.
Click to expand...
A bit more analysis... I set up another manual recording with the same times but on a different channel which yielded:
nsttime: 1429185540 = Thu 16 Apr 2015 12:59 BST; szsttime: 20150416115900
nsttime: 1429181940 = Thu 16 Apr 2015 11:59 BST; szsttime: 20150416115900

The first recording was set up whilst in GMT and the second obviously in BST. Both record at 11:59 local time, so it's clear that the Humax software is using the szsttime field to trigger and not the nsttime field. Webif clearly uses the opposite, so ought to be changed to match the Humax software's way IMHO.
 
I found this in the activity log for a manual recording:

11 16/04/2015 08:00:05 - Recorded: /Headline News (32 minutes - RT)
10 16/04/2015 08:24:49 - System booted (Scheduled event).

The recording finished at 9 am so the log (line 11) is an hour out, presumably for the reason described by prpr above.
 
prpr said:
A bit more analysis... I set up another manual recording with the same times but on a different channel which yielded:
nsttime: 1429185540 = Thu 16 Apr 2015 12:59 BST; szsttime: 20150416115900
nsttime: 1429181940 = Thu 16 Apr 2015 11:59 BST; szsttime: 20150416115900

The first recording was set up whilst in GMT and the second obviously in BST. Both record at 11:59 local time, so it's clear that the Humax software is using the szsttime field to trigger and not the nsttime field. Webif clearly uses the opposite, so ought to be changed to match the Humax software's way IMHO.
Click to expand...
Can you post the line from the backup file? I can't yet see why the backup/restore process should modify those fields at all but something is obviously going on! Was the correct time shown in webif prior to the backup/restore?
 
I think the restore is a red herring. It probably did that before but I didn't look until after I'd restored. The problem is that the WebIf is apparently using the wrong field from the database, as detailed above.
 
Diagnostics: I like the new log file viewer, but what seems to be missing now is a means to export log files (previously one could copy & paste). A "download" button would be nice (I solved this using FTP, but a download button would be more convenient). Also, although one can "clear" a log file, there doesn't seem to be a means to remove it entirely.
 
Last edited:
Black Hole said:
Diagnostics: I like the new log file viewer, but what seems to be missing now is a means to export log files (previously one could copy & paste). A "download" button would be nice (I solved this using FTP, but a download button would be more convenient). Also, although one can "clear" a log file, there doesn't seem to be a means to remove it entirely.
Click to expand...
It is possible to copy and paste from the new viewer but while it is fine with small log files it is quite slow to load with larger files and 5000 lines only covers a few hours of the auto log with full tracing turned on so I have switched to viewing them with my full text editor via FTP.
 
1.2.2-8 seems to have broken the log file viewer (on iPad). The page comes up, but the file contents never display.

Aha! The file does display if I refresh the page. It's working properly now.
 
I have several auto... files, all apparently created automatically: auto.log, auto.20150327075436.log, auto.20150330075435.log, auto_old.log. What's the algorithm for their creation? I assume they have been spawned from auto.log when it gets too big, but why the odd-ball auto_old.log? This one seems to be the most recent. They are all too new for me to have had anything to do with them.

Without going into Telnet or FTP, there seems to be no means to delete them - hence the request for a proper delete option not just "clear". A rename option could also be useful - so that the user can preserve the current state of a log.
 
Look in settings - you can specify the rotation size and the number to keep in there IIRC.
 
I have a feature request, a 'clear all logs' button. The number of logs has grown and some of them, e.g. recmon, get large quite quickly. Every now and then I clear out the logs, and a single button to do this would be a boon.
 
Black Hole said:
Thanks... but that doesn't explain where auto_old came from.
Click to expand...
It looks like the auto process still creates an auto_old when the main file gets too big. I'll have a look at that as it should be using the new central log management.
 
Any plans to add COM8 to the diagnostics - channel information section. Currently flags the correct type (DVB-T2 HD) but the mux is unknown.
 
You must log in or register to reply here.
Back
Top