Results 1 to 6 of 6

Thread: HTTPLiveStreamRecord Generating Corrupt Files

  1. #1

    Default HTTPLiveStreamRecord Generating Corrupt Files

    I am using a custom version of the HTTPLiveStreamRecord to record multiple files from one source stream via my earlier discussion here:

    I am saving the files across the network on a different server. It has been working perfectly on a server running version build3572

    However, I now have two other servers running version 3.6.2 build533 where the files are corrupt when they are saved. If I save the files locally on the same server, it works properly.

    FFMPEG reports an error reading the header and that it could not find corresponding trex.

    Any idea what has changed between those versions and what the fix might be?


  2. #2
    Join Date
    Dec 2007


    How are you moving the files? Are you using ModuleMediaWriterFileMover ?

    Or are you moving the file, or recording directly to a network drive. That might be the problem, in which case using the above is suggested practice, i.e. record to local content folder, then with the above Module configured Wowza will move the file when recording is finished.

    If you are already moving after record, might be related to the move, in which case it would be a network problem during that move, but it is more likely just a bad recording, which does happen occasionally, also probably due to network problems. If you were recording to an .mp4 container you would see a .tmp folder with the same name in the content folder where the stream was recorded to file. The .mp4 file in that case is not recoverable.

    Otherwise, can you replicate this, does it happen consistently?


  3. #3


    Quote Originally Posted by rrlanham View Post
    How are you moving the files? Are you using ModuleMediaWriterFileMover ?
    Or are you moving the file, or recording directly to a network drive.

    Otherwise, can you replicate this, does it happen consistently?
    I'm recording it directly across the network - I'm not moving it. It fails pretty much every time.

    Again it works perfectly in, but fails on 3.6.2.

  4. #4



    It is not recommended to record directly to a network location because of the way that Wowza handles the files when writing to them. Wowza needs to write to the files quickly and any interruption to the network could cause the files to be corrupted.. The method that Richard mentions about recording the file locally and then moving it once completed is the recommended way of doing it.

    In your corrupted recordings, do you see a file with the same name as the original recording with a tmp file extension. This file contains the atom data for the stream and should be deleted once the recording is complete. Wowza only writes to this file when the size of the atom data get larger than will fit in memory so the file doesn't contain the latest data. If the file still exists once the recording is complete, this indicates that the recording failed somehow and because the file doesn't contain a complete record of the data, it is not possible to recover the original recording.. Because you are recording across a network, you cannot rule out a network issue that has caused the problem.


  5. #5


    I'll do some more tests to check and see if the .tmp files are existing. However, the question would still remain that I have three different servers:
    Server A running version 3.5
    Server B & Server C running version 3.6.2
    All 3 are writing to a fourth server (server D) and are all on the same network.

    Server A works perfectly, servers B & C don't. A network issue seems highly unlikely. Was anything changed between those versions in regards to how you write the files or process the header when the file write is completed?

  6. #6



    There were a few changes related to recording between 3.5 and 3.6.2 but most of these would not have been related to how the recordings are actually written to the files.

    Since 3.6.2 there have been substantial changes to the recording API so it would not be possible to roll anything back that far.

    The best option may be to do the following.

    On Server B or C, install the same version that you have on Server A and confirm that the issue is with the 3.6.2 version.

    If this is the case then install the current version of Wowza Streaming Engine on that server and see if this resolves the issue.

    If the issue still exists then please zip up the conf, logs and recorded files (including any tmp files) and send them to You may need to provide a download link for the recordings if these are large. If we can provide any fix then it will be against the current release version as we cannot provide updates to old versions. Depending on what the cause is, we may not be able to do anything if it turns out to be network related as we don't support recording across a network and do provide a recommended method for transferring completed recordings.


Similar Threads

  1. Corrupted Mp4 files with GoCoder and Streaming Engine 4 HTTPLiveStreamRecord
    By eyalhasson in forum Live Streaming and Encoders
    Replies: 5
    Last Post: 06-11-2014, 05:32 AM
  2. MP4 file corrupt
    By Bernienor in forum General Forum
    Replies: 2
    Last Post: 06-02-2014, 01:28 AM
  3. Generating smil files programatically
    By tan-tan in forum AddOn: Transcoder
    Replies: 3
    Last Post: 12-25-2013, 07:01 AM

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts