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

efry · Post by **efry** » Mon Jan 28, 2008 23:14

Hey Guys,

I got sick of waiting for iceRemote support so I made my own remote timer system.

It's really just a proof of concept at this stage. It lacks input validation and security but you can list current timers and add new timers via the web.

Here's the link to the app/code.

http://www.beyonwizsoftware.net/softwar ... te-v0-1/0/

Current version 0.3

Code: Select all

0.3 * Fixed some memory leaks in wizremote
    * Added the ability to delete timers
    * Added the ability for the daemon to process mulitiple commands
      in a single connection
    * Added a 'Save and Reboot' button to the website. Don't 
      automatically reboot when adding new timers.

Here's a picture of the web interface looking at the timers on my wiz.

Enjoy!

Eric[/code]

janilxx · Post by **janilxx** » Mon Jan 28, 2008 23:45

It didn't take too long to get first timer creation application!
Nice work!

This is a proof that http://www.beyonwizsoftware.net/ is really needed

Even BW does not publish API for applications, there is still skilled "hackers" available. Sorry BW

Now I would like to get all kind of guides how to do this kind of tricks into www.beyonwizsoftware.net 's wiki (which is still under construction, but can be accessed from http://wiki.beyonwizsoftware.net/ ).

tonymy01 · Post by **tonymy01** » Mon Jan 28, 2008 23:47

Woohoo, I knew someone would do it!
Ok, you say "I don't know how tsid,onid and svcid numbers are generated yet.

". Well, these aren't "generated", they are actually parameters sent via the broadcaster, and vary from state to state of course. How you are doing it, by sucking out the details from existing timers, is probably the easiest way to map channels vs these IDs, unless you discover the stored channel tables in the Wiz.
Regards

peteru · Post by **peteru** » Tue Jan 29, 2008 02:22

Where did you find a cross-compiler?

jpp · Post by **jpp** » Tue Jan 29, 2008 07:21

Well, I hope that this shows the Wiz engineers that we really do have very capable people, eager and willing to make the Wiz a better machine and will spur them on to release APIs. I also hope that it will spur them on in completing the next FW upgrade - it's been far too long in my opinion since the last one. It's now well nigh a year since the introduction of the unit and we still don't have some of the promised functions/features.

[start of broken record] By releasing API's, we can speed up the process of adding features. [/end of broken record]

np · Post by np » Tue Jan 29, 2008 08:42

This looks excellent but any chance someone could give me a step by step installation guide ?

Do I need a web server running on my machine (IIS?)
Do I need php installed on my machine ?

Etc.

Thanks!
Nick

Gully · Post by **Gully** » Tue Jan 29, 2008 08:42

Phil

The next beta is in the planning stage already with some work progressing.

There has already been some discussion about releasing access to timers and while you might think wizremote's creation suggests it is no longer needed, we might be able to get to the point where users don't need to hack the firmware to use wizremote and similar programs.

jpp · Post by **jpp** » Tue Jan 29, 2008 09:01

Thanks for the update Gully. I hope that in time we will get access to more parts of the FW so that we can add a suite of BWAPs like we can on the Toppy - with an alternative EPG high on my list as you (all) already well know

.

efry · Post by **efry** » Tue Jan 29, 2008 09:13

peteru wrote:Where did you find a cross-compiler?

Hi Peter,

I got the toolchain sources from the following URL

http://www.services.digitus.de/data/dow ... 900.tar.gz

It looks like this company has complied with the GPL license and released the sigma patches.

I'm hoping Beyonwiz will play nice and release their GPL'd code soon too.

It was a real pain compiling it up on my mac. The elf2flt application is only really designed to be compiled under linux and apple doesn't like you compiling static apps.
I think some of the kernel build config files are missing too.

Eric

prl · Post by **prl** » Tue Jan 29, 2008 09:55

efry wrote:
peteru wrote:Where did you find a cross-compiler?
Hi Peter,

