GEOSATpro Is there any "disk maintaining" needed....in attached hard drive on Micro HD?

To clarify:

Attach a virgin USB to the microHD. This will create a DVR folder and two test recordings on the new drive.

Disconnect from the microHD and connect to a PC.

Transfer a problematic DVR recoding file from the old drive DVR folder to the new drive DVR folder.

Now check if the microHD plays the file from the DVR screen.

What firmware version/date is installed?

How were the files renamed? Are the folders, thumbnails renamed or only the TS?

What file format? NTFS or FAT32?
 
To clarify:

Attach a virgin USB to the microHD. This will create a DVR folder and two test recordings on the new drive.

Disconnect from the microHD and connect to a PC.

Transfer a problematic DVR recoding file from the old drive DVR folder to the new drive DVR folder.

Now check if the microHD plays the file from the DVR screen.

What firmware version/date is installed?

How were the files renamed? Are the folders, thumbnails renamed or only the TS?

What file format? NTFS or FAT32?

Thanks for clarification. I put the videos in the newly MHD created file folders on the USB stick. The DVR menu now sees the videos but I get a blue screen when I try to play them.

The original USB hard drive is 1TB FAT32. The USB stick used for the test you suggested is NTFS.

Firmware: installed the most recent load you posted in Dec/12. See screen grab below


Re file renaming; one file was renamed via DVR menu, a 2nd was renamed via PC desktop..but only the folder name was renamed in this later case. IMG_6955.JPG
 
It appears that the file headers on these DVR recordings have been corrupted. Short of using a PC to rebuild the TS or transfer the DVR TS recording to a video file format, I have no other suggestions.

Lets see if any other reports surface. At this point, it is an isolated incident of undetermined cause.
 
It appears that the file headers on these DVR recordings have been corrupted. Short of using a PC to rebuild the TS or transfer the DVR TS recording to a video file format, I have no other suggestions.

Lets see if any other reports surface. At this point, it is an isolated incident of undetermined cause.

I hear ya. It does seem odd though that 34 files suddenly have their headers corrupted but appear clean via PC or VideoRedo.

Are there any suggestion that could minimize the chance of file/header corruptions eg NTFS vs FAT32. Any benefit to having the MicroHD format the drive as a start?
 
Always best to have the primary multimedia device format the drive. STBs memory management is on a very basic level compared to a PC.

Can't recommend how to minimize risk since we have no idea what caused the issue. Could it be an indexing issue that is ignored by a PC or????
 
Had the file corruption issue this morning. It had not shown up before. I recorded a short test clip before recording a feed, then I went in to delete the test clip. That is when the problems started. After re-accessing the DVR menu, none of my previous recordings worked right EXCEPT for the first recording on the drive. The rest of the recordings wouldn't play, and at first showed up with the same names as the first recording. Then, after I rebooted the micro, they showed up as their proper names but still wouldn't play (blue screen and playback much faster than 1x).

Again, this problem only happened after I deleted a recording. Here are some pieces of information that may be helpful:

-The previous recordings were made using much older firmware (from July)
-The new recording (this morning) was made using current firmware.
-The first file on the drive still plays and displays properly in the DVR menu.

Hope that helps...
 
Found that the identical file naming in the DVR Recording list is a result of an error occurring in the drive's Master File Table (MFT). The actual files have the correct name and date attached, but the drive's data management has been corrupted and the incorrect information is displayed by the microHD. This may occur due to bad drive sectors or incorrect reporting.

A NTFS drive MFT table can usually be rebuilt in order to save important files. This can be done on a PC using Window disk management software. It is recommended to perform a low level format of the drive to prevent future errors.

  • Open the PC command prompt
  • Type "chksk (letter of drive):/f
This prompt will scan the files and attempt to correct any errors.
 
I experimented with the files I lost the ability to playback on the micro and was never able to recover any of them (as discussed in another thread).

Although they play perfectly on a PC and show no signs of errors when tested by various system utilities. For fun I was thinking about rolling back to the FW they were created with and trying them.
 
I experimented with the files I lost the ability to playback on the micro and was never able to recover any of them (as discussed in another thread).

