Posts by idreamsat
Another way of doing it.
You need to download TrueGridNFS search Google
tgpnfs10.zip (218 KB)
1. Download the TrueGrid NFS server.
2. Create an etc directory on your pc.
3. Create a directory on your pc for the nfs share.
Also create the following sub directories:
4. Create a directory and extract NFS server (tgpnfs.zip) files on your pc. Eg:
5. Copy two files, rpc and exports, to the etc directory that you created in step 2.
6. Edit the exports file. Add a line at the end of the file to point to the nfs directory you created in step 3. It should look like this:
7. Save the file. (Make sure the last line of the exports file is a blank line.)
8. Open a command line prompt and go to the directory containing the extracted NFS files.
9. The following commands register and setup the portmap and nfs services:
10. Start the services.
11. Check that the services are setup correctly.
1. To show what is available to share:
TrueGrid SHOWMOUNT UTILITY.
COPYRIGHT (C) BY XYZ SCIENTIFIC APPLICATIONS, INC., 1998
ALL RIGHTS RESERVED. TrueGrid IS A TRADEMARK OF
XYZ SCIENTIFIC APPLICATIONS, INC.
2. To show port mapping:
COPYRIGHT BY XYZ SCIENTIFIC APPLICATIONS, INC., 1998
ALL RIGHTS RESERVED. TrueGrid IS A TRADEMARK OF
XYZ SCIENTIFIC APPLICATIONS, INC.
program vers proto port
100000 2 tcp 111 portmapper
100000 2 udp 111 portmapper
100005 1 udp 714 mountd
100005 1 tcp 717 mountd
100003 2 udp 2049 nfs
Mount Plugin with Automount Option
1. On the dreambox navigate to communications setup.
Setup>Expert Setup>Communications Setup
2. If you have the latest Hydra image (eg hydra56xx_sateez_2304) you can press the blue button to open mounts setup. Not all images provide this option.
3. Enter your mount info:
IP: 192.168.0.1 ......................: your pc ip
Dir: dreambox .......................: your nfs share directory
LocalDir: /mnt ........................: your db directory
4. Put an X in the Automount box. Your mount will be automatically re-established each time you restart the dreambox.
5. Select Mount.
6. If your mount was successful be sure to SAVE your mount settings.
* Check that your nfs services are running properly and the mount is available to share.
* Attempt a mount via a telnet session using the command line method
1. download the attached file passwd.tar.gz.
2. Put it in X:\dreambox\hdd
3. In the Blue Panel go to Addons and click manual install. browse to /hdd, click passwd.tar.gz and install it.
Now your Root Password is dreambox.
It has been reported that it works with cifs .
- Install and run TuxBox Commander plugin
- Change directory to edit /var/etc/passwd (type 4: "Edit")
- Remove the encrypted password.
In the file /etc/passwd is the line:
or something as
The password field is the x or the encrypted string
Delete the x or the whole string. The line now is:
- Save the file and exit
- Telnet to your DB with root user without password
- Change/Create immediately a new root password with password
Happy Birthday ihad
what emanuel was saying is that you have to create a script and put it in /var/etc/init.d/ or /etc/init.d/
have you tried to re-flash your box and see if it will correct the problem?
I never heard of the network interface going out by itself!!!!!!
Originally posted by mabcocenter
where is ths link download
This document shows the pin layout of 9pin D-Sub Female to 9pin D-Sub Female, for various types of null modem cables, and for most Sat receivers, the one to use is the Null modem with full handshaking.
Null modem, an introduction
Serial communications with RS232. One of the oldest and most widely spread communication methods in computer world. The way this type of communication can be performed is pretty well defined in standards. I.e. with one exception. The standards show the use of DTE/DCE communication, the way a computer should communicate with a peripheral device like a modem. For your information, DTE means data terminal equipment (computers etc.) where DCE is the abbreviation of data communication equipment (modems). One of the main uses of serial communication today where no modem is involved—a serial null modem configuration with DTE/DTE communication—is not so well defined, especially when it comes to flow control. The terminology null modem for the situation where two computers communicate directly is so often used nowadays, that most people don't realize anymore the origin of the phrase and that a null modem connection is an exception, not the rule.
In history, practical solutions were developed to let two computers talk with each other using a null modem serial communication line. In most situations, the original modem signal lines are reused to perform some sort of handshaking. Handshaking can increase the maximum allowed communication speed because it gives the computers the ability to control the flow of information. High amounts of incomming data is allowed if the computer is capable to handle it, but not if it is busy performing other tasks. If no flow control is implemented in the null modem connection, communication is only possible at speeds at which it is sure the receiving side can handle the amount information even under worst case conditions.
Original use of RS232
When we look at the connector pinout of the RS232 port, we see two pins which are certainly used for flow control. These two pins are RTS, request to send and CTS, clear to send. With DTE/DCE communication (i.e. a computer communicating with a modem device) RTS is an output on the DTE and input on the DCE. CTS is the answering signal comming from the DCE.
Before sending a character, the DTE asks permission by setting its RTS output. No information will be sent until the DCE grants permission by using the CTS line. If the DCE cannot handle new requests, the CTS signal will go low. A simple but useful mechanism allowing flow control in one direction. The assumption is, that the DTE can always handle incomming information faster than the DCE can send it. In the past, this was true. Modem speeds of 300 baud were common and 1200 baud was seen as a high speed connection.
For further control of the information flow, both devices have the ability to signal their status to the other side. For this purpose, the DTR data terminal ready and DSR data set ready signals are present. The DTE uses the DTR signal to signal that it is ready to accept information, whereas the DCE uses the DSR signal for the same purpose. Using these signals involves not a small protocol of requesting and answering as with the RTS/CTS handshaking. These signals are in one direction only.
The last flow control signal present in DTE/DCE communication is the CD carrier detect. It is not used directly for flow control, but mainly an indication of the ability of the modem device to communicate with its counter part. This signal indicates the existence of a communication link between two modem devices.
Null modem without handshaking
How to use the handshaking lines in a null modem configuration? The simplest way is to don't use them at all. In that situation, only the data lines and signal ground are cross connected in the null modem communication cable. All other pins have no connection. An example of such a null modem cable without handshaking can be seen in the figure below.
If you read about null modems, this three wire null modem cable is often talked about. Yes, it is simple but can we use it in all circumstances? There is a problem, if either of the two devices checks the DSR or CD inputs. These signals normaly define the ability of the other side to communicate. As they are not connected, their signal level will never go high. This might cause a problem.
The same holds for the RTS/CTS handshaking sequence. If the software on both sides is well structured, the RTS output is set high and then a waiting cycle is started until a ready signal is received on the CTS line. This causes the software to hang because no physical connection is present to either CTS line to make this possible. The only type of communication which is allowed on such a null modem line is data-only traffic on the cross connected Rx/Tx lines.
This does however not mean, that this null modem cable is useless. Communication links like present in the Norton Commander program can use this null modem cable. This null modem cable can also be used when communicating with devices which do not have modem control signals like electronic measuring equipment etc.
As you can imagine, with this simple null modem cable no hardware flow control can be implemented. The only way to perform flow control is with software flow control using the XOFF and XON characters.
[Blocked Image: http://ihadna.com/wbb2/attachments/downloads/imgs/db9_null_dumb.png]
Null modem with loop back handshaking
The simple null modem cable without handshaking shows incompatibilities with common software. The main problem with this cable is that there is a possibility for the software to hang if it checks the modem signal lines in a proper way. I.e. with this null modem cable, good written programs will perform worse than badly written programs.
To overcome this problem and still be able to use a cheap null modem communication cable with only three lines in it, a fake null modem cable layout has been defined. The null modem cable with loop back handshaking resulted from this.
The main purpose of this null modem cable is to let well defined software think there is handshaking available, with a null modem cable which has no provisions for it.
Consider first the DSR signal (pin 6). This input indicates that the other side is ready to start communicating. In the layout, the line is linked back to the DTR output (pin 4). This means, that the software doesn't see the ready signal of the other device, but its own. The same holds for the CD input (pin 1). The assumption is, that if software has been written to check the DSR line to test communication availability, it will probably also set the DTR output to indicate its own state. This is true for at least 99% of all serial communication software. This implies that at least 99% of all serial communication software is capable of faking its own DSR check with this null modem cable.
The same trick is used with the CTS input. In the original use, RTS is set, and then CTS is checked before starting the communication. By setting the RTS output (pin 7) the CTS input on the same connector (pin is receiving clearance immediately. There is no possibility of a software hangup because of dangling RTS requests.
Other issues to consider
The null modem cable with loop back handshaking is often advised as the best low cost available null modem cable. But, is it really so good? The simple null modem cable without handshaking has the disadvantage that it does not permit proper written software to communicate with it. Software which is aware of the lack of handshaking signals can however use it without problems.
The null modem cable with loop back handshaking can be used with more software, but it has no functional enhancements over the simple cable! There is no way both devices can control data flow, other than by using XON/XOFF handshaking. If the software is designed for using hardware flow control it seems to work with this null modem cable, but on unpredictable moments, data loss may occur. This means that the null modem cable allows communication as long as no flow control is needed, but when data speeds reach the limit the receivers can handle, communication may stop immediately without an assignable reason. Therefore, although this null modem cable is cheap and easy to make, use it with care! Despite these warnings, this type of null modem cable has been used successfully between Windows 95/98/ME computers with a Direct Cable Connection.
[Blocked Image: http://ihadna.com/wbb2/attachments/downloads/imgs/db9_null_loop.png]
Null modem with partial handshaking
The simple null modem cable and the null modem cable with loop back handshaking are useful, but have no provisions for hardware flow control. If it is absolutely necessary that hardware flow control is used, the null modem with partial handshaking can be an alternative.
This null modem cable is the best of two worlds. There is the possibility of hardware flow control without being incompatible with the original way flow control was used with DTE/DCE communication. Let us first consider the RTS/CTS flow control lines present on pins 7 and 8. As with the loop back null modem cable, these signals are not connected to the other device, but directly looped back on the same connector. This means, that RTS/CTS flow control is allowed to be used in the software, but it has no functional meaning. Only when the software at the other side checks the CD signal at pin 1, the RTS information will reach the other device. This would however be only the case in specifically developed software which uses the CD input for this purpose.
More important however is the cross connection of the DSR (pin 6) and DTR (pin 4) lines. By cross connecting these lines, their original function is simulated pretty well. The DTR output is used to signal the other device that communication is possible. This information is read on the DSR input, the same input used for this purpose with modem communication. Because of this cross connection, the DTR output line can be used for simple flow control. Incomming data is allowed when the output is set, and blocked if the output is not set.
Software using only the RTS/CTS protocol for flow control cannot take advantage of the partial handshaking null modem cable. Most software however will also check the DSR line and in that case—when using the null modem cable with partial handshaking—the best possible hardware flow control can be achieved which is still compatible with the original use with modems.
[Blocked Image: http://ihadna.com/wbb2/attachments/downloads/imgs/db9_null_part.png]
Null modem with full handshaking
The most expensive null modem cable is the null modem cable suitable for full handshaking. In this null modem cable, seven wires are present. Only the ring indicator RI and carrier detect CD signal are not linked. The cable is shown in the following figure.
The null modem cable with full handshaking does not permit the older way of flow control to take place. The main incompatibility is the cross connection of the RTS and CTS pins. Originally, these pins are used for a question/answer type of flow control. When the full handshaking null modem cable is used, there is no request anymore. The lines are purely used for telling the other side if communication is possible.
The main advantage of this cable is, that there are two signalling lines in each direction. Both the RTS and DTR outputs can be used to send flow control information to the other device. This makes it possible to achieve very high communication speeds with this type of null modem cable, provided that the software has been designed for it. Because of the high possible connection speed, this null modem cable can be used with Interlink to connect two MS-DOS PC's.
This is the type of cable Microsoft recommends for the direct cable connection in their knowledge base article. For the DB9 connector they also added a connection of DTR to CD on each connector but they didn't define this connection for the DB25 connector version and they also didn't mention the CD input in the descriptive text, so it is safe to leave the CD input disconnected.
[Blocked Image: http://ihadna.com/wbb2/attachments/downloads/imgs/db9_null_full.png]
Originally posted by mornachew
Ive also read about that --- THATS BAD eh!!
What shall i do now?
You said you just got your box, well, take it back to where you got it from.
Originally posted by peds1988
DM800HD is a brilliant box my friend, if you want a receiver that works straight out of the box then DM800 isnt for you! buy a DIFFERENT receiver, Ive had a DM800 for 6months now on rotor and it works PERFECTLY!
If you ask nicely then someone might actually be willing to help you solve your problem? instead of hurling abuse.
but I haven't said or done anything!!!!!!!!!!!!!!!
just to give you a little help that will get you started, but I recommend you do your part of reading as well.
After flashing, you need to have a good satellite.xml file for the sats that you are receiving, you can either download your sat.xml file from the blue panel, extra settings menu, or by using a pre-made service list that you can custumize for only the sats you want. Then you need to set up your sats/lnb configuration and make sure the settings are correct.
If you like to build your own service list, then use a good sat.xml file, and finish setting your sats/lnb, then you can start scanning each sat you are pointed at for services. Sometimes, you need to scan each sat more then once to get all services available.
Next you need to figure out "by reading" which emu you need to work with any encrypted services you might have, unless you are watching free-to-air services.
here is a list of some needed software:
DreamBoxEdit for editing service lists
Any FTP client software like FlashFXP, or use Dreambox Control Center, which has an ftp client, and much more.
Also read about WebIF, and I recommend you use FireFox, and make sure you install the latest VLC.
Good luck reading, and let us know if you have more questions.
I just get tickled every time I see a dead clone. Go after the person who sold it to you, that is if you did not know you were buying a clone, otherwise, as Playa4Life said, "Get a genuine Dreambox, dont buy clone crap.... "
Originally posted by Kerni
talking about nabilo skin's outside of nabilo board is evil
but to answer your question,
No, the box will crash.
kerni, we need a Gemini skin with an analog clock.
I think you know the answer, most emulators out there supports only 2 services @ the same time.
Originally posted by pcd
Also, if you know the urls to get the epg in xml form - I can try to do the e2_loadepg files for those providers.
I haven't checked load epg myself, and I think I will today, anyway, the url is http://labs.zap2it.com/
Zodac. any possibility on adding support for North American Providers EPG. as Dishnetwork, and Bell of Canada. EPG data is available from services like Zap2it and many others.
guys and gals, the thread starter has a point, this is the English forum, which is for people who don't speak German.
GuteMine, you could of made your 2nd post to be the first, where jimmcooper took as an insult.
@Schadelbeisser, your post was also a little insulting as well, you could of just give him the answer, instead of replying the way you did.
jimmcooper, there was no need for the foul word you said, on a forum, you need to chill out a little and not take it so seriously, as people might having a bad day while replying to some posts, I know for a fact that gutemine did not mean any insults, and there was a sense of humor in his first post.
@all, chill out guys, and let's have a beer, cheers.
OE Build Configuration:
BB_VERSION = "1.8.12"
METADATA_BRANCH = "opendreambox"
METADATA_REVISION = "12986b0a47f5e813d5e811807ca930bd1da75e62"
TARGET_ARCH = "mipsel"
TARGET_OS = "linux"
MACHINE = "dm800"
DISTRO = "opendreambox"
DISTRO_VERSION = "1.6.0"
TARGET_FPU = "soft"
ENIGMA2 = "20090302"
- First e2 image to support Dishnetwork epg
- North American scan
- other small fixes.
do you mean "no preview" of highlighted skin? if so, then it is because the creator of that skin did not create a preview image for it.