Customised HDF file released

[Black Hole]

Regarding Win7 WMC, are there any down sides to just running Samba and accessing (decrypted) recordings just like any other file? Why bother with DLNA at all (apart from properly enabled software being able to find things for itself)?

 

[fenlander]

Go into the MediaTomb web interface (follow the link at the bottom of the web interface main page). From there you can browse the directory tree and select which directories to serve. I'm not near my box at the moment or I would post more detailed instructions!

Remember that MediaTomb can only stream content which you have decrypted though, which is why the default package installation just shares the virtual drive.

Thanks for that - I'd missed the link. That MediaTomb page is what I'd call rudimentary. I've been able to add some folders, but I'll be blowed ifI can see how to remove them! No matter, I don't really thing media servers are going to be my thing - for my purposes the Samba share makes more sense.

 

[Drutt]

Eek. That's very surprising because I don't think the low level firmware (Micom?) should have been replaced by the HDR update, although it might consult some bits in flash.

That's what I assumed - be rubbish if it did consult the flash, as that means it can't recover from a corrupt flash (or wrong flash as I now have. There are other signs that low level stuff may have changed - the led lights on the front now just run a "circling" pattern, and it just freezes when the box is on standby (I think it used to say the time). Tried a few other usb sticks with no sucess. Also tried renaming the update to HDR rather than HD in case its now looking for that.

If all else fails, you'll need to hook up the box to a JTAG so that you can write directly to the flash and hopefully fix whatever is wrong that way.

Do you know for sure this is possible? I don't know much about this other than what I goggled this morning...

Taking another approach, I'd like to try killing the HRD elf and running the HD one. Problem is that the firmware I'm now stuck with has your script that allows the firmware elf to be restarted, but not a different one - any idea how I could either prevent reboot on killing the humaxtv process, or is it possible in some way to patch over the readonly rootfs to redirect it to a new elf on the harddrive. Maybe there is a process motoring the s90settop exiting that I could kill?

 

[af123]

Taking another approach, I'd like to try killing the HRD elf and running the HD one. Problem is that the firmware I'm now stuck with has your script that allows the firmware elf to be restarted, but not a different one - any idea how I could either prevent reboot on killing the humaxtv process, or is it possible in some way to patch over the readonly rootfs to redirect it to a new elf on the harddrive. Maybe there is a process motoring the s90settop exiting that I could kill?

The easiest way is to touch a file called /var/lib/humaxtv/nosettop. I added that as a hook into the S90settop script so that the box could boot without starting the settop process, purely for experimentation. The file is deleted during boot but the S90settop script should drop into a sleep loop for you.

 

[Drutt]

The easiest way is to touch a file called /var/lib/humaxtv/nosettop.

I did try that, but couldn't telnet to the box - just looked harder at your script though, and looks like I also need to add a script called "network" there to ifconfig with my ip address right? Nice one - very forward thinking of you Will try it shortly...

[Edit] Or even better I could get the "network" script to execute a humaxtv elf of my choice

 

[af123]

[Edit] Or even better I could get the "network" script to execute a humaxtv elf of my choice

Just bear in mind that, at least on the HDR, the disks are mounted by the humaxtv binary itself so you proably won't have an alternative available to you at that point.

 

[af123]

I also need to add a script called "network" there to ifconfig with my ip address right?

Yes

humax# echo ifconfig eth0 192.168.0.1 > /var/lib/humaxtv/network
humax# chmod 755 /var/lib/humaxtv/network

 

[Drutt]

That worked nicely - was able to get the network script to mount the usb drive and load a humaxHD elf from there - the sound came back, and the led display started working. Quite a few things not working though - string mismatches and lots of crashes. Going to hack the binary to load its data / libraries from the usb disk instead of the rootfs. Doesn't solve the problem of not being able to flash it, but at least I should be able to make it usable for now - as a dual boot system with a decryption cababilities Shame I don't get HD transmittions here yet, so I don't know if an ota flash would fix it all.

 

[af123]

I wonder whether the utilities in mtd-utils might be useful in allowing you to write to the flash from within the booted environment?

humax# opkg files mtd-utils
Package mtd-utils (1.4.2) is installed on root and has the following files:
/mod/sbin/nandtest
/mod/sbin/flash_unlock
/mod/sbin/flash_otp_info
/mod/sbin/nandwrite
/mod/sbin/flash_lock
/mod/sbin/mtdinfo
/mod/sbin/flash_otp_dump
/mod/sbin/mtd_debug
/mod/sbin/nanddump
/mod/sbin/flash_erase
/mod/sbin/flash_eraseall
/mod/sbin/flashcp
/mod/sbin/flash_info

 

[af123]

I also just tried flashing a full version of your modifed HDR rootfilesystem (simply had to rebuild the hdf with the HD's system id). This fixed up a few text problems I noticed (must have been a mismatch with a data file containing them).

Just to confirm, did you flash the modified HDF for the HDR over the top of the release HD 1.02.20?

The modified HDF only includes the squashed root filesystem so won't have touched the kernel or bootloader. Even stranger that you can't flash it again.

 

[af123]

And one last thought, have you tried flashing straight after running the HD binary? It might just be that the HDR binary initialises the platform in a way that breaks flash updates.

 

[Drutt]

Just to confirm, did you flash the modified HDF for the HDR over the top of the release HD 1.02.20?.

Yes - or to be precise, moded HDR, over moded HD, over release HD (all 1.02.20)

 

[Drutt]

I wonder whether the utilities in mtd-utils might be useful in allowing you to write to the flash from within the booted environment?

Thanks - those look like they could be pretty useful. Certainly mtdinfo seems to return sensible information. flashcp looks like to one to go for, but I'm a little reluctant to try these at the moment for fear of making things worse!

I've now actually got the box into a reasonably good place using the following "network" script and the "nosettop" escape route we discussed above. It re-routes the /usr and /opt directories of the route filesystem to a copy of the HD filesystem on disk and then runs the HD elf from disk. I retouch the "nosettop" that your script deletes to force the "patch" to be permanent.

By removing a "BootHD" flag file on the disk, I can then chose to I boot into the "HDR mode" to remove encryption form recordings (but missing sound and recording capabilities).

sleep 7
mount -t ext3 /dev/sda1 /mnt/hd1/
mount -t ext3 /dev/sda1 /mnt/hd2/
mount -t ext3 /dev/sda1 /mnt/hd3/
mount -t ext3 /dev/sda1 /mnt/hd4/
if [ -f /mnt/hd2/BootHD ]; then
  echo Booting HD Elf
  mount /mnt/hd2/HDModhum/squashfs-root/usr/ /usr/
  mount /mnt/hd2/HDModhum/squashfs-root/opt/ /opt/
fi
if [ -f /mnt/hd2/PatchBootScript ]; then
  echo Patching Booting next time
  touch /var/lib/humaxtv/nosettop
fi
/usr/bin/humaxtv

The key was working out that the usb drive (as /dev/sda1) is not available until several seconds after bootup (hence the sleep 7 at the start). This seems to be route of the problem with being unable to flash. Previously the usb drive light would come on from the moment you hit the power button. Now it is several seconds in, and I think thats why it misses the window for checking for firmware updates. I wonder if boot code relies on the drivers from the routefilesystem to start up the usb device, or now the HRD drivers somehow preventing it from starting immediately.
If I understand correctly the HDR picks up the firmware later into the boot process? On the HD it is pretty imediatly you power up with the power button held down.

 

[Black Hole]

If I understand correctly the HDR picks up the firmware later into the boot process? On the HD it is pretty imediatly you power up with the power button held down.

I don't think so, there is no noticable delay... I just went to check, reflashed my box. With the TV up and running first, I powered up the HDR-FOX T2 with the remote. The Humax banner appeared on the screen and "system start" (or something like that) on the matrix display, then after about 2 seconds max it started the software download routine. Is that slower than you expect with the HD?

Incidentally, you don't hold any buttons down on the HDR - it just detects the presence of an hdf file and gets on with it from boot.

Incidentally #2, without a hdf file you get about 4 seconds of Humax banner, then a green flash (or at least I do), then the current channel comes through after a few seconds of black while the box sorts itself out.

 

[Drutt]

Also worth pointing out to other HD owners, it should be fairly easy now to set up a similar "dual boot" system, where you can optionally boot temporarily into "HDR mode" from disk to remove encryption from recordings. None of the dangerous reflashing that has caught me out involved I'll try and put something together in the next few days, but I now can't test it fully due to my schizophrenic box! Fancy testing it for me Trevor / moppet?

 

[Drutt]

I don't think so, there is no noticable delay...

Thanks for the info. Does it have to be done from the front USB port btw? I wonder my delay starting the usb is caused by it taking time looking for the non existant internal HD or something. It would be slightly worrying if the bootloader relies on drivers from the main root filesystem flash. Has anyone ever had it recover from an incomplete flash? I'm wondering if for example I just erased the flash, the "driver conflict" would be removed and the usb would startup ok again for the bootloader to pick usb...

 

[Black Hole]

Just for you, I have now reflashed from the rear port - no difference.

 

[Trevor Jasper]

Also worth pointing out to other HD owners, it should be fairly easy now to set up a similar "dual boot" system, where you can optionally boot temporarily into "HDR mode" from disk to remove encryption from recordings. None of the dangerous reflashing that has caught me out involved I'll try and put something together in the next few days, but I now can't test it fully due to my schizophrenic box! Fancy testing it for me Trevor / moppet?

I would be happy to give it a go. I have some encrypted recordings I wouldn't mind being able to decrypt.

Trevor

 

[bigbadal]

Pls can anyone point me to a tutorial on how to share a drive attached to the front usb port, so it can be seen from wmp?

tia.

Allan

 

[bigbadal]

ok, I've sorted this now using mediatomb - fantastic the way this has improved the box's usability. i have one minor issue with a folder full of .mpg files. I can view them in the mediatomb filesystem tab. If I click on + to add them, I don't get them populating the database. Other filetypes on the same drive but a diff folder are all adding just fine (.avi). Anyone got any thoughts or advise on this?

thanks

Allan