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

[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

[tonymy01]

i already gotyour perltgd working as wiztimerd, see a few threads down. Www.openwiz.org has enough info to hack 4 telnet. Build a serial adapter is a better way i think.

[jim16]

i already gotyour perltgd working as wiztimerd, see a few threads down. Www.openwiz.org has enough info to hack 4 telnet. Build a serial adapter is a better way i think.

Hi tony,

Yes I know that you have ported my PerlTGD to the wiz ( nice work btw ), but pvrtimersd will expand on both PerlTGD and wiztimerd to support users with both a toppy and a wiz i.e. When to many timers exist at that same time for the number of tuners on the device, the dropped timer will be placed on the other device etc.. Thanks for the tip with openwiz.org will use the information to add telnet to the device and start hacking away.

Regards

jim16

[prl]

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

I have a toolkit (BWFWTools) that uses efry's Wiz Firmware Tools to allow the Beyonwiz firmware packages to be unpacked into the file system, manipulated (by hand in the current version), and repacked.

I have almost completed coding and testing of a new tool for BWFWTools that allows patcher modules to be run to allow particular changes to the firmware. The simplest patcher module that works with this is one that enables Telnet. I haven't tried it on the P2 firmware, but I don't think that that will cause any problems. This new tool will let anyone apply any of the standard patches to any firmware.

Unfortunately, the current released version of Wiz Firmware Tools doesn't work properly with Windows; there'll be a companion release of that that works on Linux, Windows, Cygwin/Windows and OS X. But the release of the two packages will be a week or two coming.

If you're willing to get BWFWTools from beyonwizsoftware.net, and can compile Wiz Firmware Tools from openwiz.org (you can also get BWFWTools from there), you can enable telnet just by unpacking the firmware with unpack_wrp.pl, editing the Beyonwiz /etc/rc.sysinit to add

Code: Select all

telnetd -l /bin/sh &

just before the line

Code: Select all

# rc.local

and then repacking the firmware with pack_wrp.pl. You must use an editor that preserves Unix-style (newline only) line endings There are some more details of how to run unpack_wrp.pl and pack_wrp.pl. However, it describes how to do a more complicated patch that can also enable telnet, but can also do much more.

If you're not confident of being able to do this from those instructions and the documentation with the firmware tools, it's probably not a good idea to try.

The effect of this hack can be undone by re-installing the original Beyonwiz firmware package.

And to repeat what the documentation says:

Using user extensions or hacks may make your Beyonwiz unable to operate correctly, or even start. Some modifications are known to interfere with the correct functioning of the Beyonwiz.

If your Beyonwiz cannot start after you load modified firmware, you may need to use the procedures in the NOTICE - How to recover from FW update failure procedure on the Beyonwiz forum. It's not known whether that procedure will fix all failures due to user modifications or "hacks".

If you run modified firmware on your Beyonwiz, and have problems with its operation, try to reproduce any problems you do have on a Beyonwiz running unmodified firmware, or at least mention the modifications you use when reporting the problem to Beyonwiz support or on the Beyonwiz Forum. Beyonwiz support may not be able to assist if you are running anything other than unmodified firmware from Beyonwiz. Forum contributors may be able to be more flexible, but they will need to know what modifications you have made.

A recent further risk is that there have been reports on the beta forum that the firmware recovery procedure may not work with firmware 1.05.261. It would probably be advisable to try using it before you try any modifications to the firmware.