UPDATING DVBS.DAT FILE IN DISK1/DISK2_BACKUP

[Flinthill]

In another thread someone offered a direct method of updating the DVBS.dat backup file located in DISK1 by using a Linux (I believe) command and FTP. The command was:

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

This command runs from the CMD prompt after accessing the Azbox.

I was able to successfully access the box with this command but was reluctant to go ahead and send the new DVBS.dat file. Before I possibly make a boat anchor out of this P+ I thought I’d inquire to see if anybody has done this before and also to see if there is a means of repairing any damage should things not go as intended.

Flinthill

 

[brentb636]

There is always the option of
1) booting to the USB stick with latest firmware on it. named "patch.bin" ;
2) Formatting the application area ;
3) Loading the latest firmware .
I've done this before to start over.

 

[jwwbrennan]

There are probably several methods using telnet, chmod and cp but I am curious...is there a reason you don't want to just ftp a copy to your PC and store it there? You can use the same method to transfer it back if required.

 

[stanleyjohn]

I have just been using the backup feature on the azbox to back up to a usb stick then using restore the same way.Its worked well for me unless im missing something.

 

[Flinthill]

I may not have full grasp on this, but I have read that the “DVBS.dat” I’m concerned about is located in DISK1/DISK2_Backup. I understand it is the original file installed by the factory that has all the Eastern and Western satellite listings. I understand that if something becomes corrupted in the DISK2/DVBS.dat file then the Azbox system reverts to the DISK1/DISK2_Backup/DVBS.dat file.

Just FTPing the three files, (DVBS.dat, all_channel.dat & channel_list.dat) to DISK2 does not change the DVBS.dat file in the disk1 backup folder. Rebooting after FTPing new .dat files to DISK2 also does not change the subject file.

Correct me if I’m wrong here: If the subject file is replaced by a new DVBS.dat file I should expect to see a current date listed, instead of the original file date of 1/1/1970.

I have considered attempting to FTP the new DVBS.dat file to replace the DVBS.dat file in the backup folder but I am reluctant about that doing that. I have tried to rename the subject file before attempting to replace it but it is “read only” and can’t change the name. I would like to build in some insurance before trying to replace it.

Additionally, according to another thread, If the “Azbox Control Center” program is used to FTP the new files to the Azbox it will also update the subject DVBS.dat file. However, I have found that feature does not work for me. That is the reason I am looking for a reliable and direct means of updating the subject file whenever I feel it is necessary.

Hope I haven’t confused the matter. Thanks for everyone’s input.

Flinthill

 

[jwwbrennan]

I didn't know it restored from that backup file...

so (as recommended) this worked:

AZBox[/]$ mount -o remount,rw -t ext3 /dev/hda1 /DISK1
AZBox[/]$ ls -ls
0 drwxr-sr-x 14 1000 default 0 Jan 1 2000 DATA/
0 drwx------ 8 root root 0 Nov 18 17:25 DISK1/
1 drwx------ 5 root root 1024 Nov 20 13:39 DISK2/
1 drwx------ 3 root root 1024 Nov 20 13:15 Download/
1 drwxr-xr-x 8 root root 1024 Nov 18 17:26 MMP/
...
AZBox[/]$ cp DISK2/DVBS.dat DISK1/DISK2_backup/DVBS.dat
AZBox[/]$ cd DISK1/DISK2_backup
AZBox[DISK2_backup]$ ls -ls
125 -rw-r--r-- 1 root root 127612 Nov 20 17:30 DVBS.dat
17 -rw-r--r-- 1 root root 17470 Jan 1 1970 ISO-639-2_utf-8.txt
...
AZBox[DISK2_backup]$

It has only had the briefest of tests so you may want to be careful. If I recall correctly Linux will set it back to read only in time. In the meantime you may want to move the file a few times so it will be easier to leave write in place for now.

Edit: I forgot to mention the ellipses represent the continued file list unnecessary for this post.

 

