Announcement

Collapse
No announcement yet.

DSR6000 Hard Drive Upgrade Problems

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • DSR6000 Hard Drive Upgrade Problems

    Hi folks,

    Well, the audio/video stuttering on my old series 1 DSR6000 with original two drives (30G and 15G) is forcing me to upgrade. I purchased a 160 MB Seagate DB35, partitioned it with the Seagate DiskWizard and then formatted it using fat32format as I don't have a 98 boot disk.

    I connected my drives as follows in my PC:
    - Primary Master: CD
    - Primary Slave: DB35
    - Secondary Master: TiVoA
    - Secondary Slave: TiVoB

    I'm using the interactive instructions and and selected the option to save recordings. This is where I get an error.

    /# mfsbackup -Tao - /dev/hdc /dev/hdd | mfsrestore -s 127 -r 4 -xzpi - /dev/hdb
    Scanning source drive. Please wait a moment.
    Source drive is 30 hours
    - Upgraded to 43 hours
    Uncompressed backup size: 40139 megabytes
    Restore failed: Backup target not large enough for entire backup by itself
    /# king up 1 of 40139 megabytes (0.00%)


    I get the following related to the drives during the mfstools initialization sequence, so I don't think its a locking issue.

    hdb: 268435455 sectors (137439 MB) w/...
    hdb: 58633344 sectors (30020 MB) w/...
    hdb: 29336832 sectors (15020 MB) w/...

    Partition check:
    hdb: hdb2 < hdb5 >
    hdc: Signature 1492, be16 Signature 9214
    16:00: block 0 has signature 9214 rather than 1492
    unknown partition table
    hdd: Signature 1492, be16 Signature 9214
    16:40: block 0 has signature 9214 rather than 1492
    unknown partition table

    Given the following, it looks like there is no issue with the source drives other than that drive B is going bad.

    /# mfsinfo /dev/hdc /dev/hdd
    MFS volume set for /dev/hdc and /dev/hdd
    The MFS volume set contains 6 partitions
    /dev/hdc10
    MFS Partition Size: 512MiB
    /dev/hdc11
    MFS Partition Size: 11403MiB
    /dev/hdc12
    MFS Partition Size: 512MiB
    /dev/hdc13
    MFS Partition Size: 15746MiB
    /dev/hdd2
    MFS Partition Size: 4MiB
    /dev/hdd3
    MFS Partition Size: 14320MiB
    Total MFS volume size: 42497MiB
    Estimated hours in a standalone TiVo: 43
    This MFS volume may be expanded 3 more times


    Not sure if an mfsinfo is supposed to show more than this for the new drive?

    /#mfsinfo /dev/hdb
    /dev/hdb10: Success
    mfs_load_volume_header: mfsvol_read_data: Input/output error

    If I run chkdsk from a DOS prompt on the DB35 drive I get the following:

    The type of the file system is FAT32.
    Volume Serial Number is 0FF7-3E0E
    Windows is verifying the files and folders...
    File and folder verification is complete.
    Windows has checked the file system and found no problems.
    156,242,112 KB total disk space.
    156,242,080 KB are available

    32,768 bytes in each allocation unit.
    4,882,566 total allocation units on disk.
    4,882.565 allocation units available on disk.


    Any help is most appreciated.

    Gidday,
    Jim

  • #2
    Meant 160 GB DB35 drive, not 160 MB.

    Comment


    • #3
      The problem is that you can't put three sets of partitions on one drive. You've got one set on each of these drives, and, with the "x" in your restore string, you're asking for a third set of partitions to use the extra space on the new drive.

      So you can either do this without recordings (but with settings) and get all of the space on the new drive, or you can do it without expansion, keeping the recordings, but limiting the space to the original combined size.
      Been here a long time . . .

      Comment


      • #4
        Michael,

        Just wanted to thank you for the time to post the reply. Used the command that doesn't save the recordings and I'm now running with the bigger disk, and better yet, no more stuttering.

        Gidday,
        Jim

        Comment


        • #5
          Great. So it sounds like the stuttering was due to a bad drive, and the problems on the drive didn't affect the OS.
          Been here a long time . . .

          Comment


          • #6
            That is correct. When I booted drive B in my PC the S.M.A.R.T diagnostics flagged it. I'm guessing that either the OS is on drive A or the sectors on the drive that were problematic was where recordings were stored vs. the OS.

            Comment


            • #7
              Yup - the OS is entirely on the A drive (although the B drive generally needs to be able to at least limp along to cooperate with an OS copy).
              Been here a long time . . .

              Comment

              Working...
              X