UPDATING DVBS.DAT FILE IN DISK1/DISK2_BACKUP

Stargaze, I want to thank you for the reminder to reboot after sending changes to the box. That is something that I do so often I could easily overlook it.

I’ve thought a lot about this issue since we last talked. I agree with you that it seems I’m using the right procedures and tools but getting different results than you are. About the only thing I can think that is different here is the performance of the ACC. I might have a partially corrupted program.

When I opened the XONIC TOOLKIT Kaspersky immediately began warning me about a virus and malware. I deleted the files Kaspersky identified as bad. The Toolkit went ahead and installed but after the first use of the program the menu shell would not come up, stating some file was in use. I then went into the C:\Program Files\Team\ToolBox AzBox HD\Prog folder and created a shortcut to each of the necessary tools (ACC, AzEdit and MazEdit). That way I could use the tools and work around the menu shell. Two of the three tools open fine and seem to work right. The exception is ACC, which does not replace the original the DISK1/DISK2_backup DVBS.dat file and does not cause the Azbox to reboot after uploading the three files.

As a side note: Correct me if I don’t see all the features that ACC provides in this scenario. It seems that the two basic functions are the ability to change the backup DVBS.dat file properties from read to write, overwrite the backup file with a copy of the newly uploaded DVBS.dat file and then change the file properties back to read. Additionally, it also sends a reboot command to the Azbox. If this is right, and I cannot get ACC to work properly, then the challenge would be to find another way to change the properties of the backup file so it can be replaced. Hope I’m not over simplifying the issue here.

I did not document the name of the site that I downloaded the Xonic Toolkit from…I now wish I had. I’m going to try again to find a site that I can get a virus/malware free set of tools and just start over. It looks like the only part of the puzzle that needs to be fixed is ACC. This has been quite an adventure and I appreciate all your suggestions (and the work you put in to compile the A to Z Guide). I’ll post how all this works out.

Flinthill
 
File size is going to vary according to location and selected satellites. A quick snip of birds out of range from here took the file size down to 25kb.

Clearly you have been successful in replacing the original backup file with a different version. I'm curious about what method you used to get the change accomplished. Did you use the code you posted or ACC or......................? Thanks for the information.

Flinthill
 
I simply ran the two commands in post #6:

mount -o remount,rw -t ext3 /dev/hda1 /DISK1

cp DISK2/DVBS.dat DISK1/DISK2_backup/DVBS.dat

The rest of the telnet record was ensuring the commands ran correctly. The results can also be confirmed in the FTP client as in my previous post. Linux returns DISK1 to read-only.
 
In all sincerity, I do not think that learning and using these linux commands and TelNet to accomplish what you can do in a matter of seconds is of any benefit in regards to making the receiver user friendly and operational.

Yes, learning these commands and what they do is valuable information. Understanding what is going on here is very key. However, there really is no formal reason to do so when there are programs to handle the objective for you - automatically.

Flinthill, you yourself stated somewhere in this thread that you were not a programmer and didn't understand what the code does... So why jump into the very fire that you don't know how to control? These LINUX commands seem to be troublesome enough for some who have experience with them because the symantics are peculiar. Spaces and characters must be perfectly recorded. Unless you are well versed in this programming, you won't understand why a comma cannot go here or why you need to put a space between two certain characters at one point, and not in another.

Many of the supporting application programs (ACC, MaZEdit, AZBox Edit, etc) are certainly not perfect and have compatibility problems with various OS's, but if you are persistent, they will work.

My recommendation is to work towards making these supporting programs work for you, rather than changing gears and finding more problems that you need to research.

Stargaze said it completely when he stated that you are worrying about things that are not important nor necessary.

It is fine to start learning these programming techniques and how to TelNet these commands to the AZBox to do your bidding, but you can save yourself some headaches and confusion if you just stick with the prefab application programs until you learn the really technical pieces of this programming code.

The procedure to North Americanize your AZBox works and it works well... The stumbling block is getting the programs required to load properly and run smoothly.

RADAR
 
I agree with AcWxRadar 100%. I was just answering the original question in post #1.

Addressing it directly through Linux will not blow it up but may lead to a few ill-advised adjustments with heavy equipment.
 
A funny thing happened on the way to updating… I decided to take the conservative route and continue trying to use ACC to send updated files to both Disk2 and hopefully the Disk1/Disk2_backup/DVBS.dat file.