I got the toolchain sources from the following URL

http://www.services.digitus.de/data/dow ... 900.tar.gz

It looks like this company has complied with the GPL license and released the sigma patches. I'm hoping Beyonwiz will play nice and release their GPL'd code soon too.

It was a real pain compiling it up on my mac. The elf2flt application is only really designed to be compiled under linux and apple doesn't like you compiling static apps.
I think some of the kernel build config files are missing too.

Eric

I doubt that much of the interesting code for this problem is GPL. Kernel sources for the uClinux for the Sigma Data chip are available from the uClinux port list (unfortunately, I haven't been able to access the uClinux site for several days). The main applications that run on uClinux to drive the Beyonwiz as a PVR are, I suspect, not going to be made publicly available by Beyonwiz.

efry · Post by **efry** » Tue Jan 29, 2008 10:41

prl wrote:I doubt that much of the interesting code for this problem is GPL. Kernel sources for the uClinux for the Sigma Data chip are available from the uClinux port list (unfortunately, I haven't been able to access the uClinux site for several days). The main applications that run on uClinux to drive the Beyonwiz as a PVR are, I suspect, not going to be made publicly available by Beyonwiz.

Hi Prl,

The code on the uclinux site is for the em8500 as far as I can tell. We need the patches for the em86xx.

Yeah it would be really nice if Beyonwiz opened up wizdvp and friends but I don't think that would ever happen.

All I'm asking for is that they release patches sufficient for me to rebuild the linux kernel, uclibc and busybox. As required by the GPL license.

Eric

Jammer · Post by **Jammer** » Tue Jan 29, 2008 11:12

This is damn awesome! Great work

peteru · Post by **peteru** » Tue Jan 29, 2008 14:21

Good work Eric.

This document is interesting: http://www.services.assmann.com/downloa ... -70900.pdf

I would expect Beyonwiz to prepare a similar release. The GPL clearly requires them to do so. Furthermore, they must supply the source code and tools - it is not good enough to point people at a third party site, like ucLinux. Not to mention that ucLinux does not have any working EM86xx resources.

I don't mind if the Beyonwiz release is a bit rough around the edges as long as there is enough to completely rebuild the kernel and any GPL or LGPL software. I am quite happy to run the Beyonwiz software, but I also want access to the underlying platform to customise/improve it.

alwayslooking · Post by **alwayslooking** » Tue Jan 29, 2008 18:08

np wrote:This looks excellent but any chance someone could give me a step by step installation guide ?

Do I need a web server running on my machine (IIS?)

Do I need php installed on my machine ?

The instructions are in a readme with the download...but you will need telnet access to your BW, which requires a firmware hack.

vdc · Post by **vdc** » Tue Jan 29, 2008 20:34

Okay I'm sold now!

Im heading down to jb/harvey/goodguys to see who can give me the best price. This kind of enduser development is just what i was waiting for!

j s · Post by **j s** » Tue Jan 29, 2008 21:10

I'm probably starting the obvious but there might be someone who needs reminding....

If anyone currently running ToppyWeb wants to play with efry's new toy then wherever you are running TW can also be used to run wizremote.php.

j s · Post by **j s** » Wed Jan 30, 2008 05:50

Some questions for efry....

1) Is it necessary to reboot every time a timer is added or could several timers be added and then reboot? Would it be better to disassociate these two actions in the daemon and let the php code request the reboot when finished adding timers?

2) Could the same technique used for adding a timer be used to modify or delete existing timers?

alwayslooking · Post by **alwayslooking** » Wed Jan 30, 2008 07:16

JS,
Do you have any plans to implement what Eric has done in TW? (or was that a given

)
I wonder how far along Dave is with the firmware patch/hack tool?

Jammer · Post by **Jammer** » Wed Jan 30, 2008 08:16

