[webif] Version 1.0.0 Released

I still think an inobtrusive "help" link would be better, leading to a sub-page. It could be immediately above the release notes links.
 
I still think an inobtrusive "help" link would be better, leading to a sub-page. It could be immediately above the release notes links.
It's definitely much better without the help buttons/links.:)
They may be useful for new users, so they should be there when webif is first installed, with the option to remove them as we have now.
 
users are directed to http://wiki.hummy.tv/wiki/Disk_Problem
which has some initial content on it but still needs work.

Brilliant work af123, but would it be helpful to non-IT people, like myself, if it is made clear whether it is the "Raw Value" or the "Value" column of the Smart table that is significant? I am assuming it is "Raw Value", but could be completely wrong. My assumption is based purely on the improbabilty of having so many "100" values.
 
It is, as you say the 'Raw Value' that is significant, note that in a command line smartctl request, the raw value is in the far right column, whereas this data is displayed towards the left when reading a Web-If >> Diagnostics >> Hard Drive screen (SMART Attributes). Also some lines e.g. 190 Airflow_Temperature_Cel are not supported, use 194 Temperature_Celsius Raw Vaue for HDD temperature
 
Back to the broken webif screens. I came across this on the MoneySavingExpert forums:

If you're using Google Chrome then you probably noticed with the latest update they've forced a change onto users that alters the style of context and shortcut menus to white and increases the spacing to make things easier for tablet users.
Yet of course most of us aren't using tablets and don't want this. Thankfully at the moment there's still a way back to the previous more compact menus, by adding this command line option when you start Google Chrome:
--disable-new-menu-style
If you need further help, more details and instructions can be found here:
The appearance of the broken screens in webif does seem to coincide with the latest Chrome update and somehow this just seems a credible candidate for causing the sort of trouble some of us have been experiencing. Anyway, I'm trying Chrome with the command line option above and we'll see what happens.
 
Back to the broken webif screens. I came across this on the MoneySavingExpert forums:

If you're using Google Chrome then you probably noticed with the latest update they've forced a change onto users that alters the style of context and shortcut menus to white and increases the spacing to make things easier for tablet users.
Yet of course most of us aren't using tablets and don't want this. Thankfully at the moment there's still a way back to the previous more compact menus, by adding this command line option when you start Google Chrome:
--disable-new-menu-style
If you need further help, more details and instructions can be found here:
The appearance of the broken screens in webif does seem to coincide with the latest Chrome update and somehow this just seems a credible candidate for causing the sort of trouble some of us have been experiencing. Anyway, I'm trying Chrome with the command line option above and we'll see what happens.

I, at least, can confirm that the above fix doesn't solve the Chrome display problems. :(
 
I can also confirm. I've implemented the menu style fix, AND whitelisted the humax in adblock. I still get the issue. I have Adblock, IE Tab, Image search by cooliris, and tweetdeck extensions.

If I use IETab for the humax, it works fine. This is my short term solution, I've set IE Tab to be used by default with the humax.
 
Not working for me either with, --disable-new-menu-style page is still screwed up.

Only working fix at moment is having 1 extension running
 
Thanks for the tip, SandyMac, about using IETab. It does seem to stop the problem. I have put in the Hummy's IP address in the 'Auto URL's' section and it works fine.
 
I'm pretty sure that the Chrome rendering problems aren't related to the webif 1.0.0 release.

I'm still on webif 0.13.3-4 and have been getting problems like this (see my 1st attachment), and also like both screenshots that MrMarky posted on page 2.

chrome-broken-1.png

I'm also confident that the problems started happening after a recent Chrome upgrade (currently at 26.0.1410.43 m, running on Windows 7 64 bit).

The problem is intermittent. When it occurs, it presents as:
  • Missing background to popups.
  • Buttons are "un-styled".
  • Browsing files is lacks any style at all (this doesn't always happen at the same time as the first two).
In all cases, I find the problem is fixed by a full page refresh (e.g. Ctrl F5).

Now, I thought to run Fiddler (a sort of web debugging proxy) to see if I could spot a pattern when Chrome renders the page incorrectly. If you look at my 2nd attachment, Fiddler has determined that the webif responses aren't quite valid because the http response lacked some information about length or closure:

chrome-broken-2.png


[Start of speculation..!]

Of course this might be totally normal behaviour, and I might be off on a tangent. Fiddler seems to report the response issue on virtually every page from webif - or more accurately, on every page served by the web server; it's not necessarily a webif problem.

I'm no web developer; but I could hazard a theory that a client (Chrome in this case) could be upset by not knowing when the response has finished; maybe if it's processing the page in fixed size chunks and doesn't close the final one off properly... I dunno.

[End of speculation]

Hope that helps somebody "in the know"...
 
I think that the consensus is that the latest version of Chrome (v26.0.1410.43 m), breaks something when viewing the WebIf.

I know nothing of these things but my two brain cells have knocked together and wonder why no other Web pages appear to be broken?

Confused. :confused:
 
Some other web pages will be broken - it's a case of finding some that use the same constructs to define what you see. There's a lot of complicated stuff going on behind the scenes.
 
Has something changed in the rename funcion in webif? I am sure that you used to be able to change the media name and the file name.
 
Ah, so you can, generally.

I was trying to rename a film with accented characters because the accents (umlat) was stopping the shrink from working. It seems the accent also affects the remame function! Brian, I know from other threads, that you have also had issuses with accented characters.

The files are totally invisible in Samba.

I have just found that rename via Humax remote cures the problem.
 
I renamed the set of 4 files for a recording using FileZilla, this got round my issue.
 
Back
Top