• 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.13 released

Status
Not open for further replies.
What version of Webif are you running? I thought this got fixed ages ago. All mine work properly (both wired and wireless).
 
hdr1 webif version 1.0.16-3 humax version 1.03.12 cf
hdr2 webif version 1.0.16-4 humax version 1.02.32 cf version 3.0

both boxes showing http//192.0.2.200..... as the DNLA URL.
 
Last edited:
It's supposed to use 127.0.0.1 in preference to your real IP address to get round this problem (I suggested this mod.), but it isn't doing it on my boxes and I can't immediately see why from a quick look at the code.
More fundamental is why it's got the wrong real address.
Can you run these at the Telnet prompt and report back:
Code: 
humax# ifconfig
humax# route -n
humax# cat /etc/hosts
 
Last edited:
prpr said:
It's supposed to use 127.0.0.1 in preference to your real IP address to get round this problem
Click to expand...
Actually, that's rubbish. It's only for decrypting that it does that, as obviously you can't use it from anywhere else. :oops:
 
o.k. HDR1 is on 192.168.1.13.

Here is the output. (I have blocked out the MAC address of the HDR -)

Code: 
humaxk# ifconfig
lo        Link encap:Local Loopback
          inet addr:127.0.0.1  Mask:255.0.0.0
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:241 errors:0 dropped:0 overruns:0 frame:0
          TX packets:241 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:22444 (21.9 Kb)  TX bytes:22444 (21.9 Kb)

wlan0     Link encap:Ethernet  HWaddr **:**:**:**:**:**
          inet addr:192.168.1.13  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:229154 errors:0 dropped:0 overruns:0 frame:0
          TX packets:71086 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000
          RX bytes:51120750 (48.7 Mb)  TX bytes:64150826 (61.1 Mb)

humaxk# route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
192.168.1.0     0.0.0.0         255.255.255.0   U     0      0        0 wlan0
0.0.0.0         192.168.1.254   0.0.0.0         UG    0      0        0 wlan0

humaxk# cat /etc/hosts
127.0.0.1       localhost
192.0.2.200     humaxk
 
I guess this is all to do with startup setting the hosts file before the wireless stuff has had a chance to get an IP address.
It might be useful to see the wlan.log and modinit.log files (make sure you remove keys and other sensitive info. before posting).
A workaround is probably to add this to the bottom of your /mod/etc/anacrontab file:

1 1 setup_hosts /sbin/modinit setup_hosts
 
with a previous router I was able to reserve an IP address for the MAC of the HDR. I then had the HDR on DHCP.
I will try modifying the anacrontab.

Modifying the anacrontab file has worked. thanks.
 
Last edited:
I've had trouble in the past with the boxes reverting to DHCP after I'd 'successfully' set them to Manual following a default setting of some sort.
The router has a reserved IP for each box mapped against the MAC address, so the procedure I've now adopted is:
With the box in DHCP mode I reboot and mess around (ie. I can't remember exactly) until it gets the correct IP address and corresponding other numbers.
Then I change it to Manual, at which point it has (so far) locked in correctly.
 
Fix for minor table heading bug in the EPG search results page:
Code: 
--- /mod/webif/cgi-bin/epg/search.jim~
+++ /mod/webif/cgi-bin/epg/search.jim
@@ -70,6 +70,7 @@
  <th colspan=3>Channel</th>
  <th>Programme</th>
  <th>Synopsis</th>
+  <th></th>
  </tr>
  }
} else {
 
Last edited:
And another one...
Weak muxes sometimes get "Unknown" put in the database for the Network name, which makes them display as "nown" on the Channel Information page, as normally there is an "i7" prefix which needs to get stripped out.
Code: 
--- /mod/webif/cgi-bin/channel.jim~
+++ /mod/webif/cgi-bin/channel.jim
@@ -51,7 +51,10 @@
  "
  puts "<td>[progressbar $ucLevel]</td>"
  puts "<td>[progressbar $ucQuality]</td>"
-  puts "<td>[string range $netName 3 end]</td>"
+  if {[string range $netName 1 2] eq "i7"} {   
+  set netName [string range $netName 3 end]
+  }
+  puts "<td>$netName</td>"
  set channels [$db query {
  select usLcn, szSvcName, szPrvName, aucDefaultAuthority
 
Thanks - applied. I added a new system function to handle the second one as there are two types of string encoding that the Humax seems to use and it makes sense to have a central function for it.
 
i have webif 1.0.15-5 and suddenly the service management tab, only, went weird
 

Attachments

  • Untitled.jpg
    Untitled.jpg
    40.1 KB · Views: 13
That is usually my policy too, but I make an exception for the CF because of our direct access to the relevant change control authority.
 
I'm on your version and webif in Chrome still misbehaves on management tab. In IE it's fine.
could you try chrome for me?
 
Black Hole said:
I'm sure I have raised this before: why does a pending series recording in the WebIF recording schedule not allow for the target folder to be changed prior to incorporating that item through a reboot? Currently adding the recording from the WebIF EPG and redefining the target folder involves a reboot to incorporate the item into the schedule, then another reboot to update the target folder.
Click to expand...

I would also like this feature as well. You can do it on the FOXSAT-HDR in one step which makes everything a lot easier!
 
Status
Not open for further replies.
Back
Top