alwayslooking wrote:JS,
Do you have any plans to implement what Eric has done in TW? (or was that a given )
I wonder how far along Dave is with the firmware patch/hack tool?

I'm wondering the same things......

IanSav · Post by **IanSav** » Wed Jan 30, 2008 08:30

Hi Guys,

I suggest a little patience here.

Before people rush out and modify their firmware to add Eric's code, and thus deny their access to support, I thought I should warn people that Beyonwiz appears to be creating a http based timer setting API. I suggest that will be an authorised and supported interface to the timers. I can't say when this interface will be released but reading a recent post from a Beyonwiz engineer makes it sound like something that will be coming sooner rather than later. (We had been speculating on the internal format of timers when we were told that this interface was going to be formalised and that all the parameters and details for working with the interface would be documented.)

If people are going to modify their Toppy based programs to also work with the Beyonwiz then I thought they should be aware of the more formal solution that is coming. If this feature is added to a Beta then I am sure somone will confirm the details at that time.

Regards,
Ian.

efry · Post by **efry** » Wed Jan 30, 2008 08:43

j s wrote:Some questions for efry....

1) Is it necessary to reboot every time a timer is added or could several timers be added and then reboot? Would it be better to disassociate these two actions in the daemon and let the php code request the reboot when finished adding timers?

2) Could the same technique used for adding a timer be used to modify or delete existing timers?

Hi j s,

We shouldn't have to reboot every time. I just did it that way to save time. I've started a little todo list and I've put that on the list.

I'm also planning to allow editing and deleting of existing timers.

I have just posted an updated version which contains some more javascript input validation and the todo list.

You can download it from here
http://www.beyonwizsoftware.net/softwar ... ;attach=26

Code: Select all

TODO List

* Client/daemon authentication (AES handshake token)
* Website user authentication
* Input checking for duplicate/overlapping timers.
* Delete timer
* Edit timer
* Allow multiple timer edits before save/reboot.
* Display the current beyonwiz time on website.
* Add more robust network handling.
* General code cleanup. More error handling.

If you have any other suggestions please let me know. :)

Eric

jpp · Post by **jpp** » Wed Jan 30, 2008 10:37

IanSav wrote:Hi Guys,

I suggest a little patience here.

Before people rush out and modify their firmware to add Eric's code, and thus deny their access to support, I thought I should warn people that Beyonwiz appears to be creating a http based timer setting API. I suggest that will be an authorised and supported interface to the timers. I can't say when this interface will be released but reading a recent post from a Beyonwiz engineer makes it sound like something that will be coming sooner rather than later. (We had been speculating on the internal format of timers when we were told that this interface was going to be formalised and that all the parameters and details for working with the interface would be documented.)

If people are going to modify their Toppy based programs to also work with the Beyonwiz then I thought they should be aware of the more formal solution that is coming. If this feature is added to a Beta then I am sure somone will confirm the details at that time.

Regards,
Ian.

G'day Ian,

I think the genie is out of the bottle now

- Eric has wet the appetite of others to get stuck into the code and prise it apart. I agree with you in principle that using an approved API is the better way to go, but so far it looks like we may only be getting one to the timers, certainly in the short term. I think many of our budding programmers are chomping at the bit to implement some of the other beaut Toppy Taps, and getting stuck into/breaking someone else's code always presents a challenge that is hard to resist

.

For those of us that want to play with Eric?s FW can always just reload the latest official FW, so I don't see that as a deal breaker/impediment as long as the FW loader doesn't get touched. I can't see any reason that buggy FW could damage the Wiz in any away.

So, to those who love tinkering with their Wiz and those who love the challenge of "breaking into it" with new FW, go for it!

.

IanSav · Post by **IanSav** » Wed Jan 30, 2008 11:33

Hi Phil,

I agree that people could/should still keep exploring their Beyonwiz units.

I just wanted to let people know what I believe is coming so that they wouldn't expend all their energy, enthusiasm and effort on the hacked interface to the detriment of supporting the official interface.

