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

DLNA Server Name

Black Hole

Black Hole

May contain traces of nut
We can change the host name in the WebIF settings, but what about the name the DLNA server announces on the network? Now I have two HDRs on the network, I can't tell them apart without dropping in to see what's on the server - they both announce themselves as "HDR-FOX T2 Media Server".
 
Thanks for the reminder.

This is fairly old isn't it? We have new facilities now (thanks to you of course). Wouldn't it be possible to run the bsed edit process on the existing humaxtv binary while in maintenance mode? If so, it could be a telnet menu option! I'll have a play.

Perhaps it could even be a WebIF setting, replacing the existing string at next reboot?
 
I can't think of a practical solution because the humaxtv binary resides in the read-only root filesystem. Modifying it requires reflashing and can't be done at boot time because the hard disk isn't available until the humax software has run.
 
Code: 
humax# opkg list bsed
bsed - 1.0.0 - Binary-safe search/replace utility.
 
What would be required to do this edit on a PC? Is the unpacking and repacking required only available via these custom tools compiled for the Humax?

Is the data field in question in an area that is unaffected by .27/.28/.29/.32 - hence the direct update via CF would not wipe it out?

Is it possible to add the custom firmware to the unpacked image so that the result is a complete firmware replacement? My guess is that by unpacking the CF into the same image (or a separate image and then doing a "replace") it will produce a combo image I can package up.

Alternatively, as the patch is only into humaxtv, is it necessary to repackage the whole lot, or would a custom .hdf with just the modded humaxtv be sufficient?

I am minded to try it out, just to try it, but in the long term it won't matter much because I shall be network mounting (I am fed up with DLNA already).
 
Black Hole said:
What would be required to do this edit on a PC? Is the unpacking and repacking required only available via these custom tools compiled for the Humax?
Click to expand...

The bit that would be difficult is the unpacking and repacking of the squashfs filesystem. Tools like 7-zip can do it but they destroy the extended attributes on the files and have trouble with device files etc. Humidify works on Windows (although it's command line driven) and there are plenty of hex editors for Windows.

Is the data field in question in an area that is unaffected by .27/.28/.29/.32 - hence the direct update via CF would not wipe it out?
Click to expand...

No, it's squarely in the only bit that's often updated - the humaxtv binary.

Is it possible to add the custom firmware to the unpacked image so that the result is a complete firmware replacement? My guess is that by unpacking the CF into the same image (or a separate image and then doing a "replace") it will produce a combo image I can package up.
Click to expand...

You can apply the process on the Wiki to a CFW .hdf file in just the same way as to an official .hdf file. In fact, the Wiki article assumes you're working on a CFW HDF - several steps won't quite work if you aren't.

Alternatively, as the patch is only into humaxtv, is it necessary to repackage the whole lot, or would a custom .hdf with just the modded humaxtv be sufficient?
Click to expand...

You need to repackage everything because the root filesystem (which contains humaxtv is a single SquashFS image).
 
Aha - I thought it was telling me to modify a normal update file. I didn't realise the article refered to the CF file - even though it says so in the first paragraph (perhaps bold text would help).

That's a bit of a turn off - I am more likely to update the CF file than the standard one, so would have to apply the update to every one!!
 
af123 said:
I can't think of a practical solution because the humaxtv binary resides in the read-only root filesystem. Modifying it requires reflashing and can't be done at boot time because the hard disk isn't available until the humax software has run.
Click to expand...

App for changing the Humax DLNA Server Name

Whilst personally happy with the Wiki method (http://wiki.hummy.tv/wiki/Change_Media_Server_Name) of changing the DLNA Media Server name, I noted other’s may be less enthusiastic. Which set me to thinking and using up some of the time I don’t have...

There seem to be a number of solutions to making this “user friendly” (that is, implemented in a manner allowing the name to be changed in a simple way, for example though the Webif without any need to flash firmware). Several types of “simpler looking” methods (but with snags) have been left on the backburner in favour of something a bit more mysterious (it isn’t really!).

This more esoteric method is installed and running on my “backup” HDR FOX T2 and so far seems to be working fine (I can still watch TV on it and it still records and so on). Currently I am looking for any “gotchas” or issues and working on some improvements needed to turn it into a final product. So it is still experimental.

All the methods I thought up involved modifying part of /etc/init.d/S90settop to read:

if [ -x $MODBOOT/xhumaxtv ]; then
$MODBOOT/xhumaxtv /usr/bin/humaxtv
else
/usr/bin/humaxtv
fi

Messing with $MODBOOT/settop.env (to include the guts of S90settop and never returning) was rejected as exactly that; messy/problematic/unclear and I don’t like that sort of thing.

xhumaxtv is (for this one) the application that does the magic. Deleting it will restore the original behaviour, as long as you can get on to the system should there be some kind of problem with it. Currently the desired DLNA server name is read from a text file called /var/lib/humaxtv/mod/dlnaservername. The applications name isn’t set in stone; I just stuck an x on the front of humaxtv as a place marker; if someone can think of a posh name? And I haven’t written a Webif settings panel.

I would assume if there anyone is interested in it that I hand it over to af123, when it is release rather than test, for “inclusion” in the custom firmware/packages. Maybe someone can write the panel to change the text file?
 
Sounds very interesting. The current method is daunting for many people. Adding a hook to the next version of the custom firmware (along the lines of your S90settop modification) is certainly no problem and a settings panel would be straightforward enough too. This could be delivered as a package with the xhumaxtv bit and the web interface plugin all in one.

(ptrace() ?)
 
af123 said:
Sounds very interesting. The current method is daunting for many people. Adding a hook to the next version of the custom firmware (along the lines of your S90settop modification) is certainly no problem and a settings panel would be straightforward enough too. This could be delivered as a package with the xhumaxtv bit and the web interface plugin all in one.

(ptrace() ?)
Click to expand...
Indeed! Give me a few days to find the time to double check things and I can send you the code. Or you can have a copy now if you want an early look?

The other simpler? ways required messing with the available writable storage on boot prior to humaxtv being run... that is, copy humaxtv somewhere writable, modify the copy and then use execve to make it “look” like we're running the original (in case it worries about where it really is). Problem there was that there is not enough room before humaxtv is run, and it didn't seem to like being started, stopped and restarted and so on. Anyway, I decided to see if modifying the running process when it starts might be safer than tinkering with things that might have unexpected side effects.
 
kev7378 said:
All the methods I thought up involved modifying part of /etc/init.d/S90settop to read:

if [ -x $MODBOOT/xhumaxtv ]; then
$MODBOOT/xhumaxtv /usr/bin/humaxtv
else
/usr/bin/humaxtv
fi
Click to expand...

Using a name with "humaxtv" in it appears not to be a good idea: as there is something in the Webif that appears to use "humaxtv" (or a substring of) to get process IDs for "/usr/bin/humaxtv", and ends up failing because it is manipulating "175\n176"!

Apart from renaming "xhumaxtv" to something that does not contain "humax[tv]", I think there may be another way to fix that in the DLNA bootstrapping application (something I was going to try anyway).

Code: 
hdrfoxt202# ps -eaf | grep humaxtv
root      175  161  0 21:17 ?        00:00:00 /var/lib/humaxtv/mod/xhumaxtv /usr/bin/humaxtv
root      176  175 17 21:17 ?        00:07:24 /usr/bin/humaxtv
root      1572  1562  0 21:59 pts/0    00:00:00 grep humaxtv
hdrfoxt202# pgrep -n humaxtv
176
hdrfoxt202#
 
kev7378 said:
Using a name with "humaxtv" in it appears not to be a good idea: as there is something in the Webif that appears to use "humaxtv" (or a substring of) to get process IDs for "/usr/bin/humaxtv", and ends up failing because it is manipulating "175\n176"!
Click to expand...
Yes, it's the {system busy} routine in /mod/webif/lib/system.class. Adding -n is a good idea though.
 
Do I understand correctly that this is inching towards a non-burned-in renaming of the server name (just as a WebIF setting)? Excellent.
 
You must log in or register to reply here.
Back
Top