[Bug] DASH playback does not work on Crystal 1.3.0

[markozajc]

Describe the bug
Playing any video with DASH on an Invidious instance compiled with Crystal 1.3.0 produces no playback a flood of the following warnings:

VIDEOJS: WARN: Problem encountered with playlist 0-placeholder-uri-0. HLS request errored at URL: http://localhost/videoplayback?expire=...&ei=...&host=... Switching to playlist 6-placeholder-uri-6.

VIDEOJS: WARN: Problem encountered with playlist 5-placeholder-uri-5. Problem encountered loading the default audio track. Switching to playlist 4-placeholder-uri-4.

(with numbers around -placeholder-uri- being different every time)
Non-DASH playback works fine, regardless of whether or not it is being proxied.

Steps to Reproduce

1. Install Crystal 1.3.0
2. Rebuild Invidious
3. Attempt playing any video with DASH (audio-only playback seems unaffected)

Logs
I've looked through the logs, but was unable to find anything beyond logged HTTP requests. I can append the full logs if you're unable to reproduce the issue.

Screenshots
N/A

Additional context
System: Debian 11/stable/Bullseye, Linux 5.10.0-8, x86_64
Crystal version: 1.3.0
LLVM version: 10.0.0
Invidious version: seems irrelevant, I've tried a few commits between f54e247 and 5a72824, and they've all had the same issue

[unixfox]

We don't support the latest and freshest Crystal version for now, it just came out yesterday.

You should use Crystal 1.2.2 until we support Crystal 1.3.0.

[markozajc]

I did get 1.2 (figured out they have separate packages for older versions on OBS now), but I felt like it was a good idea to report this nevertheless before anyone spends a few hours figuring out what the issue is like I did.

[SamantazFox]

Yes, thanks for reporting this :)

[solisinvictum]

For those Guys who run in the same trouble...

i had it today too. And had a big headache because the normal "downgrade path" on a normal debian didnt worked. Until i remembered that i had to add the crystal repo manualy long long ago...

And on this repo, they handle the versioning totaly different as debian do...

Long story short, who had to downgrade crystal:

apt install crystal1.2

is the way to go.

(dont forgett to rebuild invidious again)

[SamantazFox]

So, I started to investigate the thing, and it looks like the second chunk of the video is fetched again and again and again.

I tried to look at the differences in headers/data between invidious on v1.2 and v1.3, and the only thing I found so far is that extra initcwndbps parameter in the youtube parameters (left side of the picture, running on crystal 1.3.2). Maybe a new header in the Stdlib is causing some sort of blocking on youtube side?

I'm also reviewing the Crystal changelog to see if anything could have broken the HTTP/QUIC clients.

[SamantazFox]

Update: nevermind the parameter, seems to be depending on the video server.

However, it seems that invidious has hiccups when sending the data (empty response), and even if the data is sent correctly after, videoJS ignores it? (top = v1.2.2, bottom = v1.3.2)

[SamantazFox]

Update on that subject:
after many painful all nighters, I managed to get something almost working, with a few exceptions.

It turns out that the packets sent by invidious are truncated, and this is causing all sorts of weird issues on the client side. Here's what the devtools show on a Safari client:

Here is the output given by curl:

Length: 1048576 (1,0M) [video/mp4]
Saving to: ‘latest_version?id=9t6jImyvnQk&itag=22&local=true.1’

latest_version?id=9t6jImyvnQk&i  99%[=========================> ]   1022K  1,73MB/s    in 0,6s    

2022-02-18 19:31:28 (1,73 MB/s) - Connection closed at byte 1046076. Retrying.

And here is what analyzing the whole exchange with Wireshark shows (left is with crystal 1.2.2, right is with crystal 1.3.2). Note the double FIN, ACK tcp packet and the lack of content detection/packet summary from wireshark on the right (which should correspond to the green "MP4" line from the left):