WizRemote - Set timers on your wiz remotely via the web!

[Kezza]

changed line 100 and it works a treat, thanks

Kezza

[peteru]

BusyBox can be built with a http server that supports CGI. That's how I implemented the user interface for the IceBox. There's quite a lot that one can do with shell and awk scripts and the occasional C program.

[Jammer]

changed line 100 and it works a treat, thanks

Nice pickup Kezza

Eric, this may be a really dumb question but is there any way for WizRemote to detect that the BW is switched off, rather than the browser window simply timing out? I realise that the script isn't AI but wondered if there may be something that could differentiate between whether the BW isn't responding (therefore, possibly switched off) or a network/browser/webserver issue......though I guess these may all look exactly the same to a dumb script

Gary

[efry]

Hi Guys,

You're probably sick of all the updates but I got another one for you.

version 0.7

http://www.beyonwizsoftware.net/softwar ... ;attach=36

Code: Select all

0.7 * Added timeouts to read operations on the daemon.
      The daemon will disconnect the client if it doesn't
      receive its data within the timeout period.
    * Added read_bytes() to daemon
    * Changed read_line() to poll for data.
    * Set daemon socket to non-blocking
    * Fixed timer date display. I was using date instead of
      gmdate. Thanks to Kezza for spotting that one.

[efry]

Eric, this may be a really dumb question but is there any way for WizRemote to detect that the BW is switched off, rather than the browser window simply timing out? I realise that the script isn't AI but wondered if there may be something that could differentiate between whether the BW isn't responding (therefore, possibly switched off) or a network/browser/webserver issue......though I guess these may all look exactly the same to a dumb script

Gary

Hi Gary,

The script should error immediately if the host is unreachable. It depends on how your network handles packets to the device. I'm not really a networking expert sometimes a socket will return an error straight away and other times it will wait for a time out.

It might depend on whether your router opens the connection then tries to port forward to the device that isn't connected.

Eric

[Jammer]

Hi Guys,

You're probably sick of all the updates but I got another one for you.

version 0.7

http://www.beyonwizsoftware.net/softwar ... ;attach=36

Code: Select all

0.7 * Added timeouts to read operations on the daemon.
      The daemon will disconnect the client if it doesn't
      receive its data within the timeout period.
    * Added read_bytes() to daemon
    * Changed read_line() to poll for data.
    * Set daemon socket to non-blocking
    * Fixed timer date display. I was using date instead of
      gmdate. Thanks to Kezza for spotting that one.

Eric, are you able to include the names of the files that have changed in your updates? I'm experimenting with some page customisation for mobile phone access and it'd be handy to know which current files I can continue using and which ones need to be replaced with the updates....rather than chucking everything out and replacing them all.

[prl]

Eric, are you able to include the names of the files that have changed in your updates? I'm experimenting with some page customisation for mobile phone access and it'd be handy to know which current files I can continue using and which ones need to be replaced with the updates....rather than chucking everything out and replacing them all.

If you're compiling under Linux, Cygwin or Mac OS, you can use 'diff -r' to compare all the files in two directory subtrees and see exactly what's changed.

If you have the original of the source that you've modified, you can use diff between that and your version and 'patch' to apply those changes to the new version.

[orangehenry]

Hi, I've be struggling with this all week. I've updated to the latest verison of wizremote, replaced all the files, changed all the permissions, setup the config files, reinstalled apache/php/cgi but i still can't make it get past the login page. I enter my password/username and it just loads for a long time and eventually times out.

The only progress I've made is getting rid of the stray lines of code on the wizremote.php page, i think this was sovled by installing cgi. do i need anything other than apache/cgi/php installed??

what else might i be doing wrong?

thanks

[DaveR]

Just another thing: I noticed last night that my BW refused to open a telnet-patched firmware file with an altered background. Mind you, I had applied the telnet patch to a firmware that'd already had the background changed.....I haven't yet tried altering the background after the telnet patching to see if the BW will open the f/w. Anyone else experienced this?