I must also express my concerns for people who may experience issues with their PVRs after installing any 3rd party software or hacks. This would obviously be totally unsupportable by Beyonwiz. If anyone installs or tries any firmware hacks then please ensure that you restore your unit to an official firmware with official settings so that you can verify any problems before posting or submitting a bug report.

It should also be noted that the telnet hack required to install WizRemote is for an older version of firmware that does not have all the latest fixes (particularly for DP-S1 and/or LiDiC owners).

Regards,
Ian.

jpp · Post by **jpp** » Wed Jan 30, 2008 11:38

IanSav wrote:Hi Phil,.....

I must also express my concerns for people who may experience issues with their PVRs after installing any 3rd party software or hacks. This would obviously be totally unsupportable by Beyonwiz. If anyone installs or tries any firmware hacks then please ensure that you restore your unit to an official firmware with official settings so that you can verify any problems before posting or submitting a bug report.

Regards,
Ian.

Totally agree Ian. T'was/is always thus with the Toppy.

It's obviously a decision for the moderators, but, to avoid newbies getting confused with modified FW discussions, I would suggest that these discussions should only be carried out on the Beyonz Wiz 3rd Party Sofware Site here:

http://www.beyonwizsoftware.net/index.php

peteru · Post by **peteru** » Wed Jan 30, 2008 13:14

jpp wrote:I would suggest that these discussions should only be carried out on the Beyonz Wiz 3rd Party Sofware Site

I won't be participating. It's difficult enough to keep up with this forum - I just don't have enough cycles to regularly visit another site.

I think that by far the best option is to keep everything in one place. That's how you build strong communities.

Jammer · Post by **Jammer** » Wed Jan 30, 2008 15:28

peteru wrote:I won't be participating. It's difficult enough to keep up with this forum - I just don't have enough cycles to regularly visit another site.

I think that by far the best option is to keep everything in one place. That's how you build strong communities.

Agreed. Perhaps this discussion could take place in the Beta section instead??

jpp · Post by **jpp** » Wed Jan 30, 2008 15:51

Jammer wrote:
peteru wrote:I won't be participating. It's difficult enough to keep up with this forum - I just don't have enough cycles to regularly visit another site.

I think that by far the best option is to keep everything in one place. That's how you build strong communities.
Agreed. Perhaps this discussion could take place in the Beta section instead??

But that would preclude most of us?

. What about setting up a separate topic/section on this Forum then?

janilxx · Post by **janilxx** » Wed Jan 30, 2008 16:03

peteru wrote:
jpp wrote:I would suggest that these discussions should only be carried out on the Beyonz Wiz 3rd Party Sofware Site
I won't be participating. It's difficult enough to keep up with this forum - I just don't have enough cycles to regularly visit another site.

May I suggest some practises that will make it easier to follow what happens in http://www.beyonwizsoftware.net/
1. Register into that site and start using User box's Show unread link (e.g. bookmark it: http://www.beyonwizsoftware.net/index.php?action=unread )
2. Start getting notifications when new posts arrive into topics (open topic and use Notify button).
3. Use RSS reader to read all new messages:
Default RSS feed is this: http://www.beyonwizsoftware.net/index.p ... ction=.xml
You can edit this URL to customize it, read guide here: http://www.simplemachines.org/community ... ic=25009.0
For example this gives 20 recent posts: http://www.beyonwizsoftware.net/index.p ... t;limit=20

I think that by far the best option is to keep everything in one place. That's how you build strong communities.

True, but BW will conquer the world. You Australians there in your island will not be alone soon. And if you then want to keep track of all BW software, you have to get out of this forum, sorry.

IanSav · Post by **IanSav** » Wed Jan 30, 2008 16:15

Hi,

peteru wrote:I won't be participating. It's difficult enough to keep up with this forum - I just don't have enough cycles to regularly visit another site.

