PeerTube: failed migration, broken Whisper (Python 3.14) and private video playback

[ikalou]

Hi,

I ran into three issues when trying to upload a video to my peertube channel (I hadn't uploaded a video for over 6 months so I'm not sure when the issue really started).
I used Claude to try to find out what was going on, but I can provide more details upon request.

Running PeerTube 8.3.2 on Cloudron 10.1.6.

1. HLS transcoding failed: column left over from an old migration
   All new-resolution-to-hls jobs failed with:

null value in column "p2pMediaLoaderInfohashes" of relation "videoStreamingPlaylist"
violates not-null constraint

The current code no longer writes this column, but it still exists with a NOT NULL constraint. I did the following change (trusting Claude) and it fixed the transcoding issue:

sql
ALTER TABLE "videoStreamingPlaylist" ALTER COLUMN "p2pMediaLoaderInfohashes" DROP NOT NULL;

2. Automatic transcription (Whisper) broken
   whisper-ctranslate2 in /app/data/storage/bin/pip was built for Python 3.12, but the image now ships Python 3.14:

ImportError: ... _multiarray_umath.cpython-312-x86_64-linux-gnu.so incompatible with cpython-314

pip isn’t available in the image (/usr/bin/python3: No module named pip), so I can’t reinstall it myself.

3. Private videos don’t play
   HLS segments of private videos (/static/streaming-playlists/hls/private/...) are aborted in a loop by the player (NS_BINDING_ABORTED in Firefox), and far more data is transferred than the requested byte ranges. The same video set to Unlisted plays fine. It looks like Range requests aren’t handled correctly on private files.

Thanks!

[ikalou]

I precise also I use Bunny as a CDN.

[whitescreendev]

@ikalou, the Bunny CDN detail might be particularly useful for narrowing down the private video playback problem.

PeerTube handles private video files differently from public ones. Access to private files goes through PeerTube's authentication checks, so a CDN or reverse proxy in front of those requests can complicate things.

I'd try isolating that part before changing the Range handling.

In Firefox's Network tab, compare a working Unlisted video with the same video set to Private. For the failing HLS requests, check the actual response status, the Range request header (if present), and the Content-Range, Content-Length and Cache-Control response headers.

A 206 Partial Content response should describe the requested byte range. But NS_BINDING_ABORTED alone doesn't establish a Range bug — Firefox can also cancel requests when the player retries or changes its playback strategy.

The most useful test might be to temporarily bypass Bunny for an authenticated private-video request, without making the video publicly accessible. If playback works through the Cloudron origin but fails through Bunny, that would narrow the issue down considerably.

Bunny supports Range requests, but its cache and origin-fetch behaviour may differ depending on Cache Slicing settings. I'd also make sure protected HLS paths aren't being cached and served across different users without proper authorization.

The other two problems seem worth tracking separately. In particular, I'd avoid treating the manual PostgreSQL DROP NOT NULL change as a permanent migration fix without checking the schema history and taking a backup.

Could you confirm whether Bunny is proxying the PeerTube application domain itself, or only the video storage/CDN URLs?

[archos]

Hi,

Adding to the note above about the DROP NOT NULL change — might not be it, but we ran into a similar error on two Cloudron instances. 8.3 requires a manual migration script that has to be run after the upgrade; it's in the IMPORTANT NOTES of the v8.3.0 release. DROP NOT NULL only silences the error, the script also moves the infohashes into the new table and fills videoSearch.

Take a backup first, it does DROP COLUMN. With PeerTube running, in the container:

cd /app/code/server
gosu cloudron:cloudron env HOME=/home/cloudron NODE_ENV=production node dist/scripts/migrations/peertube-8.3.js

Expected output:

Filling videoSearch table with existing videos...
videoSearch table filled.

Migrating video infohashes...
Video infohashes migrated.

Check, should return 0 rows:

SELECT column_name FROM information_schema.columns
WHERE table_name IN ('videoStreamingPlaylist','videoFile')
  AND column_name IN ('p2pMediaLoaderInfohashes','infoHash');

Then restart the app and re-encode the affected videos. But you may have done this already.