[brentb636]

"
Correct me if I’m wrong here: If the subject file is replaced by a new DVBS.dat file I should expect to see a current date listed, instead of the original file date of 1/1/1970"

The file you copy to the Disk2_backup location will take the date current on the Azbox at the time of copying. Check the filesize, too, and you will see that the file does indeed copy.
My copied DVBS.dat file, for example, is dated 1-1-2000 , not the 1970 date like the other files in the folder, and has the same filesize as my current DVBS.dat file.

 

[stargaze]

I was able to successfully access the box with this command but was reluctant to go ahead and send the new DVBS.dat file. Before I possibly make a boat anchor out of this P+ I thought I’d inquire to see if anybody has done this before and also to see if there is a means of repairing any damage should things not go as intended.

Flinthill

ok, first off, I have not done it this way as my computer skills are not the greatest, and the ACC program has worked fine for me.
But to help alleviate some of your concerns....
1) Have you sent over your list to your working disk on the azbox? (not the backup one).
2) if so does it work as you want it to work and are all the settings set up properly for your particular setup?
3) if you have answered yes to everything above then go ahead and send it to your back up as you wrote.
You will have 3 scenarios:
1) It worked fined and everything is Great!
2) It did not recognize your command prompt and did not upload anything. no harm no foul,
3) If your file is corrupt you will have a bad file in your backup.
I do not see where it would cause your receiver to be a boat anchor. Your only rewriting the satellite channel files not anything else in the azbox.
Give it a go and let us know how it worked out for you.
It only takes a minute to get it finished and you have worked long enough to get this far.

 

[jwwbrennan]

The requested listing on DISK1/DISK2_backup:
AZBox[/]$ ls -ls

is returning a DVBS.dat listing from today:
125 -rw-r--r-- 1 root root 127612 Nov 20 17:30 DVBS.dat

and a utf-8.txt listing from Jan 1 1970 as it was not copied.

 

[stargaze]

"
Correct me if I’m wrong here: If the subject file is replaced by a new DVBS.dat file I should expect to see a current date listed, instead of the original file date of 1/1/1970"

The file you copy to the Disk2_backup location will take the date current on the Azbox at the time of copying. Check the filesize, too, and you will see that the file does indeed copy.
My copied DVBS.dat file, for example, is dated 1-1-2000 , not the 1970 date like the other files in the folder, and has the same filesize as my current DVBS.dat file.

You are correct. The DVBS.dat file date will have changed, on my P+ box I also see a time stamp with the maz program.
I thought the date stamp came from the azbox itself.
I have never seen a DVBS.dat file dated 1970 but then this is the first I have looked at the date on that file, and I am using 3 az receivers as my reference.

 

[Flinthill]

AZBox[DISK2_backup]$

It has only had the briefest of tests so you may want to be careful. If I recall correctly Linux will set it back to read only in time. In the meantime you may want to move the file a few times so it will be easier to leave write in place for now.

Thanks for the reply. I'm not a programmer so I don't understand what the code actually does. Will this go out to my hard drive, access the DVBS.dat file and send it to the Azbox. Or, after this code is entered do I start up the FTP program then select and send the file to the Azbox. Or, is there another way???

Flinthill

 

[Flinthill]

The requested listing on DISK1/DISK2_backup:
AZBox[/]$ ls -ls

is returning a DVBS.dat listing from today:
125 -rw-r--r-- 1 root root 127612 Nov 20 17:30 DVBS.dat

and a utf-8.txt listing from Jan 1 1970 as it was not copied.

Now I wonder why that is. The questions seems to be, have you updated the backup copy today and thus it would have todays date or did the operating system simply redate the old file when it received the query?

Flinthill

 

[jwwbrennan]

I must say in the twenty plus years I have been running Unix and its variations I have never seen any of them update a file date on the execution of an ls command (the query). What was not apparent in the print out was the file date was the date on the AZBox at the time of the cp. As it was coming from Telnet, a simple terminal emulation program, the local system date is not relevant.