I think that by far the best option is to keep everything in one place. That's how you build strong communities.

I couldn't agree more. I have more than enough sites to follow as it is now. I don't want to add any more - particularly when the chances of duplication are so high.

Regards,
Ian.

IanSav · Post by **IanSav** » Wed Jan 30, 2008 16:20

Hi Janilxx,

As Beyonwiz moves into other markets hopefully they will open their own forum website (there is a place reserved for it now) and we can all move there. Many companies host a single forum for their users all over the world. Smaller regional forums don't seem to work as well as larger forums. The Infrant/Netgear forum is a good example of an international forum as there are channels run in different languages for the different users but all the information is shared in the one place.

Regards,
Ian.

j s · Post by **j s** » Wed Jan 30, 2008 16:24

alwayslooking wrote:JS,
Do you have any plans to implement what Eric has done in TW? (or was that a given )

It's a given!! But you've ruined the surprise now!

You probably guessed that was the reason for my questions to efry. As an interim measure just drop efry's php and gif files into your TW folder and link to the page manually.

Even though it is alpha code it's worth supporting from TW. It might just help to put more pressure on Wiz to add a proper interface.

I'm midway thru some other coding so I need to get that to a completion point before starting this. I plan to do this like a "plug-in" so that the Wiz code can thereafter be updated independently of the main TW code - for example if Wiz themselves release an alternative method.

The most difficult thing I'll need help with - what to call the combined product? At this alpha stage it stay as TW but any thoughts on the issue would be welcome.

janilxx · Post by **janilxx** » Wed Jan 30, 2008 16:27

IanSav wrote: As Beyonwiz moves into other markets hopefully they will open their own forum website (there is a place reserved for it now) and we can all move there. Many companies host a single forum for their users all over the world. Smaller regional forums don't seem to work as well as larger forums. The Infrant/Netgear forum is a good example of an international forum as there are channels run in different languages for the different users but all the information is shared in the one place.

I have doubts about this.
1. Will BW ever create worldwide forum?
2. Will you Australians move to worldwide forum?
3. Will also all others move to worldwide forum?
(e.g. German users will NOT start using english easily so they will use their own forum)
4. Will BW allow third party hack-sw be distributed in their worldwide forum?

http://www.beyonwizsoftware.net/ is aimed to be a centralized place for BW software. Place where users can find all interesting BW software. And maybe have general discussion about them.
http://www.beyonwizsoftware.net/ is not a forum, which should replace regional forums.
It is aimed to be BW version of http://www.tapworld.net/

IanSav · Post by **IanSav** » Wed Jan 30, 2008 16:32

Hi J S,

j s wrote:The most difficult thing I'll need help with - what to call the combined product? At this alpha stage it stay as TW but any thoughts on the issue would be welcome.

What about PVRWeb or PW for short?

Regards,
Ian.

jpp · Post by **jpp** » Wed Jan 30, 2008 16:44

