Humax & Twonky

Border said:
Is your (humax) connection Ethernet or WiFi?

The reason I ask is that recently SWMBO was using HDR1 to watch an MP4 recording stored on HDR2 via WiFi/DNLA. I switched off HDR2 and HDR1 froze. I had to power off HDR1 . I have network-shares-automount installed on both boxes. Is the twonky issue only Ethernet or only WiFi or both?
Click to expand...
Mine is a wired connection to the Humax, but to get to the QNAP it then goes over a wireless bridge so there is a wireless element to the connection. So, as far as anything which is likely to make a difference is concerned (i.e. network drivers/routines on the Humax) it is wired. If it is some strange issue with network latency or something then it would be behaving like a fast (5Ghz N) wireless connection.

Shaggy said:
A workaround on the QNAP side is to disable Twonkymedia DLNA Server in the QNAP Control Panel, then separately install an earlier version of Twonky as a QPKG. Personally I still use Twonky 6.0.34, which I downloaded from here, and it coexists happily with the HDR.
Click to expand...
Good point. I have thought about the fact that you can upgrade to later versions of Twonky with QPKGs, but didn't think to look for an older one. If I don't find a Humax solution then I will probably use that - thanks.
 
I had a chance to have a play and I have a partial solution using iptables.

I have created /mod/etc/init.d/S22twonkyblock with the following contents:
Code: 
#!/bin/sh

iptables -A INPUT -p tcp --dport 50001 -s 192.168.1.1 -j DROP
Where 192.168.1.1 is the IP address of my NAS that runs Twonky 7.

This has the effect of stopping all communication between the humax and Twonky and solves the crashing. Twonky doesn't see the Humax and the Humax cannot see Twonky. However, the Humax can still see the NAS shares that I have mounted and use them as normal which is one step on from a complete block.

Unfortunately, all the DLNA communication prior to the crash seemed to be on port 50001 so further filtering to still allow the Humax to see Twonkey will require filtering based on the content of the packets. I may or may not look into that. Most of what I need to do is now working, so I may not go further. I have kept a tcpdump file from a crash that I can look at in more detail in the future if I want to.
 
rowanmoor said:
Unfortunately, all the DLNA communication prior to the crash seemed to be on port 50001 so further filtering to still allow the Humax to see Twonkey will require filtering based on the content of the packets. I may or may not look into that. Most of what I need to do is now working, so I may not go further. I have kept a tcpdump file from a crash that I can look at in more detail in the future if I want to.
Click to expand...
That's a nice update, thanks. Would you mind if I put it into a new 'twonky-protect' package or something similar? (I don't know what name to use because I don't want to imply that the problem is with twonky).

The kernel in CFW 3.00 doesn't currently include some of the more complicated iptables conditionals, such as matching on packet contents as I needed to keep the kernel size down. My plan was to try and work out what was causing the crash and then enable the necessary iptables modules in a future update.
This is probably a good enough solution for most people.
 
af123 said:
That's a nice update, thanks. Would you mind if I put it into a new 'twonky-protect' package or something similar? (I don't know what name to use because I don't want to imply that the problem is with twonky).
Click to expand...
Please do. What will you do about the NAS ip address? You could do a setting for it. You could leave out the whole -s x.x.x.x and that would block all DNLA media servers from communicating from/to the Humax, but that would seem a bit extreme.

I agree on the naming. Whilst it is limited to Twonky 7 (at the moment) Twonky isn't doing anything wrong. You could make it more generic dnla-server-protect, but that could confuse people into thinking they need it for any dnla server.

af123 said:
The kernel in CFW 3.00 doesn't currently include some of the more complicated iptables conditionals, such as matching on packet contents as I needed to keep the kernel size down. My plan was to try and work out what was causing the crash and then enable the necessary iptables modules in a future update.
This is probably a good enough solution for most people.
Click to expand...
I thought that was probably the case. If I do ever investigate any further then I will do so with iptables on the NAS to find a working filter. I probably won't though because I think I would need to do a few more tcpdumps with different versions of Twonky and with all the shared folder mapping disabled etc and then have to compare them in detail which will be fairly time consuming and I don't really have time for all that.
 
af123 said:
Would you mind if I put it into a new 'twonky-protect' package or something similar? (I don't know what name to use because I don't want to imply that the problem is with twonky).
Click to expand...
"dlna-filter" or similar?
 
Just to add to the fund of knowledge here, my 'Lenovo EZ Media and Backup Center' runs Twonky 7.2.6-2 and crashes the FOX-T2 if the Media Centre is enabled.
 
You must log in or register to reply here.
Back
Top