• 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] Version 1.0.0 Released

prpr, thanks for the advice.
I copied and pasted your instructions into the Telnet console.
When I executed the first statement, the console gave me the following response:
"
SMART-ack_realloc|136|
pkgdev |0|
SMART_status||PASSED
SMART_realloc|0|
SMART_spinretry|0|
SMART_pending|0|
SMART_offline|0|
"
The error message was still being displayed after relaunching WebIf

When I executed the second statement, all I got was a humax# prompt and the error persists
Just for good measure, I rebooted the Humax but it is still there.

My guess is that what ever the acknowledge faults button is doing, it can't cope with negative numbers. I also wonder whether, once I get a sector re-allocation, I will then be able to accept it as it will move from 0 to 1.

Do you think if I uninstalled the whole thing and reinstalled it, that would wipe the settings?

Thanks again
 
af123,
Thanks for your response. Unfortunately, I have only just read it.
I ran the diskattrs diagnostic and that seems to have fixed it.
Many thanks to you and prpr for all your help
 
Niall Edwards said:
When I executed the first statement, the console gave me the following response:
"
SMART-ack_realloc|136|
"
Click to expand...
I would guess that, having run the diagnostic, if you run this again you will now get 0:
Code: 
humax# echo "select * from settings;" | sqlite3 /mod/etc/webif.db
When I executed the second statement, all I got was a humax# prompt and the error persists
Click to expand...
That's expected. You were just setting that value. Unfortunately it was the wrong value!
Code: 
humax# echo "update settings set nval=0 where name='SMART_ack_realloc';" | sqlite3 /mod/etc/webif.db
would presumably have worked.
 
af123 said:
Where did SMART-ack_realloc come from I wonder. The first - should be a _
Click to expand...
I probably mistyped it the response.
To my shame, I have got so used to Windows Ctrl-C & Ctrl-V that I forgot about 'Mark' & 'Copy' in the Command Prompt Console Edit options so I just typed it in.
In future, I will make sure that I copy & paste all responses. Hope it didn't cause too much confusion.
 
In response to prpr from yesterday morning, re-running echo "select * from settings;" | sqlite3 /mod/etc/webif.db now gives me:
"
pkgdev|0|
SMART_ack_realloc|0|
SMART_status||PASSED
SMART_realloc|0|
SMART_spinretry|0|
SMART_pending|0|
SMART_offline|0|
humax#
"
I'm not completely sure but the Humax feels a bit more responsive in the media menus with the new HDD. It is only a Western Digital Green drive, nothing fancy.
 
Instead of the ", use [code]...[/code] or [quote]...[/quote] tags. For information see Help.. BB Codes (Help button near the top of the page).
 
That post seems to refer to webif 2.74 and relate to the Foxsat. I've been running Chrome 64m for a few days and the problem is still there.
 
Yes, it does refer to the Foxsat but they started having issues with Chrome and the web interface at the same time as people here, and the foxsat web interface is a fork of the one here.
 
As far as I can tell, Chrome has not been updated since April 9th, and that didn't fix the issue.
 
af123 said:
I've seen a post over on AVForums (Ref: http://www.avforums.com/forums/18873311-post306.html) that says that the Chrome issue with the Foxsat web interface seems to be fixed with the latest version of Chrome. Can anyone who was having problems confirm whether the new version works properly with this web interface?
Click to expand...
Still a problem on the current Chrome, I'm afraid. Version 26.0.1410.64 m.

Some patterns in the behaviour that I've noticed:

Observed effect: The file info pop-ups lose their background and formatting; the EPG list has no grid formatting at all and is just a long list of programme names; buttons are un-styled. The data on the page is correct; just that the styling is missing or incomplete.

Affected pages: I've observed the problem on the EPG (/cgi-bin/xepg.jim) and the file list (/browse/index.jim), but no other pages so far.

Patterns in repeatability: The problem never occurs when a page has been refreshed (Ctrl-F5). It only ever happens when navigating from one page to another. A full page refresh always fixes the problem for me, but then it re-occurs when navigating back to the pages.

Patterns in HTTP headers: There is a difference between HTTP requests which result in a broken page versus a correctly rendered page. The difference is that the correctly rendered page always has the following HTTP parameters in the request header:

Cache-Control:no-cache
Pragma:no-cache

Conversely, these HTTP parameters are always missing in the instances where the page ends up broken. Of course, this isn't necessarily causal, and it means little to me... But it might help to point at where the problem lies? It does feel like part of the page isn't being loaded into the browser correctly - like some of the CSS definitions or something?

I've made some screenshots of the captured HTTP responses. The first shows when the page worked, and the second when it failed:

worked.png failed.png

HTTP violations in general: I don't think this is necessarily related to the problem; but my Fiddler proxy reports an HTTP protocol violation on every page that the Hummy serves. This violation is that the response has no Content-Length or "connection close" - but, that affects every page regardless of success.

My web-if: This is important..! I'm still on 0.13.3-4. So even though this is being discussed in the 1.0.0 thread, it's important to note that this Chrome problem affects the previous version of web-if.

Hope that helps.

Cheers
 
Is there a way to restart the auto logging? I cleared my auto log a couple of hours ago, but log is still empty. I can see that the auto process is busy auto-shrinking a folder of recordings.

I have tried a reboot and changing the logging level.
 
A reboot should certainly do it. I can see why clearing the log while the auto process was running could break it but once it's finished it should log once it runs again. A reboot would have stopped the auto-shrink (which is fine) and the log should have picked up when auto started running again after the reboot.
 
Thanks for the response af123. I was refreshing the browser and clicking on the auto.log every 10 minutes or so for about 4 hours and just got the refreshed empty log header, I could see that the shrink process was running and working its way down the file list. Then about an hour ago it suddenly produced a log of the previous 4 hours or so.

Interestingly, fix-disk.log which normally sits above it in the list, and had disappeared after the reboot, reappeared at the same time as the issue with the auto.log, re-appeared.
 
You must log in or register to reply here.
Back
Top