janilxx wrote:[quote="IanSav"
As Beyonwiz moves into other markets hopefully they will open their own forum website (there is a place reserved for it now) and we can all move there. Many companies host a single forum for their users all over the world. Smaller regional forums don't seem to work as well as larger forums. The Infrant/Netgear forum is a good example of an international forum as there are channels run in different languages for the different users but all the information is shared in the one place.

I have doubts about this.
1. Will BW ever create worldwide forum?
2. Will you Australians move to worldwide forum?
3. Will also all others move to worldwide forum?
(e.g. German users will NOT start using english easily so they will use their own forum)
4. Will BW allow third party hack-sw be distributed in their worldwide forum?

http://www.beyonwizsoftware.net/ is aimed to be a centralized place for BW software. Place where users can find all interesting BW software. And maybe have general discussion about them.
http://www.beyonwizsoftware.net/ is not a forum, which should replace regional forums.
It is aimed to be BW version of http://www.tapworld.net/

I think you're right Jan. I think the resistance to visit another site is more ideologically based than real. Email notification surely makes it very simple to keep up with the thread. I use an Explorer add-on called Maxthon which allows me to keep as many tabs open as I wish and is much easier to use than IE7's tabs, so keeping one open for the beyonwizsoftware.net is no great drama.

Don't forget too that other Toppy guys like Dave etc have already put their stuff up on this site.

And yes, I for one can't see BW being too happy with hacked firmware being published on their site.

My 4c worth for today.

j s · Post by **j s** » Wed Jan 30, 2008 16:45

IanSav wrote:If people are going to modify their Toppy based programs to also work with the Beyonwiz then I thought they should be aware of the more formal solution that is coming. If this feature is added to a Beta then I am sure somone will confirm the details at that time.

Point noted Ian! It's exactly why I intend to use the plug-in approach.

I'm pleased to hear that an official interface is in the works.

j s · Post by **j s** » Wed Jan 30, 2008 17:04

IanSav wrote:Hi J S,
j s wrote:The most difficult thing I'll need help with - what to call the combined product? At this alpha stage it stay as TW but any thoughts on the issue would be welcome.
What about PVRWeb or PW for short?

Regards,
Ian.

That's the obvious one (I should have mentioned I'd thought of that). So far the only name I've thought of but I'm hoping for something a bit more.....well....you know what I mean.

But that will be the fallback name if nothing better emerges.

DrPhil · Post by **DrPhil** » Wed Jan 30, 2008 18:58

Surely the BW folk must realise that opening up the firmware, creating API's etc leverages all the talents from the end users willing to develop apps and tools to enhance the BW.

It must make their life a little easier having all this help at hand.

Guess they want to get the product to a certain point that PVRs should be at before they do this.

Must be nearly there?

Phil

PS Great work Eric....

efry · Post by **efry** » Wed Jan 30, 2008 23:20

Hi Guys,

I've updated wizremote to version 0.3.

Here's the change log entry.

Code: Select all

0.3 * Fixed some memory leaks in wizremote
    * Added the ability to delete timers
    * Added the ability for the daemon to process mulitiple commands
      in a single connection
    * Added a 'Save and Reboot' button to the website. Don't 
      automatically reboot when adding new timers.

Eric

IanSav · Post by **IanSav** » Thu Jan 31, 2008 08:11

Hi Eric,

Two questions:
1 - Why do you need the reboot after changing the timers?
2 - Have you updated the telnet hack for 01.05.197?

Regards,
Ian.

efry · Post by **efry** » Thu Jan 31, 2008 09:04

IanSav wrote:Hi Eric,

Two questions:
1 - Why do you need the reboot after changing the timers?
2 - Have you updated the telnet hack for 01.05.197?

Regards,
Ian.

Hi Ian,

1. The timers are stored in the /tmp/config/book.xml file but this file is only read by the pvr on startup. It would be great if
the wizdvp app had a way of reloading its config files without a restart. Most unix apps do this with a HUP signal.

Running 'kill -HUP wizdvp' would then cause the pvr to rescan its book.xml file and we'd be in business.

Though a better solution would be to setup an IPC socket from wizdvp that applications could use to connect to wizdvp and
interact with timers. wizdvp already uses sockets for comms between its threads so I don't think it would be hard to implement.

2. I'm currently running 01.05.197 with telnet turned on. I'll make a patch file tonight and update beyonwizsoftware.net

One thought I had, would it be a better idea to move the book.xml file to the hdd because at the moment it is written
to the flash everytime a timer fires. Flash has a limited rewrite cycle so it might be better to do these writes to the hard disk.
Just food for thought.

Eric

IanSav · Post by **IanSav** » Thu Jan 31, 2008 10:57

Hi Eric,

efry wrote:1. The timers are stored in the /tmp/config/book.xml file but this file is only read by the pvr on startup. It would be great if the wizdvp app had a way of reloading its config files without a restart. Most unix apps do this with a HUP signal.

