GEOSATpro HD DVR Recording Playback Problem

In each sample I tested, there is always a duplicate of 48128 bytes from the last file repeated in the next file. Is this a pointer or buffer set incorectly with this version of code? Any chance of this duplicate being addressed in a future update. It does play back on the microHD fine in most cases, but is a real problem for those wanting to play the files back on other devices. I have not yet found a quick and easy way to cut this 48128 bytes from the start of a file without adding in their own bytes to the start of the file.

The sequential DVR recording file formatting is established in the ALI code to reference and synchronize multiple TS file playback. The files are built and provide seamless playback using the microHD or any other ALI based STB.

We are able to modify the firmware for file default size, but unable to modify the ALI file build routine including data overlap.

The export of files for playback on another platform or software may introduce issues that are not present with playback on an STB. Modifying the sequential file creation for a secondary purpose and causing potential playback issues on the primary playback device makes no sense.

I am sure that there are 3rd party solutions for trimming duplicate data during TS file combining. I would think that the error that you are reporting in attempting to trim files is caused by deleting data without modifying the file header, so null packets are inserted.

Larry1 said:

It does play back on the microHD fine in most cases, but is a real problem for those wanting to play the files back on other devices.

Click to expand...

This statement conflicts with your January 15 post indicating that DVR recordings had playback issues at the file transition points. Please clarify if your microHD playback IS or IS NOT affected at the file transition points.

I am going to have to check some more files. The recording I was using for a sample to base that post on, I no longer have. At that time it did have a blip at the join point when played back on the microHD, and also when played back on the computer. I single stepped through the join point on my PC while also single stepping the microHD on my TV to compare the frames. I just checked two join ponts on a different file, and it plays back fine on the microHD, but produces a blip when played back on a PC. Now I will check a good selection of my recordings as this sample size is too small.
WRBreland, can you check some of your mpeg-4 files as my files are all mpeg-2.

I continue to be confused by your posts indicating multiple samples and tests providing the same results, but now it is a single sample for each test?

What did you mean in this morning's post about all files having the extra 48128 bytes, but play back fine on the microHD. Was this statement based only on a single sample test?

The first timer recordings after hooking up my new microHD did have slight breakups at the point of where the file change occured. This happened on a least 2 files at that time that were checked/played back on the microHD and one file was single stepped through frame by frame. The other recordings may only have been confirmed on the PC and not on the microHD. I did not check all my recordings at that time (as i should of) as this behaviour seemed to be common as well as this thread about the playback blip. This is why I did not place more concern on keeping these inital recordings as they were not programs I was concerned about keeping. These were just test recordings to see how the box functioned and to figure out how to timer record. (I had it setup to channel for my first try and then figured out I had to change it to record) I have now gone through at least two dozen join points trying to find more recordings that show this behaviour, (blip in the recording when playing back through the microHD with the original, unedited files) but have been unable to find any. Most of these join points show signs of video breakup when transfered to a PC and a simple binary added together or combined and played on a PC. A sample of one of the recordings was sent to VideoReDo to see why the files when joined together did not play back smoothly on the PC but played fine on the microHD. I only sent a sample of one join point for them to investigate. What they found out was that the last 48128 bytes of the first file was repeated as the first 48128 bytes of the second file. (which as you explained is due to the ALI file build routine and if it plays fine on the microHD it is not an error) Now with this information I have on at least 5 recordings so far that have multiple pieces (3 to 7 pieces each) to get them to play on a PC without a blip in the playback, I take the second piece of the ts file (that is the file 001.ts) and load it into my hex editor. I remove, or cut out the first 48128 bytes of the file. Only the remaining bytes are left in the 001.ts file. I do the same for each subseqent file of that recording. i.e. 002.ts, 003.ts, 004.ts etc..... Then these file pieces are either binary copied to a single file (dos command in a previous post) or loaded into VideoReDo with the combine option. So far this has worked fine for my recordings that are transfered and played back on my PC or other media player devices. I am not transfering these edited files back to the microHD. I am only playing the originaly recorded, unmodified files on the microHD.
Now also, since those first recordings I have changed the clock GMT on and off a few times as well as a Factory Reset and tried other settings as well. (it should be noted that this fixed my timer issue as discussed in another thread) As it seemed common, I did not note which USB sticks this happened on or if I did confirm the abberation happened on the microHD with ALL the USB sticks or only on the PC. At the time I was more concerned about the PC playback and not the microHD playback. I no longer have these original recording files, only the files since the clock change and factory reset. (that playback fine on the microHD)

Understood. Thanks for clarifying!

Again, the segmented .TS files may be joined by TSDoctor and the resulting single file played back without any glitches of any kind.

Tried TS-Doctor and the file produced still showed a blip at what was the join point. Did you have to set any special settings?

That's strange. Doesn't do that for me. Were the original .TS files modified in any way?

In TSDoctor, only open the first .TS segment, and it will open the others and join them when you select 'Save New File'.

