WizRemote - Set timers on your wiz remotely via the web!
Nice pickup KezzaKezza wrote:changed line 100 and it works a treat, thanks
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
wizRemote v0.7
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
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.
Hi Gary,Jammer wrote: 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
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
Re: wizRemote v0.7
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.efry wrote: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.
-
- Wizard God
- Posts: 32706
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
Re: wizRemote v0.7
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.Jammer wrote: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 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.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
-
- Apprentice
- Posts: 14
- Joined: Fri Nov 30, 2007 09:01
still wont work
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
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
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.Jammer wrote: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?
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";
Code: Select all
//$GLOBALS["wiz_ip"] = "localhost";
$GLOBALS["wiz_ip"] = "192.168.1.102";
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.
cheers
DaveR
IceTV, T4, T3, T2, P2, S1, FV-L1(P1 fw), TRF-2460, HDR-7500 and Skippa
DaveR
IceTV, T4, T3, T2, P2, S1, FV-L1(P1 fw), TRF-2460, HDR-7500 and Skippa
-
- Apprentice
- Posts: 14
- Joined: Fri Nov 30, 2007 09:01
That made everything work. Thanks heaps!Dave? wrote: Eric: To prevent people getting a blank page after the log-in page you should change the defaults in config_inc.php from this:to this:Code: Select all
$GLOBALS["wiz_ip"] = "localhost"; //$GLOBALS["wiz_ip"] = "192.168.1.102";
Code: Select all
//$GLOBALS["wiz_ip"] = "localhost"; $GLOBALS["wiz_ip"] = "192.168.1.102";
Hi Gary,Jammer wrote:Yeah, just got 'em. Have been out all morning. Will PM you back a bit later.Kezza wrote:did you get my PM's Jammer?
Kezza
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
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
Hi Dave,
Eric
No problem, I've changed it and will update it with the next version.Dave? wrote: Eric: To prevent people getting a blank page after the log-in page you should change the defaults in config_inc.php from this: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 commentsCode: Select all
//$GLOBALS["wiz_ip"] = "localhost"; $GLOBALS["wiz_ip"] = "192.168.1.102";
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?Dave? wrote: 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.
Eric
- tonymy01
- Uber Wizard
- Posts: 6373
- Joined: Fri Jun 01, 2007 15:25
- Location: Sydney, Australia DP-S1-1TB, DP-P2-2TB, DP-T4-2TB, DP-T4-BB... too many!
- Contact:
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
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
Tony
Nah, I'm just running it on Windows. I originally created the config_channels_inc.php manually so will just continue to use this.efry wrote: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
-
- Apprentice
- Posts: 14
- Joined: Fri Nov 30, 2007 09:01
Too many channels
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 Tony,tonymy01 wrote: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
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
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>";
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>";
Last edited by Jammer on Mon Feb 18, 2008 19:28, edited 2 times in total.
Re: Too many channels
Hi orangehenry,orangehenry wrote: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
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
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.
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
- Uber Wizard
- Posts: 6373
- Joined: Fri Jun 01, 2007 15:25
- Location: Sydney, Australia DP-S1-1TB, DP-P2-2TB, DP-T4-2TB, DP-T4-BB... too many!
- Contact:
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
Regards
Tony
I have devised an alternative solution.
I put wizremote onto an SD card (at the root level) then modified rc.local to read:
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
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
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:
and
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
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 &)
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
- rwhitby
- Apprentice
- Posts: 37
- Joined: Tue Aug 28, 2007 17:41
- Location: Adelaide, Australia Project:http://www.openwiz.org Hardware:DP-P1, LiDiC
Having something survive a firmware upugrade can be a mixed blessing.j s wrote: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
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
- Uber Wizard
- Posts: 6373
- Joined: Fri Jun 01, 2007 15:25
- Location: Sydney, Australia DP-S1-1TB, DP-P2-2TB, DP-T4-2TB, DP-T4-BB... too many!
- Contact:
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
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
Tony
Hi Tony,tonymy01 wrote: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
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)
Quite true! But that applies to having wizremote anywhere not removable as long as it's initiated by rc.localrwhitby wrote:Having something survive a firmware upugrade can be a mixed blessing.j s wrote: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
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
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
- Apprentice
- Posts: 37
- Joined: Tue Aug 28, 2007 17:41
- Location: Adelaide, Australia Project:http://www.openwiz.org Hardware:DP-P1, LiDiC
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.j s wrote:Quite true! But that applies to having wizremote anywhere not removable as long as it's initiated by rc.localrwhitby wrote: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.
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
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
Hi Rod,
Perhaps the access mechanism should be workshopped and the a firm proposal made to Beyonwiz for their consideration (and integration).
Regards,
Ian.
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.rwhitby wrote: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).
Perhaps the access mechanism should be workshopped and the a firm proposal made to Beyonwiz for their consideration (and integration).
Regards,
Ian.
Hi Tony,
Co-operation would be a better way.
Regards,
Ian.
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.tonymy01 wrote: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.
Co-operation would be a better way.
Regards,
Ian.
Hi Rod,rwhitby wrote: 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
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 &
Eric
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
- Uber Wizard
- Posts: 6373
- Joined: Fri Jun 01, 2007 15:25
- Location: Sydney, Australia DP-S1-1TB, DP-P2-2TB, DP-T4-2TB, DP-T4-BB... too many!
- Contact:
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
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
Tony
Hi j s,j s wrote: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
I don't think the config flash partitions are touched in a firmware update.
Eric
Hi Tony,tonymy01 wrote: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
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
-
- Wizard God
- Posts: 32706
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
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.prl wrote:I just had a bit of a closer look at it. It seems to contain SHTTPD, which does in fact support CGI.Gully wrote:I was under the impression it was more than that and would support similar functions to WizRemote.
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.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
-
- Wizard God
- Posts: 32706
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
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.
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
-
- Wizard God
- Posts: 32706
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
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).
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
-
- Wizard God
- Posts: 32706
- Joined: Tue Sep 04, 2007 13:49
- Location: Canberra; Black Mountain Tower transmitters
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:
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
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
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
Peter
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
T4 HDMI
U4, T4, T3, T2, V2 test/development machines
Sony BDV-9200W HT system
LG OLED55C9PTA 55" OLED TV
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
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