Because my current version of ACC seemed not to get the job done, I did a complete uninstall. Then found a new site from which I downloaded TOOLBOX AZBOX HD 1.2. This time the file was completely virus and malware free.

I installed and opened the new ACC program then sent a copy of the three .dat files to Disk2. The size of the DVBS.dat file I uploaded is 15.05 KB. Before I uploaded these files I had deleted the existing three files in Disk2 to insure a new copy was installed. After rebooting I checked to see if the Disk1 backup had received the new 15.05 size file. It had not changed from its original size of 132.37…still the old file. But, what did happen is the Disk2 DVBS.dat file had grown from 15.05 to 142.97 KB.

I repeated this procedure several times with the new install of ACC only to have the DVBS.dat file increase in size and the file list again become corrupted. Each time there were duplicates of all the western sats, along with all the eastern sats.

OK, I thought it time to start over so I did a factory reset. Reentered all the basic data and again uploaded my three .dat files. But this time I used a proven FTP program (CUTE FTP) instead of ACC. The same thing happen all over again…the disk1 backup file stayed the same at 132.37 but the Disk2 DVBS.dat file went right back to the 145 KB file size.

Now I’m stumped. It would appear that ACC has corrupted some operating system file that the factory reset could not make right. So now I’m not certain what steps to take next. I’m wondering if a new copy of the Azbox OS could be installed. Or maybe there is some other kind of fix.

Things are really sliding downhill, but at least I believe we’re at the bottom, or very close to it, so all will hopefully get better from here.

Flinthill
 
dont use those stupid toolboxes... i use gftp in linux or filezilla in winblows, they both work fine. i still use xp.
flint, try just to delete dvbs file from disk1, make sure its gone, after that copy a new dvbs to the disk1. reboot azbox with the POWER SWITCH.
 
I agree with AcWxRadar 100%. I was just answering the original question in post #1.

Addressing it directly through Linux will not blow it up but may lead to a few ill-advised adjustments with heavy equipment.

Jwwbrennan,

I think that what we should do is start a thread that is dedicated to all the TelNet Linux commands and what they actually do. All the instructions and commands would need to be screened very cautiously to ensure the accuracy. I think that it must be explicit regarding the rules about where to place commas, spaces and special characters and what every command we send actually does. We should get this sort of tutorial running soon. It would be benefical to all.

If you are willing and confident, maybe you can get the ball rolling here?

I feel that we must offer the avenues that you noted ealier as we strive to learn all that we can.

RADAR
 
I am very hit and miss when it comes to availability but have larger concerns as well. There are many great Linux forums out there better suited to that task as this forum is better suited to satellite hobbyists.

Frankly I have seen AZBox related posts on various Internet sites implying the impossible that could lead to frustration. For example read-only means precisely that. Unless the software in use changes the status of a mounted file system to read-write any number of attempts will not write to or delete from it. (That is the intention.) Without a large group of contributors with knowledge specific to that command set the incorrect information could remain in place for a long time.

Like all tools, this set has some to-be-expected limitations but their value far exceeds their cost. I am long enough in the tooth to recall the difficult first days of some highly respected (and by times expensive) software; so with good support the future of the tools looks bright.

'AZBox Remote Control' for example has talent specific to certain tasks. DHCP is the default on a new box so, if DHCP is running, the network is set automatically. The Remote Control software is not quick but can help when setting 'Display' or while making time consuming changes when the television is actually in use by someone watching it from another source (SonicView for example). If, after studious research, careful planning, the making of financial and time commitments I decided on FTA, the first screen from the AZBox connected to a large North American Sony would not be encouraging. Remote Control could help build confidence.

One thing that may not be immediately obvious is the AZBox does not need to be connected to a television or LNB to be configured. For a network configuration the only connections required are network and power. As the software is free, a Windows computer anywhere can be used to download and run it. Those concerned with or frustrated by making system changes could take the unit (and suitably modified files if required) to someone with experience (who has made all the mistakes) and ask for their help. The Linux community is remarkably and infectiously co-operative. Again, I say this to help anyone who feels he just blew the budget on undocumented electronic snake oil.

I think supporting the tools others have generously created is the best way to manage the box. With a little exploration most of them do a great job and circumvent having to learn an arcane language.

So RADAR, thanks for the thought but I think your first take is better.
 
Last edited:

Users Who Are Viewing This Thread (Total: 0, Members: 0, Guests: 0)

Who Read This Thread (Total Members: 1)