Although they play perfectly on a PC and show no signs of errors when tested by various system utilities. For fun I was thinking about rolling back to the FW they were created with and trying them.
Changing the FW won't help you either. I have run into the same problems you are having about a dozen times. Once this error occurs you can never play the files again on the microHD. I have tried 3 different hard drives and all versions of FW - this is a problem with the box itself. I lost 92gb of shows that I haven't watched yet, now I have to watch them on my PC. That is the final straw, I disconnected the MicroHD and threw it in the corner. My Openbox & Azbox never had this problem and I have made thousands of recordings with both of them. I don't know if this problem will ever be ironed out but I'm not taking any more chances. I have never run into this kind of frustration before and I've owned just about every brand of STB. I couldn't heartily recommend this half working oddity with a major problem with the DVR malfunctioning.
 
Changing the FW won't help you either. I have run into the same problems you are having about a dozen times.

Before this week, we have heard only one report of this issue by another user. If this is such a problem, why is the first that we have heard from you about this?

I have requested several users to provide us a sample file with this issue, but no one has yet been able to provide us a sample.

Instead of simply ranting and throwing the microHD in a corner, how about helping us identify the problem? Would you post one or two samples on a file sharing site and PM the link?

If we have a few samples, we could identify what is occurring.
 
Brian, I have been extremely busy and rarely home during the past week, but I still intend to send you a sample file (or set of .DVR files). I may be able to get it to you via a PM tomorrow.

I don't think the problem is with the files themselves, but rather how they are indexed by the micro's DVR utility (which might have changed in later FW revisions). Just a guess though. The issue where hitting the yellow button would instantly delete a file without prompting was still there in the July FW which was used to make these recordings.

Since the recordings are still intact, I find this to be only a minor inconvenience, as my content is usually remuxed via TSDoctor into .TS files for PC use anyway.
 
Last edited:
We wish to look at a problematic DVR recording file as the report is that these files cannot be simply copied to another drive for successful playback. If this is the case, it is not a drive mapping issue as we previously identified and were able to fix with a drive first aid.

If a DVR recoding file cannot be played from a new drive after copying with a PC, the issue must be with the file compatibility. I agree that firmware changes should be able to address this, but the changes can only be made if we have a problematic file to test.
 
Could I upload a zip of the DVR folder containing a problematic recording here to SatelliteGuys? It wouldn't be too large. This is the only way I can think of to make the file available, as I do not have access to an online file sharing site.
 
We wish to look at a problematic DVR recording file as the report is that these files cannot be simply copied to another drive for successful playback. If this is the case, it is not a drive mapping issue as we previously identified and were able to fix with a drive first aid.

If a DVR recoding file cannot be played from a new drive after copying with a PC, the issue must be with the file compatibility. I agree that firmware changes should be able to address this, but the changes can only be made if we have a problematic file to test.

Most of my recording are HD PBS programs therefore are typically 1-2GB. How do I suggest I provide them to you?
 
I found a short file that should help with figuring out why the updated microHD won't play back files from older firmware. It's a .TS from before my firmware update, and was recorded on December 1st, during a well-known feed on 83W. The video is just black, with a burned-in subtitle. It will no longer play as a DVR recording on my microHD, but will play without problems on a PC in Media Player Classic or any other media player. On the microHD, it shows as a blue screen, and appears to play at about 3-4x normal speed, judging by the time reference.

Since I do not have access to a file sharing site, I tried to send it via PM, but couldn't attach it. I tried to attach it here, but at 171 mb it is too large. Is there any way I can upload this file to Satelliteguys for Brian to get it? Also, do you need the associated .DVR file in addition to the .TS file? Thanks!
 
Last edited:
Interested in seeing an example of this error as it has only occurred with a few users.

Will PM you before the end of the week with a private FTP and password.

Zip the entire recording folder including the .ts and the TWO .dvr files.
 
Will do. The clip is one minute 15 seconds long, and there's a bit of picture at the end. It is a 1080i stream.

Thanks Brian! Maybe we can solve this thing. The two .DVR files might contain the answer :) ...
 

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

Who Read This Thread (Total Members: 1)

Latest posts