another useful attempt could be to upload this same video to another Peertube instance (best if managed by someone who’s open to look into this and discuss with us) and compare the results
I’ve been making more tests and looks like this same issue affects different videos on our instance and it seems that duration, size, ratio or audio don’t matter.
affected files seem to all be mp4 files, encoded in h264, yuv420p Pixel format, “High” Profile. they also all seem to have bitrate > 1-2 mbps.
but other videos on our instance (including this one with a 4 mbps bitrate) are encoded in the same way, and they seem to play fine.
let’s build a list of files affected by this problem.
please check the following videos and confirm whether they’re affected by the same issue, or if they play correctly for you.
Now I have uploaded the video “color 2 sound: Der Hirsch” for a test at diode.zone. On this instance it can be played from the beginning.
This video was recorded with SimpleScreenRecorder as H.264.
Here is the output from ffprobe:
Input #0, mov,mp4,m4a,3gp,3g2,mj2, from ‘color2sound-hirsch-2021-05-24_18.36.18.mp4’:
Metadata:
major_brand : isom
minor_version : 512
compatible_brands: isomiso2avc1mp41
encoder : Lavf58.20.100
Duration: 00:01:31.25, start: 0.000000, bitrate: 5324 kb/s
Stream #0:0(und): Video: h264 (High) (avc1 / 0x31637661), yuv420p(tv, bt709), 1024x1024 [SAR 1:1 DAR 1:1], 5193 kb/s, 25.01 fps, 25 tbr, 12800 tbn, 50 tbc (default)
Metadata:
handler_name : VideoHandler
Stream #0:1(und): Audio: mp3 (mp4a / 0x6134706D), 48000 Hz, stereo, fltp, 128 kb/s (default)
Metadata:
handler_name : SoundHandler
1 Like
thank you both for helping to troubleshoot this. the example videos are playing ok for me but i’m on my phone so it’s likely playing a lower quality rendition for me.
unfortunately things are too hectic for me to help troubleshoot from a computer right now, but i will try to look into this issue when i am able to (likely after i finish moving). one thing i have found helpful is to look at the javascript console in developer tools in the browser, sometimes peertube will spit out helpful information in there.
This is the Debug Console in Firefox 78.10.0esr (64-bit). On a Debian 10 system.
However, the “HLS.js error: mediaError - fatal: false - fragParsingError” is also listed in the console for videos that can be played from the beginning.
This is a speculation:
It is possible that the problem is not directly related to videos.scanlines.xyz. But with the connection of the browser on the local PC with the provider of the cloud storage.
As I understand it, the video stream is not loaded directly from videos.scanlines.xyz (134.122.124.248 / digitalocean?) but from Wasabi.
130.117.252.10 seems to be a server in Amsterdam Netherlands.
traceroute:
7 ipv4.decix-frankfurt.core1.fra1.he.net (80.81.192.172) 25.164 ms 24.305 ms 24.482 ms
8 100ge6-1.core1.ams1.he.net (72.52.92.5) 32.149 ms 33.312 ms 33.443 ms
9 wasabi-technologies-inc.port-channel3.switch1.ams4.he.net (184.104.204.190) 32.605 ms 33.121 ms 100ge5-2.core1.ams1.he.net (184.104.194.209) 35.917 msrevers whois:
network:IP-Network:130.117.252.0/24
network:Org-Name:Wasabi Technologies, IncDomain names on IP address 130.117.252.10
IP Owner: PSINet, Inc
IP Location: Netherlands Amsterdam, North Holland, Netherlands
When I record the connection to 130.117.252.10 while the video should start (but did nor start), I see some strange TCP packets.
First: “Alert Message: Encrypted Alert” sent by the browser 192.168.2.4.
Then the browser tries to disconnect from 130.117.252.10.
1 Like
that’s right, the storage is wasabi, we don’t have nearly enough storage on the digitalocean droplet to host all the video content.
it does seem like there might be issues with the “handshake” between wasabi, the peertube client, and the user. the hls stream / peer to peer functionality seems to be pretty complex and tricky to debug -_-
2 Likes
i found this issue that looks like it might be related.
@cyberboy666 are you able to check the ffmpeg version we have installed? i can’t find any indication through the UI.
3 Likes
i just ssh’d into the droplet and checked with ffmpeg -v :
ffmpeg version 3.4.8-0ubuntu0.2
so yeap this might be the problem - i can try updating the ffmpeg version now.
another thing we could do just to narrow down the problem is disable the wasabi static object storage for a moment and test uploading some videos directly to disk. and then see if the problem is still there ? if not then atleast we know the problem is in the static object storage somewhere
ok updated we are on ffmpeg version 4.3.2-0york0~18.04 now
3 Likes
A)
Just uploaded a new video. This one can now be played from the beginning. Thank you very much.
B)
Login still works for me. By clicking on “Login with Discord”. And ignore the actual password entry.
2 Likes
The video monitor-camera-feedback-loop-1608578433 was also one of the videos that could not be played from the beginning.
Tried this today:
-
Deleted the video from videos.scanlines.xyz.
-
Then re-uploaded the same mp4 file that was still on my hard drive.
This time used the title: monitor camera feedback loop
And now this video can be played correctly.
2 Likes
This was a great, successful example of collaborative debugging!! 
I’m adding “FIXED” to the title of this topic.
Please create a new topic if you have different issues with videos.scanlines.xyz.
2 Likes
(replying here while we figure out what this is about)
Today I found out the first video below wasn’t playing. I guess this means it never played in the first place? I thought I had verified it was working when I first uploaded it. Anyway I just imported it again and that’s the second video. This is an import from the Internet Archive, and specifically from an h264 file generated by them. The two videos have the same specs except for the “Format/Encoder” version which turns out to be Lavf57.83.100 for the older/failing import, and Lavf58.45.100 for the second one.
for the second video, as I’m writing there’s still a “it’s being transcoded, it may not work properly” message but it’s playing correctly for me (reminder this is NSFW, sometimes in surprising ways)
1 Like
Sorry to revive an old topic; I think I’ve narrowed down a source of PeerTube buffering issues.
I’ve always experienced stuttering playback on scanlines, where videos would buffer then stop, buffer then stop, etc. I’d always assumed this was due to VPS bandwidth, but I now think this is actually a WebTorrent vs HLS playback issue.
Peertube version on videos.scanlines.xyz is 3.0.1. Here’s one of my videos there:
Peertube version on diode.zone is 4.0.0. Here’s the same video hosted there:
I get the stuttering playback from scanlines but smooth playback from diode.zone.
PeerTube made HLS playback the default in version 3.2.0. They go into detail about the relative benefits of HLS for playback, bandwidth and storage in their docs.
I think that upgrading the latest Peertube and enabling HLS will make videos play a lot smoother.
4 Likes
thanks for the insight @rnkn ! i can have a go at updating the peertube version and we can see if the results are as expected
(i remember upgrading to version 3.x to be a bit of a hassle so hopfully this major update will go smoother 
)
i started trying to update peertube to v4 but as expected quite a few problems (something went wrong updating node causing a kernel panic and required recovery booting to sort out 
) thats fixed now but theres many other things breaking, but iv done enough for the day will try sort it out tomorrow or atleast b4 the weekend
2 Likes
looks like videos.scanlines.xyz is bak up (few minor fixes needed for the custom sso login stuff but) test it out see how its going !
An user reported being unable to login to videos.scanlines.xyz - apparently I’m having the same issue right now, I’ll double check later.