The were not modified. Just copied from the USB stick to a temporary directory on my PC's hard disk. I used the FILE, OPEN MULTPLE FILES, and then selected all the xxx.ts files. (using either CTRL key or SHIFT key)
I will try your way of only opening the first .ts file. Have you tried MPEG-2 files or MPEG-4 files or both? I've been trying with MPEG-2 files. Is your USB stick or hard disk formated FAT or NTFS?

I've used TSDoctor with both MPEG-2 and MPEG-4 streams with no issues. Using a NTFS-formatted hard drive. USB sticks (thumbdrives) can be problematical, since they usually have extremely slow write speeds. Have you tried recording directly to a hard drive and using TSDoctor with the hard drive instead of the thumbdrive?

Tron said:

I've used TSDoctor with both MPEG-2 and MPEG-4 streams with no issues. Using a NTFS-formatted hard drive. USB sticks (thumbdrives) can be problematical, since they usually have extremely slow write speeds. Have you tried recording directly to a hard drive and using TSDoctor with the hard drive instead of the thumbdrive?

Click to expand...

I've only been using USB sticks. Will have to try a hard drive.

If there is still a problem, go through the logfile that TSDoctor creates. There should be references to each file segment. Verify that the data regarding the segments corresponds correctly to the files. Here is an example of part of a logfile:

Ali file format 3.0 detected
File [0] packets: 0 - 5721856
File [1] packets: 5721856 - 11441408
File [2] packets: 11441408 - 17162752
File [3] packets: 17162752 - 22882048
File [4] packets: 22882048 - 28596224
File [5] packets: 28596224 - 34311936
File [6] packets: 34311936 - 40023552
File [7] packets: 40023552 - 45744128
File [8] packets: 45744128 - 51463680
File [9] packets: 51463680 - 57179136
File [10] packets: 57179136 - 62892032
File [11] packets: 62892032 - 68604160
File [12] packets: 68604160 - 74324224
File [13] packets: 74324224 - 80045056
File [14] packets: 80045056 - 85765632
File [15] packets: 85765632 - 91485952
File [16] packets: 91485952 - 97207040
File [17] packets: 97207040 - 102922752
File [18] packets: 102922752 - 108636672
File [19] packets: 108636672 - 114358784
File [20] packets: 114358784 - 120078080

Make 20 minute or so recording using a hard drive, and run it through TSDoctor. If there are still problems, check the logfile to see if it looks similar to the one above.

I got it working. Instead of selecting all the .ts files, I select the info3.dvr file. (it was the open multiple files where I was going wrong, when I tried as you suggested all was good) When doing this the log file then identifies the stream as Ali file format 3.0. Before it did not.
Thank You Tron for your help and persistance in getting this working.

Cool! Glad you got it working! I always run my recordings through TSDoctor in order to screen out any MPEG errors due to bad reception, encoder anomalies, etc. Also, since my PC hard drives are formatted NTFS, there is no need to keep the recordings in segmented form (they are segmented in order to maintain compatibility with older file systems such as FAT, which have a limit on file size).

Clock drift can occur if the unit is in Manual Time mode and it is repeatedly cycled through standby mode. There will be ZERO time drift in the manual time mode if the unit is left in operate mode instead of cycling through standby mode.

I can't think of a reason that the microHD would need to be placed in Standby mode between timers. I keep mine in operate mode at all times and the USB goes to sleep between recordings. Have absolutely no time drift.

Why place the microHD into Standby mode between timers?

SatelliteAV said:

Clock drift can occur if the unit is in Manual Time mode and it is repeatedly cycled through standby mode. There will be ZERO time drift in the manual time mode if the unit is left in operate mode instead of cycling through standby mode.

I can't think of a reason that the microHD would need to be placed in Standby mode between timers. I keep mine in operate mode at all times and the USB goes to sleep between recordings. Have absolutely no time drift.

Why place the microHD into Standby mode between timers?

Click to expand...

WRBreland said:

Thanks, did not know that.

Habit, custom, tradition, ritual

Click to expand...

If I may chime in here, too... I have never utilized the standby mode on any receiver, I always leave them in the FULL ON mode 24/7. Reasoning? It's always ready to go, doesn't appear to create any problems, doesn't consume enough power to change the electric bill, and I don't have to fret over whether it will start up for a recording on time. I usually expect my receiver to, when a record event is to occur, drive the motorized dish to the desired satellite, acquire a signal lock and begin recording at the start of the program. Leaving it in FULL ON MODE seems to make more sense to me as there is one less operation that must be carried out (wake up) prior to all the others. I better clarify this all by stating that I am mostly referring to the implementation of the Coolsat 5000 and the AZBox family of receivers. I now own a microHD receiver, too and I expect to utilize it just the same.

RADAR

I don't keep my microHD on 24/7, but if an event is coming up that I want to record, I power on and test everything in the system a couple of hours before the time I need the recording to start.

I'm awaiting a popular feed on 83W to go live as I type this ...