[webif] Web Interface version 1.0.17 released
- Thread starter af123
- Start date
- Status
JoeBloggs911
Member
A small irritant I've noticed for a while also looks like a bug: The header bar on all pages of the Webif is a clickable link that produces a 404 error. The URL bar shows "http://192.168.1.64/ return false". Running latest CF/Webif; Firefox 32.0.3 on Win7x64.
Ezra Pound
Well-Known Member
Clicking on the Header Bar should take you to the Main Menu Web-If screen, obviously you won't see a change if you are already on this page, so I'm guessing 192.168.1.64 is the IP address of your Humax
JoeBloggs911
Member
It also happens on all the subpages. However, I've just tested and found that it doesn't happen in Opera, so it must be down to something in my Firefox setup.
Later: It also doesn't happen in Firefox safe mode.
Mine works happily on several versions of Firefox in use here, IE, Chrome, Android and Firefox browsers on Android phone, Windows Mobile... have you got any add-ons in Firefox then that fiddle with the page like grease monkey etc?
<div id=topbar class=container onclick="location.href='/'; return false;">
<div id=topbar class=container onclick="location.href='/'; return false;">
JoeBloggs911
Member
I don't think so. I tried disabling all addons that could possibly have an effect to no avail. I know it works as it should in Opera, in Firefox 32.0.3 Portable, and the standard FF 32.0.3 in safe mode. It has to be an interaction with one of the many addons I have installed, or with the highly customised interface I have created over the years. It's not enough of an irritant to spend any more time on.
cdmackay
Active Member
Apols if this has been raised before - it rings a bell, but I can't find it...
A friend has just ran out of space on his T2/CF, because he enabled both recursive auto-decrypt, and auto-shrink, on "/media/My Video".
That produced two backup copies, in [Deleted Items], of every file, and eventually the disk filled up completely.
Whilst that seems entirely understandable, I had thought that the auto-processing "wrapper" would not run disk-space gobbling jobs if the disk space was getting too low?
So, was this just user error, or should this have been caught?
thanks much indeed...
[edit] he's running:
Web interface version: 1.0.17-7
Custom firmware version: 2.23 (build 2035)
Humax Version: 1.03.12 (kernel HDR_1.03.11)
A friend has just ran out of space on his T2/CF, because he enabled both recursive auto-decrypt, and auto-shrink, on "/media/My Video".
That produced two backup copies, in [Deleted Items], of every file, and eventually the disk filled up completely.
Whilst that seems entirely understandable, I had thought that the auto-processing "wrapper" would not run disk-space gobbling jobs if the disk space was getting too low?
So, was this just user error, or should this have been caught?
thanks much indeed...
[edit] he's running:
Web interface version: 1.0.17-7
Custom firmware version: 2.23 (build 2035)
Humax Version: 1.03.12 (kernel HDR_1.03.11)
Trev
The Dumb One
Do you mean up and running, or running away
Black Hole
May contain traces of nut
Regardless of what protections are put in place, recording too much and deleting too little will ultimately fill up the disk (however big the disk). Relying on shrink because you are not disciplined enough not to record what you will never have time to watch is only a stop-gap measure, and not worth the (slight) risk of corruption IMO.
Constantly running with an almost-full disk is asking for trouble. Recordings will be fragmented and there is no defrag process for Ext3. The CF will have no room to work. The only real solution is a spring clean now and a reduced diet in future.
Constantly running with an almost-full disk is asking for trouble. Recordings will be fragmented and there is no defrag process for Ext3. The CF will have no room to work. The only real solution is a spring clean now and a reduced diet in future.
cdmackay
Active Member
Things were slightly different in this case: the disk was initially nowhere near full, but the turning on of a global decrypt/shrink resulted in a tripling of used space, with two backup copies of every file. I imagine that if the disk were more than 33% full, that would be bound to happen?
Normally, the dustbin emptier would have dealt with this, but presuming that runs only daily, the disk filled up before the emptier process ran.
I had some vague idea that there was some restriction on auto-processing when the disk approached full - am I just dreaming that?
thanks...
Normally, the dustbin emptier would have dealt with this, but presuming that runs only daily, the disk filled up before the emptier process ran.
I had some vague idea that there was some restriction on auto-processing when the disk approached full - am I just dreaming that?
thanks...
Black Hole
May contain traces of nut
No, I think you're right there... but if the capacity calculations were off it could have gone wrong.
OP
The automatic processing will stop once the available disk space gets down to 1GiB. It used to stop earlier but that caused its own problems (see http://hummy.tv/forum/threads/insufficient-disk-space-for-what.5097/).
cdmackay
Active Member
ah thanks, yes, that rings a bell.
Of course, a single decrypt could easily use more than 1GB, so it's not surprising he ran out of space.
thanks all, for the comments.
MontysEvilTwin
Well-Known Member
Minor observation: if you have a recording in progress that was set up as a manual timer recording rather than from the guide, the pop-up banner at the top of the Web-If interface shows this as playing rather than recording: it correctly shows as recording in the scheduled events table.
- Status