Results 1 to 4 of 4

Thread: DVR timecode and 'store not found' issues

  1. #1
    Join Date
    Jan 2011
    Posts
    14

    Default DVR timecode and 'store not found' issues

    Hi.
    We have experienced odd behavior for one on our streams.

    2 days ago one stream became corrupted:

    200	-	CupertinoPacketHandler.handlePacket[DVR_APP/_definst_/HD_720.stream]: Timecode out of order [video]: 95445745:190887393	-	-	-	111042.354	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-24	20:48:53	UTC	comment	server	WARN	200	-	DvrPacketHandler.handlePacket[]: Timecode out of order [video]: 95445745:190887393	-	-	-	111042.354	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-24	20:48:53	UTC	comment	server	WARN	200	-	SanJosePacketHandler.handlePacket[DVR_APP/_definst_/HD_720.stream]: Timecode out of order [video]: 95445745:190887393	-	-	-	111042.354	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-24	20:48:53	UTC	comment	server	WARN	200	-	LiveStreamPacketizerSmoothStreaming.handlePacket[DVR_APP/_definst_/HD_720.stream]: Timecode out of order [video]: 954457450000:1908873930000	-	-	-	111042.379	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-24	20:48:53	UTC	comment	server	WARN	200	-	LiveStreamPacketizerSmoothStreaming.resetStream[DVR_APP/_definst_/HD_720.stream][0:11]: Timecodes jumped back in time.	-	-	-	111042.774	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-24	20:48:53	UTC	comment	server	WARN	200	-	CupertinoPacketHandler.resetStream[DVR_APP/_definst_/HD_720.stream][0:11]: Timecodes jumped back in time.	-	-	-	111042.774	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-24	20:48:53	UTC	comment	server	WARN	200	-	DvrPacketHandler.resetStream[][0:11]: Timecodes jumped back in time.	-	-	-	111042.774	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-24	20:48:53	UTC	comment	server	WARN	200	-	SanJosePacketHandler.resetStream[DVR_APP/_definst_/HD_720.stream][0:11]: Timecodes jumped back in time.	-	-	-	111042.774	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-24	20:48:55	UTC	comment	server	WARN	200	-	LiveStreamDvrRecorder.endChunk[DVR_APP/_definst_/HD_720.stream]: Recalculating video duration by estimating.  Was -95438968.  Is now 1400.	-	-	-	111043.949	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-24	20:48:55	UTC	comment	server	WARN	200	-	DvrStreamStoreBase.storeChunks[DVR_APP/_definst_/HD_720.stream/HD_720.stream.0] : Skipping chunk. A/V durations differ by 2745 ms, more than allowed 2000 ms.   aDuration=4145 vDuration=1400	-	-	-	111043.95	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-24	20:48:55	UTC	comment	server	INFO	200	-	LiveStreamDvrRecorder.endChunk[DVR_APP/_definst_/HD_720.stream]: Skip chunk: a/v/k: packets: 141/35/0 durations: 4145/1400/-1	-	-	-	111043.95	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-24	20:48:57	UTC	comment	server	WARN	200	-	DvrStreamStoreBase.storeChunks[DVR_APP/_definst_/HD_720.stream/HD_720.stream.0] : Skipping chunk. A/V packet times differ by 95443095 ms, more than allowed 2000 ms.   aTime=190890160 vTime=95447065	-	-	-	111046.747	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-24	20:48:57	UTC	comment	server	INFO	200	-	LiveStreamDvrRecorder.endChunk[DVR_APP/_definst_/HD_720.stream]: Skip chunk: a/v/k: packets: 111/66/0 durations: 2369/2640/-1	-	-	-	111046.747	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-24	20:49:00	UTC	comment	server	WARN	200	-	DvrStreamStoreBase.storeChunks[DVR_APP/_definst_/HD_720.stream/HD_720.stream.0] : Skipping chunk. A/V packet times differ by 95442823 ms, more than allowed 2000 ms.   aTime=190892528 vTime=95449705	-	-	-	111049.264	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-24	20:49:00	UTC	comment	server	INFO	200	-	LiveStreamDvrRecorder.endChunk[DVR_APP/_definst_/HD_720.stream]: Skip chunk: a/v/k: packets: 126/66/0 durations: 2689/2640/-1	-	-	-	111049.264	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-	-
    2013-08-24	20:49:00	UTC	comment	server	INFO	200	-	Available start date: Tue Aug 20 20:36:43 UTC 2013, a
    Today it became normal again and we can see this streams as Live, but not DVR. And there are 2 log entries:

    WARN	server	comment	2013-08-26	11:27:09	250138.222	-	LiveStreamPacketizerSmoothStreaming.handlePacket[DVR_APP/_definst_/HD_720.stream]: Fragment duration greater than suggested range of 1-4 seconds. Adjust keyframe interval accordingly: Fragment durations: [71.8,1.3,1.3]
    WARN	server	comment	2013-08-26	11:28:10		250199.621	-	DvrStreamManagerBase.addManifestEntries[DVR_APP/_definst_/HD_720.stream] :  store not found for vStream:HD_720.stream.0
    And in file system we have folders:
    drwxr-xr-x 2 root root 24K Aug 24 20:48 0237_40_00
    -rw-r--r-- 1 root root 254 Aug 26 11:28 manifest.txt
    drwxr-xr-x 2 root root 20K Aug 26 11:28 0333_40_00
    1) Why this stream became corrupted with huge A/V packet times differ by 95443095 ms?
    2) Why DVR recording didn't start when the stream became normal again?

    Thanks

  2. #2
    Join Date
    Dec 2007
    Posts
    21,962

    Default

    We discussed this today. We're not sure what might have happened re #2. You might just be trying to play a stream that does not exist. In any case, there is no practical way to look back. If the store does not exist there is nothing you can do. There have been nDVR fixes in recent patches, so make sure you are up to date. If you have Wowza version 3.6.2.00 or higher you can apply the development patch

    The timecode problems are a problem with the source or the network, upstream from Wowza.

    The A/V alignment is a problem for nDVR, which does not record packets when audio and video are not aligned. Try applying dvrPacketSortTime shown in the nDVR advanced guide to fix.

    dvrPacketSortTime
    Adds a packet sorter before the audio and video packets get to Wowza nDVR. The unit is in milliseconds (ms). The default value (0) means that no sorting occurs. This is similar to the live streaming packet sorter. This adds additional latency equal to the value. It is recommended to fix audio and video alignment upstream from Wowza Server, but this setting can be used if that is not possible.

         <Property>
              <Name>dvrPacketSortTime</Name>
              <Value>0</Value>
              <Type>Integer</Type>
         </Property>
    Richard

  3. #3
    Join Date
    Jan 2011
    Posts
    14

    Default

    Hi Richard.
    This stream is streamed continuously from an encoder. And it's been recorded to DVR buffer before alignment issue happened.
    If the store does not exist there is nothing you can do.
    I'm not fully understand what does it means. When I start a new stream, Wowza creates new store for the stream. But in our case is just said: "Store not found" and didn't try to create one or do something else. And what is meant by 'store': is it physical folder to store files or somethings else? Because this stream has already been recorded and we had folders for it with 1 day of video recorded.

    About alignment issue: we'll try dvrPacketSortTime to fix it.
    Is it correct, that we should use value less than dvrAllowableAVPacketDelta=2000 (default)?

    Thanks!

  4. #4
    Join Date
    Dec 2007
    Posts
    21,962

    Default

    No, dvrPacketSortTime is not constrained by dvrAllowableAVPacketDelta. The dvrAllowableAVPacketDelta setting is the tolerance for a/v synch issues, as described in nDVR Advanced Guide. dvrPacketSortTime will hopefully prevent that allowance from being exceeded.

    Yes, a store is the DVR folders and recordings.

    Richard

Similar Threads

  1. Detect if stream is a DVR store stream
    By Meinaart in forum Wowza nDVR
    Replies: 1
    Last Post: 02-11-2014, 04:58 AM
  2. Replies: 9
    Last Post: 06-28-2013, 03:24 PM
  3. PushPublish 3.5 to Akamai timecode issues.
    By bmckim in forum AddOn: Other AddOns
    Replies: 17
    Last Post: 03-12-2013, 07:36 PM

Posting Permissions

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