DLNA troubles

dandnsmith

dandnsmith

Forum Supporter
Back in the autumn, when I started using my FOX T2, I installed CF to allow use of the web IF. I also installed DLNA servers on 2 of my local PC network so I could play files and view pix held on the PCs. I found that it was unclear what the starting conditions needed to be to get successful connection (either way), but it seemed to be slightly better when the Win7 PC had its server running as well as the WinXP system.
The last couple of days I cannot seem to get the DNLA link working in either direction, and this may be because I installed the file having 1.02.32 with CF 2.15. Previously I believe (but cannot find it recorded) that I had 1.02.28 with CF2.15.
I have no problems contacting the internet from the T2 (for iPlayer etc), and I can always get to the web IF from a PC, or telnet in from a PC.
Can anyone throw light on my problem, or suggest diagnostic tests to locate it more precisely - I've considered reverting the firmware, but haven't rushed to it (as I'm unsure which version I was really on when it worked smoothly).
In case it matters, I use tvMobili! as DLNA server on the PCs, and VLC as PC player when try to do that link.
 
I don't know if it is the same problem, but I have found it hit-and-miss whether the PC server shows up at the Humax.
 
Unfortunately I don't do enough of this to offer any advice. Does anybody else have experience?
 
I've come across something which may be a further clue:
While pursuing alternatives to using the DLNA facility, I found that I could not get successful execution of a decrypt using the opt+ facility in WebIF. I had no problem using the download from the opt+ in WebIF.

I got an error message, whenever trying to decrypt:

Processing Rick Stein's Mediterranean Escapes_20130219_1517 Runtime Error: execute.jim:41: Connecting to 192.0.2.200:9000 (192.0.2.200:9000) wget: can't connect to remote host (192.0.2.200): Connection timed out at file "execute.jim", line 41

This contains the rather curious 'fact' that the DLNA server is on 192.0.2.200 - where my local network is 10.0.0.x - and I cannot see where this IP address is coming from. I have no record of what happened on the odd successful occasion of decrypting, unfortunately, and have no idea whether it would be in any of the logs.
 
dandnsmith said:
This contains the rather curious 'fact' that the DLNA server is on 192.0.2.200 - where my local network is 10.0.0.x - and I cannot see where this IP address is coming from.
Click to expand...
I believe that the Humax has two default IP addresses, one for the network port and one for WiFi. That address is, I think, one or other of the defaults. Was the box connected to your router at the time?
 
That's the fallback WiFi address if the Humax fails to negotiate DHCP with the router. You should not have a live network link to be accessing the WebIF in that situation, so I am confused.
 
I had a live link via wifi at the time.
Further, both the eth0 and wlan0 had IP addresses 10.0.0.142, as shown by ifconfig.
The links were working for both external connection to the Fox T2, and Fox T2 to other PCs on the LAN (as evinced by remote filesystems being accessible) and also to the the internet.

How would this fallback address be getting assigned in the face of a live link?
 
The decryption invokes a fetch from the DLNA server via a loop-back on the Ethernet port - wget sends a request to the specified IP address and URL within, and writes whatever comes back to file, which when you do that to the correct URL from the Humax DLNA server produces a decrypted stream of the recording.

What appears to have happened is that somehow the wrong IP address has been picked up by the WebIF process and the request has been sent to 192.0.2.200 instead of 10.0.0.142. Does rebooting cure it, or is it permanent? It is unusual for a home network to have these parameters, 192.168.x.x is normal.
 
The code takes the IP address from the hosts file. Something has caused that to end up with the wrong IP. I think I've seen this reported before with Wifi so it warrants further investigation.

Nothing unusual about a 10. address on a home network. Anything from RFC1918 can be considered normal although admittedly many router manufacturers default to something in 192.168/16


Posted on the move; please excuse any brevity.
 
af123 said:
The code takes the IP address from the hosts file. Something has caused that to end up with the wrong IP. I think I've seen this reported before with Wifi so it warrants further investigation.
Click to expand...
Can you not use the loopback address instead?
 
Interesting idea. Does the loopback address act as a full proxy for the subsequent processes?
 
prpr said:
Can you not use the loopback address instead?
Click to expand...
Yes, and I'll upload a version that does shortly. The reason it didn't originally is that the same method (ts dlnaloc) is used for determining the URL that the Download function uses. That's since changed and now the browser download option uses javascript to detect the URL by which the Humax is bieng accessed.
 
What appears to have happened is that somehow the wrong IP address has been picked up by the WebIF process and the request has been sent to 192.0.2.200 instead of 10.0.0.142. Does rebooting cure it, or is it permanent? It is unusual for a home network to have these parameters, 192.168.x.x is normal.
Click to expand...

I can speak to quite a number of reboots, which haven't cured it.

I'm relieved to hear that a version which acts differently is on the way - but how does the entry in /etc/hosts get to be this default value? Is it merely ignored, as it would be superceeded by some other method of determining the appropriate value? As a quick fix, editing the hosts file gets the correct acting for decrypt from the WebIF.
 
The hosts file is created by the CFW initialisation routine (modinit) either when the internal disk is first mounted or when DHCP completes. It is probably being created too early in your case, before the wireless has come up.

Do you use DHCP?
Can you post the contents of the modinit.log file shortly after a boot?

The new version of the web interface that solves this is available now.
 
No, I found problems with DHCP, so the IP addresses are set in the Menu Settings.
I've got the modinit.log - where the wlan0 allocation to 192.0.2.200 is plainly visible.

I've noted that I now see the DNLA server at 127.0.0.1 for the purposes of the opt+ and decrypt, and it has correctly decrypted a file for me.

Under what circumstances will this continue to bug me - I still haven't seen the server from any PC.
 

Attachments

  • modinit.txt
    5.6 KB · Views: 8
dandnsmith said:
Connecting to 192.0.2.200:9000 (192.0.2.200:9000)
Click to expand...

I dont know it this will be of any help but when I tried Foxlink I was trying both DHCP and manual settings for 'configure IP'. I have two HDRs. I had problems with error messsages saying trying to connect to 192.0.2.200. Decrypt wasnt working - DLNA settings appeared wrong. I am not sure if the wifi helper was setting the manual IP before the box had connected to wifi or vice versa. In the end turning off the FTP server, rebooting the box ond turning back on the FTP server fixed it after trying diffrent DHCP/manual settings. I dont know much about this. It seemed the DNLA server IP was not the same as the box IP during this problem and after 're-indexing' of library the problem went.
 
Thanks for that.
Unfortunately, I've had the ftp server both off and on without effect, and I've also tried resetting the DLNA database (not sure whether this is the re-indexing to which you referred).
I'll have to look at the wifi helper - not sure whether I have this, currently, installed.
What sort of DHCP and manual settings were you trying - DHCP seemed to be unusable when I tried it back in October?
I hoped that the use of manual settings would override any default - but it doesn't.
 
Both boxes currently on manual selection of ip address. From recollection I Set the router to reserve ip address for the mac address of the boxes then connected with dynamic settings turned off ftpserver [edit] then reset DLNA database, rebooted and then set ip selection back to manual. Now both boxes connect to their reserved ip address and I haven't experienced the problem since.
 
You must log in or register to reply here.
Back
Top