• This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn more.
  • The forum software that supports hummy.tv has been upgraded to XenForo 2.0!

    This is a major upgrade which changes the look and feel of the forum somewhat but brings a host of improvements too. Please bear with us as we continue to tweak things and report any issues or suggestions in Site/Forum Issues.

[webif] Web Interface version 1.0.13 released

Status
Not open for further replies.

prpr

Well-Known Member
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:

prpr

Well-Known Member
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:
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
 

prpr

Well-Known Member
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:

MikeSh

Well-Known Member
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.
 

prpr

Well-Known Member
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:

prpr

Well-Known Member
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
 
OP
OP
af123

af123

Administrator
Staff member
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.
 

Black Hole

May contain traces of nut
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 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.
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.