Running 'kill -HUP wizdvp' would then cause the pvr to rescan its book.xml file and we'd be in business.

Though a better solution would be to setup an IPC socket from wizdvp that applications could use to connect to wizdvp and interact with timers. wizdvp already uses sockets for comms between its threads so I don't think it would be hard to implement.

How did you come to these conclusions? I haven't found enough information to come to support such statements. I am not saying you are wrong just that I haven't found these sort of hints as yet.

If a signal is sent to the main process I would expect it to reload all its configuration files, not just the timer file.

efry wrote:2. I'm currently running 01.05.197 with telnet turned on. I'll make a patch file tonight and update beyonwizsoftware.net

With the assistance of a mate I am considering doing our own firmware repacks rather than binary patches. I just don't want to offend Steven/Beyonwiz. We may just go ahead and do the work then seek permission to post the results. I will have to think about this some more. (Steven what do you think about these firmware modifications/hacks?)

efry wrote:One thought I had, would it be a better idea to move the book.xml file to the hdd because at the moment it is written to the flash everytime a timer fires. Flash has a limited rewrite cycle so it might be better to do these writes to the hard disk.
Just food for thought.

Yes this also worries me.

I suspect that Steven may want to move these files into the /tmp/mnt tree anyway as that is the root for the httpd server and will make http access easier.

Regards,
Ian.

chrisb · Post by **chrisb** » Thu Jan 31, 2008 11:09

DrPhil wrote:Surely the BW folk must realise that opening up the firmware, creating API's etc leverages all the talents from the end users willing to develop apps and tools to enhance the BW.

You'd think that would be the case. However, that raises the question of what the hell happened at Topfield between the 5000 and 7000 PVR for them to take such a backwards step.

Bring on the open API's! Once the Beyonwiz matches the TEDS/ICETV combo I might actually use the S1... At the moment it's just a nice clock. (Sorry, but it doesn't even do a good job playing dvd's.)

Chrisb.

efry · Post by **efry** » Thu Jan 31, 2008 17:12

Hi Ian,

IanSav wrote:Hi Eric,
efry wrote:1. The timers are stored in the /tmp/config/book.xml file but this file is only read by the pvr on startup. It would be great if the wizdvp app had a way of reloading its config files without a restart. Most unix apps do this with a HUP signal.

Running 'kill -HUP wizdvp' would then cause the pvr to rescan its book.xml file and we'd be in business.

Though a better solution would be to setup an IPC socket from wizdvp that applications could use to connect to wizdvp and interact with timers. wizdvp already uses sockets for comms between its threads so I don't think it would be hard to implement.
How did you come to these conclusions? I haven't found enough information to come to support such statements. I am not saying you are wrong just that I haven't found these sort of hints as yet.

If a signal is sent to the main process I would expect it to reload all its configuration files, not just the timer file.

I have been looking at a disassembly of wizdvp and I have identified the function that reads in the book.xml file and traced it back to the main function. Which suggests it only gets called once. IIRC there was another occasion where it was called but it didn't seem to be relevant either.

I have tried killing the main wizdvp thread with the HUP signal and at the moment it just dies. I don't even think it is a clean shutdown.

I would also expect that a HUP signal would cause a full config reload. That would be the desired outcome.

If you know of any other ways of getting wizdvp to reload its timers I'd be interested to know.

I have also observed the IPC sockets via netstat and via looking at the /tmp directory. You can also see debugging info about the communications between the sockets in the ctrace logs.

IanSav wrote:
efry wrote:2. I'm currently running 01.05.197 with telnet turned on. I'll make a patch file tonight and update beyonwizsoftware.net
With the assistance of a mate I am considering doing our own firmware repacks rather than binary patches. I just don't want to offend Steven/Beyonwiz. We may just go ahead and do the work then seek permission to post the results. I will have to think about this some more. (Steven what do you think about these firmware modifications/hacks?)