Yep. I added the telnet patch to a background-patched firmware and the S1 refused to load it (using Matt's WizTools GUI). I then used my own combined Background Changer and Telnet patcher which changes the Background, then adds the Telnet patch and then repacks it and it loaded ok.

I then followed Matt's step-by-step instructions and also had the 'md not found' error so I used mkdir.

Eric: To prevent people getting a blank page after the log-in page you should change the defaults in config_inc.php from this:

Code: Select all

$GLOBALS["wiz_ip"] = "localhost";
//$GLOBALS["wiz_ip"] = "192.168.1.102";

to this:

Code: Select all

//$GLOBALS["wiz_ip"] = "localhost";
$GLOBALS["wiz_ip"] = "192.168.1.102";

I'd changed the IP to suit but missed the comments

BTW I've noticed that sometimes when calling ./reboot.sh via telnet it usually reboots straight away... but sometimes it just freezes with the channel name showing on the display and requires me pressing the power button on the remote to shut it down.

[orangehenry]

Eric: To prevent people getting a blank page after the log-in page you should change the defaults in config_inc.php from this:

Code: Select all

$GLOBALS["wiz_ip"] = "localhost";
//$GLOBALS["wiz_ip"] = "192.168.1.102";

to this:

Code: Select all

//$GLOBALS["wiz_ip"] = "localhost";
$GLOBALS["wiz_ip"] = "192.168.1.102";

That made everything work. Thanks heaps!

[Kezza]

if your editing php files use notepad2

Kezza

[Jammer]

if your editing php files use notepad2

Kezza

Great tip Kezza! Excellent little editor

[Kezza]

did you get my PM's Jammer?

Kezza

[Jammer]

did you get my PM's Jammer?

Kezza

Yeah, just got 'em. Have been out all morning. Will PM you back a bit later.

Can anybody tell me how to make config_channels_inc.php writeable by my webserver. I'm running Apache 2.2 and can't work out how to configure this?

Cheers
Gary

[efry]

did you get my PM's Jammer?

Kezza

Yeah, just got 'em. Have been out all morning. Will PM you back a bit later.

Can anybody tell me how to make config_channels_inc.php writeable by my webserver. I'm running Apache 2.2 and can't work out how to configure this?

Cheers
Gary

Hi Gary,

Are you running apache on a unix machine? The file needs to be writable by the apache process and the full path needs to be searchable (executable) by the apache process.

It's probably easier to just down load the file and copy it over the original. It's probably safer to if you're on a shared environment.

Eric

[efry]

Hi Dave,

Eric: To prevent people getting a blank page after the log-in page you should change the defaults in config_inc.php from this:

Code: Select all

$GLOBALS["wiz_ip"] = "localhost";
//$GLOBALS["wiz_ip"] = "192.168.1.102";

to this:

Code: Select all

//$GLOBALS["wiz_ip"] = "localhost";
$GLOBALS["wiz_ip"] = "192.168.1.102";

I'd changed the IP to suit but missed the comments

No problem, I've changed it and will update it with the next version.

BTW I've noticed that sometimes when calling ./reboot.sh via telnet it usually reboots straight away... but sometimes it just freezes with the channel name showing on the display and requires me pressing the power button on the remote to shut it down.

That's strange does the reboot script show any unusual messages? Are you running wizpnp? I don't think I check that. Maybe that hangs the system if you try to kill the wizdvp process while it is still running?

Eric

[tonymy01]

I am running WizPNP and timeshift, and none of these cause problems with reboot.
Eric, do you think a possible future timer update might, instead of manipulating the non-volatile stored timers file, manipulate the RAM stored timers instead? I did this for timer_extend before they brought out a Timer API for the 5K. It would save the reboot part of the script also?
I might start peeking around in RAM soon, as soon as I can get the silly toolchain working (mind you, there is a hexdump in busybox, maybe I don't need to code anything).
Regards

[Jammer]

Hi Gary,

Are you running apache on a unix machine? The file needs to be writable by the apache process and the full path needs to be searchable (executable) by the apache process.

It's probably easier to just down load the file and copy it over the original. It's probably safer to if you're on a shared environment.

Eric

Nah, I'm just running it on Windows. I originally created the config_channels_inc.php manually so will just continue to use this.

[orangehenry]

When i log into the timer page there are four times as many channels as i usually see on the beyonwiz. For example i get 10 copies of ten hd. How do i get rid of the excess and how do i know which ones to delete? Thanks

[efry]

I am running WizPNP and timeshift, and none of these cause problems with reboot.
Eric, do you think a possible future timer update might, instead of manipulating the non-volatile stored timers file, manipulate the RAM stored timers instead? I did this for timer_extend before they brought out a Timer API for the 5K. It would save the reboot part of the script also?
I might start peeking around in RAM soon, as soon as I can get the silly toolchain working (mind you, there is a hexdump in busybox, maybe I don't need to code anything).
Regards

Hi Tony,

I think it might be tricky to set timers directly in memory. Depending on how BW have implemented the timer list in memory. It might be dynamically assigned.

How are you going with your toolchain? Are you using the config system supplied with the code or are you compiling by hand? I used the presupplied make system for the most part. Then compiled elf2flt by hand.

Eric

[Jammer]

Just thought I'd post some minor alterations I made to Eric's script to better visualise the HDD stats (hope you don't mind Eric ):

TOTAL HDD CAPACITY: 186.31GB

HDD Used: 37.08% or 69.09GB
HDD Free: 62.92% or 117.22GB

$used = round((($total - $free) / $total) * 100, 2);
$used_gb = round(($total * $bs) / (1024 * 1024 * 1024), 2) - round(($free * $bs) / (1024 * 1024 * 1024), 2);
$total_gb = round(($total * $bs) / (1024 * 1024 * 1024), 2);
$free_gb = round(($free * $bs) / (1024 * 1024 * 1024), 2);
$free_percent = (100 - $used);

echo "<p><h6>TOTAL HDD CAPACITY: </b>{$total_gb}GB</p>";
echo "<b>HDD Used: </b>$used% <b>or</b> {$used_gb}GB</p>";
echo "<b>HDD Free: </b>$free_percent% <b>or</b> {$free_gb}GB</h6>";

[Jammer]

Eric, I just noticed that the resulting output file from update_channels.php gives the time with DST....which is pretty odd since I'm in QLD.

[efry]

When i log into the timer page there are four times as many channels as i usually see on the beyonwiz. For example i get 10 copies of ten hd. How do i get rid of the excess and how do i know which ones to delete? Thanks

Hi orangehenry,

Tony suggested adding the LCN (Logical channel number??) to the channel name. This might clear up the confusion. I was also thinking about importing the fav list but that might just complicate things.

Eric

[tonymy01]

I think not only the LCN (yep, you got the acronym correct), but also the channel frequency. Some people get 10 from a few translators, and so knowing which LCN10 is also necessary (although they should really delete all the channels on frequencies where reception is poor).
Regards

[j s]

Some bad news - the presence of the wizremote directory on the HDD makes the HDD check fail.

see this post: http://www.beyonwiz.com.au/phpbb2/viewt ... 1233#21233

Of course if the Wiz never hangs and never gets a power failure then there's no problem.

[tonymy01]

AHa, that explains my situation also. The HDD check failed, I removed the offending file created during the fail (I was doing a TAR of everything to a file on the HDD which eventually crashed the wiz) and then the check still failed, but next reboot was ok. There is a file that needs to be copied (or is it removed...) to the hdd to fool it into not checking it, called the ".grace" file. I believe we can mod the HDD check app to not have a dummy spit perhaps?
Regards

[j s]

I have devised an alternative solution.

I put wizremote onto an SD card (at the root level) then modified rc.local to read:

Code: Select all

#!/bin/sh
# put this file in /tmp/config then reboot with wizremote.php to have wizremote start on boot
/bin/sleep 5
mkdir /tmp/mnt/card/wizremote
mount -t vfat /dev/scsi/host0/bus0/target0/lun2/part1 /tmp/mnt/card/wizremote
(cd /tmp/mnt/card/wizremote; ./wizremote > /dev/null &)

Insert the SD card into the slot, copy rc.local to /tmp/config as usual and reboot.

I also discovered that a normal reboot via the remote is necessary to make rc.local stick. A reboot from the wizremote webpage didn't do it.

The only drawback is that the flap in the S1 cannot be closed with the SD card in place

[j s]

Is there any reason why wizremote itself couldn't be placed into /tmp/config ? I think the whole directory is saved on shutdown and restored during boot.

Yep - it works!!

rc.local reads:

Code: Select all

#!/bin/sh
# put this file in /tmp/config then reboot with wizremote.php to have wizremote start on boot
/bin/sleep 5
(cd /tmp/config; ./wizremote > /dev/null &)

and

Code: Select all

# ls -l /tmp/config
-rw-rw-rw-    1 0        0             834 Dec 31  1969 book.xml
-rwxrwxrwx    1 0        0            3680 Dec 31  1969 fav.dat
-rw-rw-rw-    1 0        0               0 Dec 31  1969 favlist
-rw-r--r--    1 0        0             552 Dec 31  1969 iceCh
-rw-r--r--    1 0        0             557 Dec 31  1969 iceCh.bak
-rwx------    1 0        0             449 Dec 31  1969 iceDevList
-rw-r--r--    1 0        0            2205 Feb 25 16:29 main.conf
drwxrwxrwx    1 0        0               0 Dec 31  1969 network
drwxrwxrwx    1 0        0               0 Dec 31  1969 playlists
-rwxr-xr-x    1 0        0             162 Dec 31  1969 rc.local
-rwxr-xr-x    1 0        0             530 Dec 31  1969 reboot.sh
-rw-rw-rw-    1 0        0              23 Feb 25 16:28 resolv.conf
-rw-rw-rw-    1 0        0            2039 Dec 31  1969 smbsnapshot.conf
-rwxrwxrwx    1 0        0            3227 Dec 31  1969 svc.dat
-rwxr-xr-x    1 0        0           66432 Dec 31  1969 wizremote
-rwxr-xr-x    1 0        0              11 Dec 31  1969 wizremote.key

It also seems that /tmp/config will survive a firmware upgrade so once wizremote is in there's no need to hack the next release to get telnet in. This would also apply to an HDD install of wizremote

[rwhitby]

It also seems that /tmp/config will survive a firmware upgrade so once wizremote is in there's no need to hack the next release to get telnet in. This would also apply to an HDD install of wizremote

Having something survive a firmware upugrade can be a mixed blessing.

Imagine if you install an application which has a bug in it which causes your machine to continually reboot. If you can't get rid of it with a firmware upgrade, then you're in a permanent reboot loop.

-- Rod

[tonymy01]

Hi Rod,
In the other thread discussing this issue (why do we need 2 threads for the same prob..) I actually found the problem isn't that the directory exists on the HDD, the problem is that once Wizremote is running, the WizDVP app can't unmount the HDD to do a filesystem check on it. So last night I wrapped the umount up in a shell script to also "killall wizremote"... but unfortunately my process to rebuild the ROMFS linux.bin.gz is mucked up somewhere and my Wiz didn't boot past the boot loader with my newly built f/w... so need to work on this a bit. Another simple option is to make the wizremote startup conditional on the .grace file existing or not, as this is the file the Wiz uses to determine if the Wiz wasn't shut down properly (thanks to Eric for finding that too!)
I just figured wrapping the unmount was easier as this will also work for a user initiated HDD check (although if a user initiated, you could telnet in and kill the wizremote process first, albeit a bit
Regards

[efry]

Hi Rod,
In the other thread discussing this issue (why do we need 2 threads for the same prob..) I actually found the problem isn't that the directory exists on the HDD, the problem is that once Wizremote is running, the WizDVP app can't unmount the HDD to do a filesystem check on it. So last night I wrapped the umount up in a shell script to also "killall wizremote"... but unfortunately my process to rebuild the ROMFS linux.bin.gz is mucked up somewhere and my Wiz didn't boot past the boot loader with my newly built f/w... so need to work on this a bit. Another simple option is to make the wizremote startup conditional on the .grace file existing or not, as this is the file the Wiz uses to determine if the Wiz wasn't shut down properly (thanks to Eric for finding that too!)
I just figured wrapping the unmount was easier as this will also work for a user initiated HDD check (although if a user initiated, you could telnet in and kill the wizremote process first, albeit a bit
Regards

Hi Tony,

How about moving wizremote and wizremote.key to /tmp before running it.

in rc.local something like the following might do the trick.

Code: Select all

mkdir /tmp/wizremote
cp /tmp/mnt/idehdd/wizremote/* /tmp/wizremote/
(cd /tmp/wizremote; wizremote > /dev/null)

Eric

[DaveR]

I've moved this topic to the developer's area because it is still alpha and we don't want average users thinking it is ready for everyone to install on their main or only PVR.

[j s]

It also seems that /tmp/config will survive a firmware upgrade so once wizremote is in there's no need to hack the next release to get telnet in. This would also apply to an HDD install of wizremote

Having something survive a firmware upugrade can be a mixed blessing.

Imagine if you install an application which has a bug in it which causes your machine to continually reboot. If you can't get rid of it with a firmware upgrade, then you're in a permanent reboot loop.

-- Rod

Quite true! But that applies to having wizremote anywhere not removable as long as it's initiated by rc.local

The only way to make wizremote removable by firmware upgrade is either have the executable on removable storage or have it triggered by something other than rc.local
Perhaps by starting it (or running a script that starts it) in the same way that telnet gets started (hacking the start up script).

[rwhitby]

Having something survive a firmware upugrade can be a mixed blessing.

Imagine if you install an application which has a bug in it which causes your machine to continually reboot. If you can't get rid of it with a firmware upgrade, then you're in a permanent reboot loop.

Quite true! But that applies to having wizremote anywhere not removable as long as it's initiated by rc.local

The only way to make wizremote removable by firmware upgrade is either have the executable on removable storage or have it triggered by something other than rc.local

I think this is a key decision that we need to make to ensure that third-party software does not impact the support load for Beyonwiz, or even the false-return rate.

In the nslu2-linux.org project, we've always had a policy that we must never release something that can permanently disable or damage the device. A continuous reboot bug that cannot be solved by reflashing firmware would fall into this category.

So we must find a solution to the problem of how to automatically start third-party applications on reboot, but not have them automatically start on firmware reflash (i.e. you need to do a simple step to re-enable them on reflash). Alternatively, there must be a simple way to disable the startup of all third-party apps on boot (like holding the "0" key on boot for a Topfield device).

-- Rod

[IanSav]

Hi Rod,

So we must find a solution to the problem of how to automatically start third-party applications on reboot, but not have them automatically start on firmware reflash (i.e. you need to do a simple step to re-enable them on reflash). Alternatively, there must be a simple way to disable the startup of all third-party apps on boot (like holding the "0" key on boot for a Topfield device).

This will probably require some co-operation from Beyonwiz. It may take the form of some sort of access to IR commands or the menu interface so that external commands or menus can be externally integrated into the existing Beyonwiz structures.

Perhaps the access mechanism should be workshopped and the a firm proposal made to Beyonwiz for their consideration (and integration).

Regards,
Ian.

[tonymy01]

The 86XX uses /dev/ir for the IR receiving, so even if Beyonwiz won't co-operate, I reckon we can intercept the IR commands there.

[IanSav]

Hi Tony,

The 86XX uses /dev/ir for the IR receiving, so even if Beyonwiz won't co-operate, I reckon we can intercept the IR commands there.

I would hazard a guess that assuming the Beyonwiz programs don't have an exclusive open on the device that pulling received IR commands from the device would probably make a mess of the Beyonwiz programs.

Co-operation would be a better way.

Regards,
Ian.

[efry]

So we must find a solution to the problem of how to automatically start third-party applications on reboot, but not have them automatically start on firmware reflash (i.e. you need to do a simple step to re-enable them on reflash). Alternatively, there must be a simple way to disable the startup of all third-party apps on boot (like holding the "0" key on boot for a Topfield device).

-- Rod

Hi Rod,

I use a similar approach for my alternative rc.sysinit hack. I check micomparam to see whether the unit (DP-S1) was booted with the eject button.

I only run my script if the unit was booted normally. If it was booted using the eject button or there was an error communicating with micomparam I don't run the custom script.

This way I can boot the unit even if my test script hangs.

Obviously this is a S1 solution only

Here's the start of my modified rc.sysint script.

Code: Select all

#!/bin/sh
# FILE : /etc/rc.sysinit.DPS1
export PATH=/bin:/sbin:/usr/bin:/usr/sbin:/usr/local/bin:/flash/bin
CONFIG_DIR=/tmp/config

mount -t romfs /dev/blkmem/1 /flash
sys_up -b

# LiDiC device files
mknod /dev/video0 c 81 0
mknod /dev/video10 c 81 10
RET=`micomparam -r E10101`
CFG=/mnt/config
if [ "$RET" = "E10101 FEE1020100FF" ];then
	bootcramfs
	if [ -f "${CFG}/rc.test" ];then
		cp ${CFG}/rc.test /tmp
		umount ${CFG} 
		/tmp/rc.test
		exit
	fi
	umount ${CFG} 
fi
# start and wait for wizmon; alloc memory first
cd /flash/wizdvp
./wizdvp -dump-from-romfs &
#./wizdvp -dump-from-romfs > /dev/null 2>&1 &

It checks the way the system was booted and then tries to run rc.test. If it was found on the config partition.

Eric

[j s]

I was thinking of a simple approach (based on my limited Linux knowledge) of a line in rc.sysinit starting (say) /tmp/config/rc.hack which would in turn start any of the experimental hacks that might come along. A reflash to a standard firmware would revert rc.sysinit to standard thus removing the trigger for the hacks

[tonymy01]

That is what I am attempting to do now, but I have hit a problem:
This is my rc.local file:
#!/bin/sh
if [ -f "/tmp/mnt/idehdd/.grace" ];then
(cd /tmp/mnt/idehdd/wiz/etc; . ./rc.local2 >/dev/null &)
fi

Essentially this .grace file is created at shutdown, so that if the Wiz doesn't detect it next power up, it means probably the wiz wasn't shutdown properly so it does a disc check. As we have found out, it can't do a disc check with applications running from the mounted partition (hmm, I wonder if we can make, say, a 2G partition on the HDD to have applications etc on.... this seems the most feasible way of putting apps in without fear of filling the flash or RAM with apps that may only be called once). So this simply will not run anything from rc.local2 if there is no grace file. This still doesn't help a user initiated disc check, but helps for the crashed and or power fail situation.

Even if I comment out the if and fi lines, it doesn't seem to want to launch a shell script from rc.local at bootup, but works fine when I run rc.local from a shell.
I am no shell programming expert, so this is annoying me a bit (I of course had the much simpler /tmp/mnt/idehdd/wiz/etc/rc.local2& line in there, but this failed, so thought I would use Eric's syntax for launching Wizremote with . It is like the HDD isn't mounted at this point, but that doesn't make a whole lot of sense because I can launch Wizremote off the HDD the same way!?
I also wanted to add /wiz/bin to the PATH, but this isn't possible from a shell script because the environment variables are only valid for the process they run in, so once rc.local2 terminates (well, and rc.local in the example above) the PATH variable reverts back to default. It would be good if I could easily generate the ROMFS, but last time I tried, the Wiz was basically a brick.... then I would simply edit rc.sysinit to have my extended PATH (I can probably still do that with hex hacking like we did to add the telnet hack in, but would have to delete a few comments out of rc.sysinit to make room...)

I guess the above will fail anyway if the Wiz jumps in and deletes the .grace file before the script gets to run.
Regards

[efry]

I was thinking of a simple approach (based on my limited Linux knowledge) of a line in rc.sysinit starting (say) /tmp/config/rc.hack which would in turn start any of the experimental hacks that might come along. A reflash to a standard firmware would revert rc.sysinit to standard thus removing the trigger for the hacks

Hi j s,

I don't think the config flash partitions are touched in a firmware update.

Eric

[efry]

That is what I am attempting to do now, but I have hit a problem:
This is my rc.local file:
#!/bin/sh
if [ -f "/tmp/mnt/idehdd/.grace" ];then
(cd /tmp/mnt/idehdd/wiz/etc; . ./rc.local2 >/dev/null &)
fi

Essentially this .grace file is created at shutdown, so that if the Wiz doesn't detect it next power up, it means probably the wiz wasn't shutdown properly so it does a disc check. As we have found out, it can't do a disc check with applications running from the mounted partition (hmm, I wonder if we can make, say, a 2G partition on the HDD to have applications etc on.... this seems the most feasible way of putting apps in without fear of filling the flash or RAM with apps that may only be called once). So this simply will not run anything from rc.local2 if there is no grace file. This still doesn't help a user initiated disc check, but helps for the crashed and or power fail situation.

Even if I comment out the if and fi lines, it doesn't seem to want to launch a shell script from rc.local at bootup, but works fine when I run rc.local from a shell.
I am no shell programming expert, so this is annoying me a bit (I of course had the much simpler /tmp/mnt/idehdd/wiz/etc/rc.local2& line in there, but this failed, so thought I would use Eric's syntax for launching Wizremote with . It is like the HDD isn't mounted at this point, but that doesn't make a whole lot of sense because I can launch Wizremote off the HDD the same way!?
I also wanted to add /wiz/bin to the PATH, but this isn't possible from a shell script because the environment variables are only valid for the process they run in, so once rc.local2 terminates (well, and rc.local in the example above) the PATH variable reverts back to default. It would be good if I could easily generate the ROMFS, but last time I tried, the Wiz was basically a brick.... then I would simply edit rc.sysinit to have my extended PATH (I can probably still do that with hex hacking like we did to add the telnet hack in, but would have to delete a few comments out of rc.sysinit to make room...)

I guess the above will fail anyway if the Wiz jumps in and deletes the .grace file before the script gets to run.
Regards

Hi Tony,

A few things I can see here. You don't have a sleep before looking for the files on the HDD. The HDD is mounted by the wizdvp app. I'm not sure when this happens so to get it to work I just put my rc.local file to sleep for awhile. By the time I tried to run wizremote the HDD had been mounted by wizdvp.

Also like you said the wizdvp app deletes the .grace file when it starts.

Eric

[prl]

I was under the impression it was more than that and would support similar functions to WizRemote.

I just had a bit of a closer look at it. It seems to contain SHTTPD, which does in fact support CGI.

I've been having a bit more of a poke around in wizpnp, and though it does appear to contain SHTTPD, and the SHTTPD source has CGI and HTTPS support, they are both compile-time options, and Beyonwiz has chosen to switch them off.

Further, although wizpnp contains the path to the SHTTPD /etc/shttpd.conf file, I haven't been able to switch on the "list_directories" SHTTPD option using /etc/shttpd.conf.

[prl]

A bit more decoding of the services table in svc.dat (all values interpreted as little-endian shorts):

Code: Select all

                              video audio                     svc        chan
radio valid chanX xxxxx svcId   PID   PID xxxxx xxxxx xxxxx nameX xxxxx nameX xxxxx XXXXX XXXXX   lcn xxxxx
 0000  0301  0000  0160  0807  0161  0162  0161  0001  0000  0000  0000  0000  0000  0009  0002  0005  0008  SC10 Canberra
    0   769     0   352  2055   353   354   353     1     0     0     0     0     0     9     2     5     8
 0000  0301  0000  06ae  0827  06af  86b0  06af  0001  0000  000e  0000  0000  0000  000a  000c  0032  0009  SC10 HD
    0   769     0  1710  2087  1711 34480  1711     1     0    14     0     0     0    10    12    50     9
 0000  0301  0004  0102  0210  090a  890b  0905  0001  0000  00c3  0000  0018  0000  0004  0005  0014  0009  ABC HDTV
    0   769     4   258   528  2314 35083  2309     1     0   195     0    24     0     4     5    20     9
 0000  0301  0004  0100  0211  0200  028a  0080  0001  0000  00cc  0000  0018  0000  000c  0000  0002  0000  ABC1
    0   769     4   256   529   512   650   128     1     0   204     0    24     0    12     0     2     0
 0007  0000  0004  0106  0214  0200  028a  0080  0001  0000  00c3  0000  0018  0000  ffff  0004  0017  0000  (deleted entry)
    7     0     4   262   532   512   650   128     1     0   195     0    24     0 65535     4    23     0

• The radio flag had value 7 on the two deleted lines in my svc.dat.
• The valid entry was 0 in the deleted lines in my svc.dat. Otherwise 0x0301.
• The audio PID entry appears to be for the "main" audio stream. Other audio streams in the service aren't listed.
• The columns before and after the two PID columns also look like PIDs. The one after the audio PID column often, but not always, has the same value as the video PID.
• The 0x8000 bit in the audio PID appears to be a flag for "true HD", i.e. 720p or better. In any case it was set on all HD services in Canberra except SBS HD, and it needs to be stripped to get the actual audio PID. So, for example, the actual audio PID for SC 10 HD is 0x06b0=1712, not 0x86b0.
• svc nameX and chan nameX are the indexes into the respective service and channel name string arrays earlier in the svc.dat file. I don't think the channel name index has been reported before.
• The two columns marked XXXXX appear to be indexes into a table of 4-byte entries starting 12 bytes after the end of the channel names table. The length of that table is the little-endian short 10 bytes from the end of the channel names table. This may mean that the 88 (0x58) byte offset from the end of the channel names table to the services table is not (in principle) fixed, but dependent on the length of the table that (might be) pointed to by the XXXXX columns.
• In that table, the first byte is (almost) just a counter in the Black Mountain transmitters svc.dat. The second byte is always either 4, 8 or 16. In my data the table runs: (0, 4), (1, 4), (2, 4), (3, 4), (4, 8), (5, 8), (6, 8), (7, 8), (8, 8), (9, 8), (10, 4), (11, 4), (12, 8), (13, 16), (14, 16), (15, 8), (17, 8), (16, 8), (18, 8). The first byte sequence (15, 17, 16, 18) is not a typo; that's how the data is in my svc.dat.
• The left-hand XXXXX column had value 0xffff in for the two deleted lines in my svc.dat.

[tonymy01]

Thanks Peter. The Topfield 5K has an extra bit on the audio pid too, only for AC3. I think it is an AC3 flag personally.
Regards

[prl]

Thanks Peter. The Topfield 5K has an extra bit on the audio pid too, only for AC3. I think it is an AC3 flag personally.
Regards

That makes sense.

[prl]

I wonder whether the two XXXXX columns are parameters for tuner1 & tuner2. If they are, I don't understand why they different for the same (presumed) tuner between services on the same channel, unless the tuner is doing some of the stream demuxing. For example, the (possible) tuner 1 entries for SC10 are 2 for SD and 12 for HD (but the variation isn't just between SD and HD channels).

[prl]

After looking at Tony's old post with a pair of svc table entries, and comparing with this fairly full table of Sydney broadcaster's PIDs, I think a couple more table values can be identified:

Code: Select all

                    PMT       video audio   PCR               svc        chan       tunerParams
radio valid chanX   PID svcId   PID   PID   PID CONST CONST nameX CONST nameX CONST    t1    t2   lcn xxxxx
 0000  0301  0000  0160  0807  0161  0162  0161  0001  0000  0000  0000  0000  0000  0009  0002  0005  0008  SC10 Canberra
    0   769     0   352  2055   353   354   353     1     0     0     0     0     0     9     2     5     8
 0000  0301  0000  06ae  0827  06af  86b0  06af  0001  0000  000e  0000  0000  0000  000a  000c  0032  0009  SC10 HD
    0   769     0  1710  2087  1711 34480  1711     1     0    14     0     0     0    10    12    50     9
 0000  0301  0004  0102  0210  090a  890b  0905  0001  0000  00c3  0000  0018  0000  0004  0005  0014  0009  ABC HDTV
    0   769     4   258   528  2314 35083  2309     1     0   195     0    24     0     4     5    20     9
 0000  0301  0004  0100  0211  0200  028a  0080  0001  0000  00cc  0000  0018  0000  000c  0000  0002  0000  ABC1
    0   769     4   256   529   512   650   128     1     0   204     0    24     0    12     0     2     0
 0007  0000  0004  0106  0214  0200  028a  0080  0001  0000  00c3  0000  0018  0000  ffff  0004  0017  0000  (deleted entry)
    7     0     4   262   532   512   650   128     1     0   195     0    24     0 65535     4    23     0

From Tony's post and the table of PIDs, it appears that the first PID column is the PMT (Program Map Table) and the last one is the PCR (Program Clock Reference). I've put in tentative names for the tuner parameter index columns, too. There are three columns whose values are all either 0 or 1 in the Black Mountain data, and I've marked them CONST. There's only one remaining column without at least a tentative explanation, the last one. In the Black Mountain data all its entries are either 0, 8, 9 or 12.

Tony (or someone else in Sydney), could you check my guesses about the PMT and PCR PIDs against the PID table in the link above? In particular for ABC and Ten, which use different PIDs for video and PCR.

Any guesses on the last column? Curiously, in the Canberra data, the last column is 8 for ABC1 on LCN 2, but 0 for ABC1 on LCN 21!

If my interpretation of the PMT and PCR columns is correct, then I think this also gives 4 of the 6 "hidden" values at the start of the header.tvwiz file. They are, in order, (unknown1, unknown2, videoPID, audioPID, PCRPID, PMTPID). In the data I've looked at unknown1 is always 4194 (0x1062, bytes 0x62, 0x10), and unknown2 is always 3 or 4. The 0x1062 may simply be a "magic number". That may also be the case for the 0xbe90s in svc.dat.

Edit: There are some more PID tables (but not for Canberra Black Mountain )on the DTV forum here: http://www.dtvforum.info/index.php?showtopic=52

[jim16]

Hi All,

Is there a telnet patched firmware available for the DP-P2? If not are there some instructions on how to enable telnet? Just purchased a device and want to get stuck into implementing my pvrtimersd application and running this tool for the wiz for it to become my primary PVR. Before a suggestion is made to use ICE for setting timers, they don't provide a guide for my region so i'm stuck.

Regards

jim16