Unable to playback videos on source resolution (transcoded resolutions work fine).

[KuJoe]

Describe the current behavior
When attempting to playback any videos at the source resolution it never starts, it downloads a bunch of segments but then ultimately fails.

Steps to reproduce:

1. Attempt to watch any video on my instance (example: https://videopen.net/w/aMvHNqTxb6KzCsbhvW4zJj)
2. Switch quality to source (720p).
3. Wait for X to appear.

Describe the expected behavior
Expected behavior is for the video to playback like it does with the 480p quality.

Additional information
I am hosting the video files on object storage (Backblaze B2) and using Cloudflare for the CDN. I migrated this instance to a new server less than a month ago but I'm just now noticing these issues (the video in the example above was able to be played back in 720p when it was uploaded originally).

In the Developer Tools I am seeing a lot of errors, this one is the most common:

Segment error. {id: 'https://cdn.videopen.net/file/videopenvid/streamin…9672-2a3b-4c79-b353-20484a487a7b-master.m3u8+V0+0', url: 'https://cdn.videopen.net/file/videopenvid/streamin…aa-c077-4178-a420-b41e5491351f-720-fragmented.mp4', masterSwarmId: 'https://cdn.videopen.net/file/videopenvid/streamin…/dfbc9672-2a3b-4c79-b353-20484a487a7b-master.m3u8', masterManifestUri: 'https://cdn.videopen.net/file/videopenvid/streamin…/dfbc9672-2a3b-4c79-b353-20484a487a7b-master.m3u8', streamId: 'V0', …} Error: Hashes does not correspond for segment b7d65eaa-c077-4178-a420-b41e5491351f-720-fragmented.mp4/1322-465315(expected: dd9833b413ec391b17baa484228eb5eb912f3c3802f19d141564d5c8d236c4c5 instead of c7035e33b614532317876ada348a8f6dcd34cf9ab16d31e93c71198fde110af3)
    at Object.<anonymous> (segment-validator.ts:54:13)
    at Generator.next (<anonymous>)
    at Xe (cjs.js:73:43)
    at i.invoke (zone.js:372:26)
    at vt.run (zone.js:134:43)
    at zone.js:1275:36
    at i.invokeTask (zone.js:406:31)
    at vt.runTask (zone.js:178:47)
    at W (zone.js:585:35)

• PeerTube instance:

  • URL: https://videopen.net
  • version: 4.2.0
  • NodeJS version: v17.9.0
  • Ffmpeg version: ffmpeg version 4.2.7-0ubuntu0.1
  • OS: Ubuntu 20.04.4 LTS

• Browser name, version and platforms on which you could reproduce the bug: Edge 102.0.1245.39, Chrome 102.0.5005.115, & Opera 87.0.4390.45

• Link to browser console log if relevant: https://kujoe.net/uploads/videopen.net-1655008313217.log

• Link to server log if relevant (journalctl or /var/www/peertube/storage/logs/): Nothing in journalctl regarding this when reproducing the problem.

[KuJoe]

I'm attempting to re-transcode the video and then move the files to object storage to see if that has any impact. I should have tried this before opening the issue.

EDIT: Re-transcoding did not fix the issue. The source quality still does not play but all of the transcoded qualities work fine.

[Chocobozzz]

Hello,

It seems there is an issue with the byte range request. PeerTube asks some parts of the video using Range HTTP header. But for the 720p resolution, the server sends the complete file

[KuJoe]

Hello,

It seems there is an issue with the byte range request. PeerTube asks some parts of the video using Range HTTP header. But for the 720p resolution, the server sends the complete file

I had read this same thing happened with another issue that was opened, I checked the nginx config file and I don't believe I changed anything other than the CDN information. I double checked it with the nginx config file on GitHub but I might have missed something:

Current config: https://kujoe.net/uploads/peertube.conf

[Chocobozzz]

I'm sorry but I can't help you. It seems it's a CDN or S3 server issue because PeerTube client correctly uses a byte range request for 480p and 720p.

The only difference I see between the two responses are the cache status from cloudflare:

(valid one, 480p)

cf-cache-status: HIT
age: 32
content-range: bytes 5760397-5956456/526035181

(bad one, 720p)

cf-cache-status: MISS

[KuJoe]

Thank you for that insight, it pointed me in the right direction and I believe I was able to resolve this by making the following changes on Cloudflare (posting here in case others run into this issue):

Browser Cache TTL -> Respect existing headers