Repository: streamlink/streamlink

Issue:
stream.dash: failed to create accurate current segment $number$
### Checklist

- [X] This is a bug report and not a different kind of issue
- [X] [I have read the contribution guidelines](https://github.com/streamlink/streamlink/blob/master/CONTRIBUTING.md#contributing-to-streamlink)
- [X] [I have checked the list of open and recently closed bug reports](https://github.com/streamlink/streamlink/issues?q=is%3Aissue+label%3A%22bug%22)
- [X] [I have checked the commit log of the master branch](https://github.com/streamlink/streamlink/commits/master)

### Streamlink version

Latest stable release

### Description

I am trying to play a Dash stream from "New York". Said stream has segment caching in place they store all segments on there server for 24 hours in order to run the same stream for different time zones.

### MPD structure
```<?xml version="1.0"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:cenc="urn:mpeg:cenc:2013" xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-DASH_schema_files/DASH-MPD.xsd" profiles="urn:mpeg:dash:profile:isoff-live:2011,urn:com:dashif:dash264" maxSegmentDuration="PT2.048000S" minBufferTime="PT2.048000S" publishTime="2022-06-17T20:00:00Z" type="dynamic" minimumUpdatePeriod="PT2.048000S" availabilityStartTime="2022-06-17T20:00:15Z" mediaPresentationDuration="PT1800.000000S" suggestedPresentationDelay="PT4.096000S">
  <Period id="1" duration="PT1800.000000S" start="PT0.000000S">
    <BaseURL>/158/live/55941/</BaseURL>
    <AdaptationSet contentType="audio" mimeType="audio/mp4" segmentAlignment="true" startWithSAP="1" codecs="mp4a.40.2" lang="en">
      <SegmentTemplate timescale="1000" duration="2048" startNumber="18926" media="audio/$RepresentationID$/$Number%08d$.m4s" presentationTimeOffset="38760243"/>
      <AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"/>
      <Role schemeIdUri="urn:mpeg:dash:role:2011" value="main"/>
      <Representation id="192a158" audioSamplingRate="48000" bandwidth="196608" qualityRanking="0"/>
    </AdaptationSet>
    <AdaptationSet contentType="video" mimeType="video/mp4" segmentAlignment="true" startWithSAP="1">
      <Accessibility schemeIdUri="urn:scte:dash:cc:cea-608:2015" value="CC1=eng"/>
      <Accessibility schemeIdUri="urn:scte:dash:cc:cea-708:2015" value="1=lang:eng"/>
      <SegmentTemplate timescale="1000" duration="2048" startNumber="18926" media="video/$RepresentationID$/$Number%08d$.m4s" presentationTimeOffset="38760243"/>
      <Role schemeIdUri="urn:mpeg:dash:role:2011" value="main"/>
      <Representation id="1080v158" bandwidth="5632000" codecs="avc1.640028" width="1920" height="1080" frameRate="29970/1000" sar="1:1" qualityRanking="0"/>
    </AdaptationSet>
  </Period>
</MPD>
```

Things to note about this Dash stream is that it is a dynamic live stream that uses the "Number" segment names template and provide a "startNumber" of the current live segment for the manifest.

When i tried to play this stream in "Streamlink" i noticed that the stream was not correct and did not match up with the live stream from there platform. I then tried to play the stream using the "VLC" media player and it plays the correct stream matching up with the platform stream in fact "VLC" was about 10 seconds ahead of the platform stream.

This lead me to believe that the issue with "Streamlink" when debugging the issue there is not much error information provided because the stream still plays with no issues it just plays from cached segment
and not live. To debug and compare both i enabled http/https loggin on my system and checked what segment urls where being called.

Both "VLC" and "Streamlink" where playing the correct base url and stuff but the difference i noticed was that "VLC" was using a segment number higher than the "startNumber" specified in the manifest as it should but "Streamlink" seemed to start streaming from "0" segment number and then going up by one seemingly completely ignoring the "startNumber" specified in the manifest. At the time of creating this Bug report the manifest specified "startNumber" was set to "22442" but stream link was currently trying to play segment number "26".

### Debug log

```text
Debug log contains no use full information other than stream playing as it does play fine just the wrong segment number.
```

### 18/06/2022  Update

This is a screen shot of the streamlink stream and the default mpd link both playing on vlc at the same time 

![Untitled-1](https://user-images.githubusercontent.com/103538584/174456752-d174837e-c617-459e-84db-e7aeff532426.png)

I have done my own calculations in PHP my normal working language and managed to create the correct output from the information provided by the mpd

Sorrty the image below has a small mistake where i forgot to enter the proper manifest delay from the mpd of 4.096 but even with this small error the php code still returns a current segment number a lot closer to the proper number than streamlink is doing on playback.

![2](https://user-images.githubusercontent.com/103538584/174458275-35f94e61-159f-4d41-b79f-126d3410bf76.png)

### 19/08/2022 Update

After looking over the code in the MPD manifest as well as the code in "dash_manifest.py" from "streamlink" i can see the error comes from the fact the manifest contains "presentationTimeOffset" where the value is higher than the current segment number so on line 485 of "dash_manifest.py" where it checks for "presentationTimeOffset" it runs the calculations based on this thus we end up with a 0000 value from the calculations because the number is higher than the current segment number value.

I do not know why this number is higher than the current number value i can only guess as to it being used for timezone or playback functions with the custom player platform used by the service.

To get around this i have made some edits to the code in "dash_manifest.py" to check and make sure that it does not lead to a negative/null value when calculating and if it does to skip to the calculations with out the usage of "presentationTimeOffset" and this has now fixed my issue and "streamlink" is now providing the correct numbers for the current playback

To mitigate this issue with possible other services in the future it may be a good option to possibly allow the passing of a arg to ignore the usage of "presentationTimeOffset" when passing a dash source url this way "streamlink" does not need to mess with its current calculations but rather only check for an extra arg and skip said section and use the calculation code with out it.

### End Notes

First of all i would like to that the developers for the amazing software that is "streamlink" it works amazing and allows me to have perfect streaming all over my house on every devices with out needing loads of complicated software and apps.

Second i would like to apologise for any spelling / grammar mistakes in my bug report aka this post i do have dyslexia and i try my best to correct mistakes when i see the red line but it does take for every to go back and forth to google to find the correct spelling so sometimes i skip doing it so am sorry!
stream.dash: failed to create accurate current segment $number$
### Checklist

- [X] This is a bug report and not a different kind of issue
- [X] [I have read the contribution guidelines](https://github.com/streamlink/streamlink/blob/master/CONTRIBUTING.md#contributing-to-streamlink)
- [X] [I have checked the list of open and recently closed bug reports](https://github.com/streamlink/streamlink/issues?q=is%3Aissue+label%3A%22bug%22)
- [X] [I have checked the commit log of the master branch](https://github.com/streamlink/streamlink/commits/master)

### Streamlink version

Latest stable release

### Description

I am trying to play a Dash stream from "New York". Said stream has segment caching in place they store all segments on there server for 24 hours in order to run the same stream for different time zones.

### MPD structure
```<?xml version="1.0"?>
<MPD xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns="urn:mpeg:dash:schema:mpd:2011" xmlns:cenc="urn:mpeg:cenc:2013" xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-DASH_schema_files/DASH-MPD.xsd" profiles="urn:mpeg:dash:profile:isoff-live:2011,urn:com:dashif:dash264" maxSegmentDuration="PT2.048000S" minBufferTime="PT2.048000S" publishTime="2022-06-17T20:00:00Z" type="dynamic" minimumUpdatePeriod="PT2.048000S" availabilityStartTime="2022-06-17T20:00:15Z" mediaPresentationDuration="PT1800.000000S" suggestedPresentationDelay="PT4.096000S">
  <Period id="1" duration="PT1800.000000S" start="PT0.000000S">
    <BaseURL>/158/live/55941/</BaseURL>
    <AdaptationSet contentType="audio" mimeType="audio/mp4" segmentAlignment="true" startWithSAP="1" codecs="mp4a.40.2" lang="en">
      <SegmentTemplate timescale="1000" duration="2048" startNumber="18926" media="audio/$RepresentationID$/$Number%08d$.m4s" presentationTimeOffset="38760243"/>
      <AudioChannelConfiguration schemeIdUri="urn:mpeg:dash:23003:3:audio_channel_configuration:2011" value="2"/>
      <Role schemeIdUri="urn:mpeg:dash:role:2011" value="main"/>
      <Representation id="192a158" audioSamplingRate="48000" bandwidth="196608" qualityRanking="0"/>
    </AdaptationSet>
    <AdaptationSet contentType="video" mimeType="video/mp4" segmentAlignment="true" startWithSAP="1">
      <Accessibility schemeIdUri="urn:scte:dash:cc:cea-608:2015" value="CC1=eng"/>
      <Accessibility schemeIdUri="urn:scte:dash:cc:cea-708:2015" value="1=lang:eng"/>
      <SegmentTemplate timescale="1000" duration="2048" startNumber="18926" media="video/$RepresentationID$/$Number%08d$.m4s" presentationTimeOffset="38760243"/>
      <Role schemeIdUri="urn:mpeg:dash:role:2011" value="main"/>
      <Representation id="1080v158" bandwidth="5632000" codecs="avc1.640028" width="1920" height="1080" frameRate="29970/1000" sar="1:1" qualityRanking="0"/>
    </AdaptationSet>
  </Period>
</MPD>
```

Things to note about this Dash stream is that it is a dynamic live stream that uses the "Number" segment names template and provide a "startNumber" of the current live segment for the manifest.

When i tried to play this stream in "Streamlink" i noticed that the stream was not correct and did not match up with the live stream from there platform. I then tried to play the stream using the "VLC" media player and it plays the correct stream matching up with the platform stream in fact "VLC" was about 10 seconds ahead of the platform stream.

This lead me to believe that the issue with "Streamlink" when debugging the issue there is not much error information provided because the stream still plays with no issues it just plays from cached segment
and not live. To debug and compare both i enabled http/https loggin on my system and checked what segment urls where being called.

Both "VLC" and "Streamlink" where playing the correct base url and stuff but the difference i noticed was that "VLC" was using a segment number higher than the "startNumber" specified in the manifest as it should but "Streamlink" seemed to start streaming from "0" segment number and then going up by one seemingly completely ignoring the "startNumber" specified in the manifest. At the time of creating this Bug report the manifest specified "startNumber" was set to "22442" but stream link was currently trying to play segment number "26".

### Debug log

```text
Debug log contains no use full information other than stream playing as it does play fine just the wrong segment number.
```

### 18/06/2022  Update

This is a screen shot of the streamlink stream and the default mpd link both playing on vlc at the same time 

![Untitled-1](https://user-images.githubusercontent.com/103538584/174456752-d174837e-c617-459e-84db-e7aeff532426.png)

I have done my own calculations in PHP my normal working language and managed to create the correct output from the information provided by the mpd

Sorrty the image below has a small mistake where i forgot to enter the proper manifest delay from the mpd of 4.096 but even with this small error the php code still returns a current segment number a lot closer to the proper number than streamlink is doing on playback.

![2](https://user-images.githubusercontent.com/103538584/174458275-35f94e61-159f-4d41-b79f-126d3410bf76.png)

### 19/08/2022 Update

After looking over the code in the MPD manifest as well as the code in "dash_manifest.py" from "streamlink" i can see the error comes from the fact the manifest contains "presentationTimeOffset" where the value is higher than the current segment number so on line 485 of "dash_manifest.py" where it checks for "presentationTimeOffset" it runs the calculations based on this thus we end up with a 0000 value from the calculations because the number is higher than the current segment number value.

I do not know why this number is higher than the current number value i can only guess as to it being used for timezone or playback functions with the custom player platform used by the service.

To get around this i have made some edits to the code in "dash_manifest.py" to check and make sure that it does not lead to a negative/null value when calculating and if it does to skip to the calculations with out the usage of "presentationTimeOffset" and this has now fixed my issue and "streamlink" is now providing the correct numbers for the current playback

To mitigate this issue with possible other services in the future it may be a good option to possibly allow the passing of a arg to ignore the usage of "presentationTimeOffset" when passing a dash source url this way "streamlink" does not need to mess with its current calculations but rather only check for an extra arg and skip said section and use the calculation code with out it.

### End Notes

First of all i would like to that the developers for the amazing software that is "streamlink" it works amazing and allows me to have perfect streaming all over my house on every devices with out needing loads of complicated software and apps.

Second i would like to apologise for any spelling / grammar mistakes in my bug report aka this post i do have dyslexia and i try my best to correct mistakes when i see the red line but it does take for every to go back and forth to google to find the correct spelling so sometimes i skip doing it so am sorry!


Discussion:
> I did post this in normal discussion as i dont know if its a bug directly as it only seems to happen with these streams only others i have play fine so bit confusing really but it was closed and i was told to post a bug report here.

You were supposed to provide actual information in your bug report. What you have copy&pasted here from your previous post pretty much says "I have tried opening a stream and it didn't work correctly". That isn't something anyone here can debug.

It doesn't matter if you're not sure whether it's a bug. If it's not, then the issue will be closed. If it is, then it can be fixed. But without any useful information, this is just pointless.

Post the URL or stream manifest.
> > I did post this in normal discussion as i dont know if its a bug directly as it only seems to happen with these streams only others i have play fine so bit confusing really but it was closed and i was told to post a bug report here.
> 
> You were supposed to provide actual information in your bug report. What you have copy&pasted here from your previous post pretty much says "I have tried opening a stream and it didn't work correctly". That isn't something anyone here can debug.
> 
> It doesn't matter if you're not sure whether it's a bug. If it's not, then the issue will be closed. If it is, then it can be fixed. But without any useful information, this is just pointless.
> 
> Post the URL or stream manifest.

This is why it was placed into discussion first as i was asking a question aka having a discussion to find out if it was a bug or simply an issue with my selected service!

I was asking how the calcuations for the segment  numbers are created so i could compare them to that of vlc and the official provider to see where in lied the issue my self if possible.

As stated there is no debug log because the stream plays perfect it just plays at the wrong time frame and because the stream is rebroadcast for people in different timezones segments are still there and it works so there is no errors to the log.

I will how ever get a copy of the manifest and post it here.
@bastimeyer I have found the cause of the problem and detailed it above i am unsure of how to best go about this situation regarding closing this or marking it as answered with out having someone look over it first in case the team wishes to put a fix or patch in place.

Hopefully i have provided enough detailed information above.
> I did post this in normal discussion as i dont know if its a bug directly as it only seems to happen with these streams only others i have play fine so bit confusing really but it was closed and i was told to post a bug report here.

You were supposed to provide actual information in your bug report. What you have copy&pasted here from your previous post pretty much says "I have tried opening a stream and it didn't work correctly". That isn't something anyone here can debug.

It doesn't matter if you're not sure whether it's a bug. If it's not, then the issue will be closed. If it is, then it can be fixed. But without any useful information, this is just pointless.

Post the URL or stream manifest.
> > I did post this in normal discussion as i dont know if its a bug directly as it only seems to happen with these streams only others i have play fine so bit confusing really but it was closed and i was told to post a bug report here.
> 
> You were supposed to provide actual information in your bug report. What you have copy&pasted here from your previous post pretty much says "I have tried opening a stream and it didn't work correctly". That isn't something anyone here can debug.
> 
> It doesn't matter if you're not sure whether it's a bug. If it's not, then the issue will be closed. If it is, then it can be fixed. But without any useful information, this is just pointless.
> 
> Post the URL or stream manifest.

This is why it was placed into discussion first as i was asking a question aka having a discussion to find out if it was a bug or simply an issue with my selected service!

I was asking how the calcuations for the segment  numbers are created so i could compare them to that of vlc and the official provider to see where in lied the issue my self if possible.

As stated there is no debug log because the stream plays perfect it just plays at the wrong time frame and because the stream is rebroadcast for people in different timezones segments are still there and it works so there is no errors to the log.

I will how ever get a copy of the manifest and post it here.
@bastimeyer I have found the cause of the problem and detailed it above i am unsure of how to best go about this situation regarding closing this or marking it as answered with out having someone look over it first in case the team wishes to put a fix or patch in place.

Hopefully i have provided enough detailed information above.

Resolving patch:
diff --git a/src/streamlink/stream/dash_manifest.py b/src/streamlink/stream/dash_manifest.py
--- a/src/streamlink/stream/dash_manifest.py
+++ b/src/streamlink/stream/dash_manifest.py
@@ -622,12 +622,10 @@ def __init__(self, node, root=None, parent=None, period=None, *args, **kwargs):
         self.presentationTimeOffset = self.attr(
             "presentationTimeOffset",
             parser=MPDParsers.timedelta(self.timescale),
+            default=datetime.timedelta(),
         )
 
-        if self.duration:
-            self.duration_seconds = self.duration / float(self.timescale)
-        else:
-            self.duration_seconds = None
+        self.duration_seconds = self.duration / self.timescale if self.duration and self.timescale else None
 
         # children
         self.segmentTimeline = self.only_child(SegmentTimeline)
@@ -673,6 +671,9 @@ def segment_numbers(self) -> Iterator[Tuple[int, datetime.datetime]]:
         In the simplest case, the segment number is based on the time since the availabilityStartTime.
         """
 
+        if not self.duration_seconds:  # pragma: no cover
+            raise MPDParsingError("Unknown segment durations: missing duration/timescale attributes on SegmentTemplate")
+
         number_iter: Union[Iterator[int], Sequence[int]]
         available_iter: Iterator[datetime.datetime]
 
@@ -685,29 +686,40 @@ def segment_numbers(self) -> Iterator[Tuple[int, datetime.datetime]]:
                 number_iter = count(self.startNumber)
         else:
             now = datetime.datetime.now(UTC)
-            if self.presentationTimeOffset:
-                since_start = (now - self.presentationTimeOffset) - self.period.availabilityStartTime
-                available_start = self.period.availabilityStartTime + self.presentationTimeOffset + since_start
-            else:
-                since_start = now - self.period.availabilityStartTime
-                available_start = now
+            since_start = now - self.period.availabilityStartTime - self.presentationTimeOffset
 
             suggested_delay = self.root.suggestedPresentationDelay
             buffer_time = self.root.minBufferTime
 
-            # the number of the segment that is available at NOW - SUGGESTED_DELAY - BUFFER_TIME
-            number_offset = int(
-                (since_start - suggested_delay - buffer_time).total_seconds()
-                / self.duration_seconds,
-            )
+            # Segment number
+            # To reduce unnecessary delay, start with the next/upcoming segment: +1
+            seconds_offset = (since_start - suggested_delay - buffer_time).total_seconds()
+            number_offset = max(0, int(seconds_offset / self.duration_seconds) + 1)
             number_iter = count(self.startNumber + number_offset)
 
-            # the time the segment number is available at NOW
+            # Segment availability time
+            # The availability time marks the segment's beginning: -1
+            available_offset = datetime.timedelta(seconds=max(0, number_offset - 1) * self.duration_seconds)
+            available_start = self.period.availabilityStartTime + available_offset
             available_iter = count_dt(
                 available_start,
                 datetime.timedelta(seconds=self.duration_seconds),
             )
 
+            log.debug(f"Stream start: {self.period.availabilityStartTime}")
+            log.debug(f"Current time: {now}")
+            log.debug(f"Availability: {available_start}")
+            log.debug("; ".join([
+                f"presentationTimeOffset: {self.presentationTimeOffset}",
+                f"suggestedPresentationDelay: {self.root.suggestedPresentationDelay}",
+                f"minBufferTime: {self.root.minBufferTime}",
+            ]))
+            log.debug("; ".join([
+                f"segmentDuration: {self.duration_seconds}",
+                f"segmentStart: {self.startNumber}",
+                f"segmentOffset: {number_offset} ({seconds_offset}s)",
+            ]))
+
         yield from zip(number_iter, available_iter)
 
     def format_media(self, ident: TTimelineIdent, base_url: str, **kwargs) -> Iterator[Tuple[str, datetime.datetime]]:


Test patch:
diff --git a/tests/resources/dash/test_segments_dynamic_number.mpd b/tests/resources/dash/test_segments_dynamic_number.mpd
--- a/tests/resources/dash/test_segments_dynamic_number.mpd
+++ b/tests/resources/dash/test_segments_dynamic_number.mpd
@@ -5,15 +5,15 @@
   xmlns="urn:mpeg:dash:schema:mpd:2011"
   xsi:schemaLocation="urn:mpeg:dash:schema:mpd:2011 http://standards.iso.org/ittf/PubliclyAvailableStandards/MPEG-DASH_schema_files/DASH-MPD.xsd"
   type="dynamic"
-  availabilityStartTime="2018-05-04T13:20:07Z"
-  publishTime="2018-05-10T09:27:09"
+  availabilityStartTime="2000-01-01T00:00:00Z"
+  publishTime="2000-01-01T00:00:00Z"
   minimumUpdatePeriod="PT10S"
   minBufferTime="PT2S"
   suggestedPresentationDelay="PT40S"
   timeShiftBufferDepth="PT24H0M0S"
   profiles="urn:mpeg:dash:profile:isoff-live:2011"
 >
-  <Period id="1" start="PT12M34S">
+  <Period id="1" start="PT1M30S">
     <AdaptationSet
       mimeType="video/mp4"
       frameRate="25/1"
@@ -23,24 +23,24 @@
       subsegmentStartsWithSAP="1"
       bitstreamSwitching="false"
     >
-      <SegmentTemplate timescale="90000" duration="450000" startNumber="1"/>
+      <SegmentTemplate timescale="90000" duration="450000" startNumber="100"/>
       <Representation id="1" width="1280" height="720" bandwidth="2400000" codecs="avc1.64001f">
-        <SegmentTemplate duration="450000" startNumber="1" media="hd-5_$Number%09d$.mp4" initialization="hd-5-init.mp4"/>
+        <SegmentTemplate media="hd-5_$Number%09d$.mp4" initialization="hd-5-init.mp4"/>
       </Representation>
       <Representation id="2" width="1280" height="720" bandwidth="1250000" codecs="avc1.64001f">
-        <SegmentTemplate duration="450000" startNumber="1" media="hd-4_$Number%09d$.mp4" initialization="hd-4-init.mp4"/>
+        <SegmentTemplate media="hd-4_$Number%09d$.mp4" initialization="hd-4-init.mp4"/>
       </Representation>
       <Representation id="3" width="640" height="360" bandwidth="950000" codecs="avc1.4d401e">
-        <SegmentTemplate duration="450000" startNumber="1" media="hd-3_$Number%09d$.mp4" initialization="hd-3-init.mp4"/>
+        <SegmentTemplate media="hd-3_$Number%09d$.mp4" initialization="hd-3-init.mp4"/>
       </Representation>
       <Representation id="4" width="640" height="360" bandwidth="650000" codecs="avc1.4d401e">
-        <SegmentTemplate duration="450000" startNumber="1" media="hd-2_$Number%09d$.mp4" initialization="hd-2-init.mp4"/>
+        <SegmentTemplate media="hd-2_$Number%09d$.mp4" initialization="hd-2-init.mp4"/>
       </Representation>
       <Representation id="5" width="640" height="360" bandwidth="350000" codecs="avc1.4d401e">
-        <SegmentTemplate duration="450000" startNumber="1" media="hd-1_$Number%09d$.mp4" initialization="hd-1-init.mp4"/>
+        <SegmentTemplate media="hd-1_$Number%09d$.mp4" initialization="hd-1-init.mp4"/>
       </Representation>
       <Representation id="6" width="160" height="90" bandwidth="110000" codecs="avc1.4d400b">
-        <SegmentTemplate duration="450000" startNumber="1" media="hd-0_$Number%09d$.mp4" initialization="hd-0-init.mp4"/>
+        <SegmentTemplate media="hd-0_$Number%09d$.mp4" initialization="hd-0-init.mp4"/>
       </Representation>
     </AdaptationSet>
     <AdaptationSet
diff --git a/tests/stream/test_dash_parser.py b/tests/stream/test_dash_parser.py
--- a/tests/stream/test_dash_parser.py
+++ b/tests/stream/test_dash_parser.py
@@ -109,8 +109,9 @@ def test_segments_dynamic_time(self):
             ]
 
     def test_segments_dynamic_number(self):
+        # access manifest one hour after its availabilityStartTime
         with xml("dash/test_segments_dynamic_number.mpd") as mpd_xml, \
-             freeze_time("2018-05-22T13:37:00Z"):
+             freeze_time("2000-01-01T01:00:00Z"):
             mpd = MPD(mpd_xml, base_url="http://test/", url="http://test/manifest.mpd")
             stream_urls = [
                 (segment.url, segment.available_at)
@@ -118,25 +119,21 @@ def test_segments_dynamic_number(self):
             ]
 
         assert stream_urls == [
-            # The initialization segment gets its availability time from
-            # the sum of the manifest's availabilityStartTime value and the period's start value, similar to static manifests
             (
                 "http://test/hd-5-init.mp4",
-                datetime.datetime(2018, 5, 4, 13, 32, 41, tzinfo=UTC),
+                datetime.datetime(2000, 1, 1, 0, 1, 30, tzinfo=UTC),
             ),
-            # The segment number also takes the availabilityStartTime and period start sum into consideration,
-            # but the availability time depends on the current time and the segment durations
             (
-                "http://test/hd-5_000311084.mp4",
-                datetime.datetime(2018, 5, 22, 13, 37, 0, tzinfo=UTC),
+                "http://test/hd-5_000000794.mp4",
+                datetime.datetime(2000, 1, 1, 0, 59, 15, tzinfo=UTC),
             ),
             (
-                "http://test/hd-5_000311085.mp4",
-                datetime.datetime(2018, 5, 22, 13, 37, 5, tzinfo=UTC),
+                "http://test/hd-5_000000795.mp4",
+                datetime.datetime(2000, 1, 1, 0, 59, 20, tzinfo=UTC),
             ),
             (
-                "http://test/hd-5_000311086.mp4",
-                datetime.datetime(2018, 5, 22, 13, 37, 10, tzinfo=UTC),
+                "http://test/hd-5_000000796.mp4",
+                datetime.datetime(2000, 1, 1, 0, 59, 25, tzinfo=UTC),
             ),
         ]