• The forum software that supports hummy.tv has been upgraded to XenForo 2.3!

    Please bear with us as we continue to tweak things, and feel free to post any questions, issues or suggestions in the upgrade thread.

[webif] Web Interface version 1.0.17 released

Status
Not open for further replies.
It's deliberate that the small pane is permanently displayed on that page and it refreshes every 30 seconds or whenever the OK button is sent. It's useful to see what the box is doing while controlling it remotely.
 
Nitpicking:
Code:
19/10/2014 03:26 - Automatically upgraded package webif from 1.0.17-5 to 1.0.17-6
http://hummy.tv/forum/threads/5031/
The link is to the locked thread for release 1.0.13
 
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.
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
 
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

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;">
 
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;">

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.
 
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)
 
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.
 
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...
 
No, I think you're right there... but if the capacity calculations were off it could have gone wrong.
 
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.
 
I suspect it's a bug which came in with the new pie chart. You can make it work if you click on exactly the right place somewhere near the edge of the circle.
 
Sorted now I can hit the correct spot every time.

One other issue though, should the usage show the same?

wkk1du.png
 
I don't know, but presumably the total excludes the TSR buffer. Even so, the percentages don't add up to 100. I find it a bit weird but have never bothered to investigate why yet.
 
Status
Not open for further replies.
Back
Top