I fixed a bug in our server software that probably has been causing trouble on both servers. It certainly has been why the new server stops was stopping at the top of the hour if it was started not at the top of the hour. So for example, if you started a player at 2:45 pm then it would stop at 3:00 pm. But if you started at 2:00 pm then you had a chance of it playing through.
I corrected the bug on both servers and it seems to make a big difference.
If youāre interested, weāre using kaltura/nginx-vod-module in mapped mode.
For example, if the request is
https://ark3.spinitron.com/ark2/KSJD-20220115T085000Z/index.m3u8
then the mapper response is
{
"discontinuity": false,
"referenceClipIndex": 1,
"clipFrom": 3000000,
"durations": [
3600533,
3600463,
3600091,
3600765,
3600533
],
"sequences": [
{
"clips": [
{
"type": "source",
"path": "/home/debian/ark/var/audio/KSJD/KSJD-20220115T080000Z.mp4"
},
{
"type": "source",
"path": "/home/debian/ark/var/audio/KSJD/KSJD-20220115T090000Z.mp4"
},
{
"type": "source",
"path": "/home/debian/ark/var/audio/KSJD/KSJD-20220115T100000Z.mp4"
},
{
"type": "source",
"path": "/home/debian/ark/var/audio/KSJD/KSJD-20220115T110000Z.mp4"
},
{
"type": "source",
"path": "/home/debian/ark/var/audio/KSJD/KSJD-20220115T120000Z.mp4"
}
]
}
]
}
Prior to the most recent fix "clipFrom": 3000000
was inside the first of the objects in the clips
array.
I think this also explains why the old server works ok for some streams and not for others. Some streams including KCSM had very irregular clip duration (idk why) but this would cause more HLS streams to include a clipFrom
field in the wrong place. Streams that produced nicely regular 5-minute clips were less likely to need the field.
And when the firt clip had a clipFrom
field then the HLS server would return a series of empty .ts
segments to make up the missing duration. Some players can tolerate empty segments while others cannot.