If the backup copy was always a copy of the last active file it would not bring back the unwanted satellites but would lead to other problems.

You may want to ask a friend with Linux experience to help resolve this.

 

[stargaze]

Now I wonder why that is. The questions seems to be, have you updated the backup copy today and thus it would have todays date or did the operating system simply redate the old file when it received the query?

Flinthill

I believe your worrying about things that are of no real consequence.
Make a back up of the original file and keep it someplace you know where it is.
Then do what you intended to do in the first place. replace the back up file.
Now one thing I did not see mentioned here and not sure if it is necessary but the ACC program re-boots the receiver after the file is sent so make sure you re-boot the receiver after you send the file.
Don't go and check the file a second time before re-booting.
After you reboot then you can check to see if the file is the same size as what you sent to it. As for the date time stamp I believe this is what the azboz gives it whenever you make a change or if the receiver has a hiccup on you.
What your after is having a set of files that works for you.

 

[stanleyjohn]

Still seems like alot of work just to backup a few files!Shame on AZbox for not making it easy.

 

[Flinthill]

If the backup copy was always a copy of the last active file it would not bring back the unwanted satellites but would lead to other problems.

In my P+ the current back up DVBS.dat file size is 132.37 KB and has a description of "Nero media Player media files" and a date of 1/1/1970

The operating DVBS.dat file located in DISK2 is 15.05 KB, no description and a date of 11/20/10. I uploaded it today.

The size comparison is probably the most credible way to determine what version of the file Azbox is using as a back up in DISK1.

 

[Flinthill]

I believe your worrying about things that are of no real consequence.
Make a back up of the original file and keep it someplace you know where it is.
Then do what you intended to do in the first place. replace the back up file.

Since we last talked, I attempted to FTP my newest DVBS.dat file to DISK1/DISK2_backup. I received an error report indicating the transfer was incomplete. (Remember the file to be overwritten is a "read only" file.

Now one thing I did not see mentioned here and not sure if it is necessary but the ACC program re-boots the receiver after the file is sent so make sure you re-boot the receiver after you send the file.

When I attempted to use ACC it would not reboot my Azbox. Tried several times.

After sending a new file(s) to the Azbox I always do a manual reboot to make sure the new files are in place. And, then immediately ckeck whatever I changes I made are in place.

Please take a look at my reply to JWWBRENNAN about file sizes. After using ACC to upload your files, I'd be interested to know the size of your backup DVBS.dat file? Is it in the range of 16KB or the original file size of 135 KB?


Don't go and check the file a second time before re-booting.
After you reboot then you can check to see if the file is the same size as what you sent to it. As for the date time stamp I believe this is what the azboz gives it whenever you make a change or if the receiver has a hiccup on you.
What your after is having a set of files that works for you.

Flinthill

 

[stargaze]

I'd be interested to know the size of your backup DVBS.dat file? Is it in the range of 16KB or the original file size of 135 KB?

The size of that file on all my azboxes is 34kb.

 

[stargaze]

(Remember the file to be overwritten is a "read only" file.)

Yes, but... no one who has done the procedure this way has ever mentioned nor stated they had to do anything different than what you are doing.
I can not explain why at every turn you appear to be having difficulties. Wether it be with the programs not working properly for you or maybe you just have an azbox that does not like being changed.
I would not give up there is a reason an you just have not figured it out yet but I suspect there is something either on you pc or plain operator error that is causing this for you.

I hope your keeping a record of what your doing, what I did was to write things out and then reread it several times to see if it made sense, at least to me, then if it did not work try a slightly different approach.

 

[jwwbrennan]

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. When there is time to actually edit the list it will be smaller again. (For the most part we only use AMC 21 and Galaxy 19 but keep a few others for curiosity and testing.) It is easier to use MaZ to add and delete satellites than to keep an updated and comprehensive list of all visible satellites.