I decided to release the patch instead of a full firmware file due to the copyright nature of the firmware file. It's also smaller to download and I figured everyone would have downloaded the original firmware already.

What sort of mods would you be putting in your custom firmware?

Eric

janilxx · Post by **janilxx** » Thu Jan 31, 2008 17:29

IanSav wrote:
efry wrote:2. I'm currently running 01.05.197 with telnet turned on. I'll make a patch file tonight and update beyonwizsoftware.net
With the assistance of a mate I am considering doing our own firmware repacks rather than binary patches. I just don't want to offend Steven/Beyonwiz.

Patches would be MUCH better that full modified FW files. This is because some users want to use older FWs, so you would have to repack at least some older FWs also. And of course you would also have to repack all future FWs as well. It is possible that patch-only could be installed into all older and future FWs and it could be done easily by individual users.

And also remember, there is other places also, like this small Finland up here. We want to get new features also and I am sure you won't repack our FWs also

So plus for patches, minus for repacked FWs.

PS. I am not sure did you mean that it would be better to distribute already patched FWs instead of patches only.

PPS. Of course this is only my opinion and I did not mean to offend anybody

prl · Post by **prl** » Thu Jan 31, 2008 17:33

efry wrote:...
I would also expect that a HUP signal would cause a full config reload. That would be the desired outcome.
...

While that's an entirely reasonable expectation of a server in an interactive system, I'm not sure that it's necessarily what you'd expect in an embedded system.

Anyway, what about modifying rc.sysinit so that instead of just running wizdvp,
it does something like

xit=129
while [ $xit -eq 129 ]; do wizdvp; xit=$?; done

129 is the exit code for a process that dies with SIGHUP.

Doesn't get around any problems associated with wizdvp not closing down cleanly, though.

IanSav · Post by **IanSav** » Thu Jan 31, 2008 18:15

Hi,

I think you guys may be misunderstanding me.

When I talk about repacking the firmware I am talking about taking a firmware update, fully expanding the update, using SED or another approrpriate tool to make any required changes and then repack the firmware back into an update image.

This could/should work for any firmware update.

Regards,
Ian.

prl · Post by **prl** » Thu Jan 31, 2008 18:21

It's not particularly hard to unpack the part of the file system where wizdvp lives.

The root file system is another romfs file system contained in the kernel binary, and likewise easy to unpack. However, there's more data in that image after the end of the romfs image, and I don't know what the consequences of moving that dta would be. I do know that the start address of the root file system is a compiled-in constant in uClinux systems built this way.

The romfs root and the other data appear to start on 4kB boundaries. If that's true, then it may be possible to expand the romfs root a bit without moving the other data.

janilxx · Post by **janilxx** » Thu Jan 31, 2008 18:32

prl wrote:It's not particularly hard to unpack the part of the file system where wizdvp lives.

The root file system is another romfs file system contained in the kernel binary, and likewise easy to unpack. However, there's more data in that image after the end of the romfs image, and I don't know what the consequences of moving that dta would be. I do know that the start address of the root file system is a compiled-in constant in uClinux systems built this way.

The romfs root and the other data appear to start on 4kB boundaries. If that's true, then it may be possible to expand the romfs root a bit without moving the other data.

You guys are discussing here about things I would love to collect into one place.
I have created a wiki pages for this kind of information, but because I do not understand this kind of low level stuff, someone else should write this stuff into wiki.

See more from
http://www.beyonwiz.com.au/phpbb2/viewtopic.php?t=1509

How could I motivate you to start editing this wiki?
I am sure all of you agree that this kind of information should be in easy-to-find format in one place, and not distributed around forum(s).

Gully · Post by **Gully** » Thu Jan 31, 2008 19:11

But Janil, it is all in one place - here.

Seriously though I think it is premature aside from the question of whether it is needed.