Page MenuHomePhabricator

Transcode in "Unknown status" and "reset" or purge does not help
Open, Needs TriagePublicBUG REPORT

Assigned To
Authored By
Rillke
Nov 17 2023, 5:47 PM
Referenced Files
F41515114: Screenshot 2023-11-18 at 23.14.16.png
Nov 18 2023, 10:21 PM
F41515112: Screenshot 2023-11-18 at 23.14.06.png
Nov 18 2023, 10:21 PM
F41515110: Screenshot 2023-11-18 at 23.13.55.png
Nov 18 2023, 10:21 PM
F41515107: Screenshot 2023-11-18 at 23.13.55.png
Nov 18 2023, 10:21 PM
F41515105: Screenshot 2023-11-18 at 23.13.48.png
Nov 18 2023, 10:21 PM
F41515103: Screenshot 2023-11-18 at 23.11.36.png
Nov 18 2023, 10:21 PM
F41515101: Screenshot 2023-11-18 at 23.11.28.png
Nov 18 2023, 10:21 PM
F41515099: Screenshot 2023-11-18 at 23.11.17.png
Nov 18 2023, 10:21 PM

Description

Steps to replicate the issue (include links if applicable):

What happens?:

Neither "Reset transcode" nor "Update transcode status" will update the transcode status.

What should have happened instead?:

The column Status shows something like "encoding" and the column "Encode time" shows the time elapsed for encoding.

Software version (skip for WMF-hosted wikis like Wikipedia):

1.42.0-wmf.5 (37d7c67), TMH 0.6.0 (d70542a)

Other information (browser name/version, screenshots, etc.):

Screenshot 2023-11-17 at 18.47.11.png (1×1 px, 294 KB)

  1. Original file. Transcodes ok.

Screenshot 2023-11-18 at 22.23.19.png (2×3 px, 1 MB)

  1. Uploading a new version. Waiting for assembling.

Screenshot 2023-11-18 at 23.09.32.png (2×3 px, 1 MB)

  1. Still waiting from assembling.

Screenshot 2023-11-18 at 23.10.37.png (2×3 px, 1 MB)

  1. Assembling complete. Publish.

Screenshot 2023-11-18 at 23.11.17.png (2×3 px, 1 MB)

  1. Queued.

Screenshot 2023-11-18 at 23.11.28.png (2×3 px, 1 MB)

  1. Waiting for publish

Screenshot 2023-11-18 at 23.11.36.png (2×3 px, 1 MB)

  1. Published

Screenshot 2023-11-18 at 23.13.48.png (2×3 px, 2 MB)

  1. No transcoding required

Screenshot 2023-11-18 at 23.13.55.png (2×3 px, 1 MB)

  1. Clicking on "Update transcode status"

Screenshot 2023-11-18 at 23.13.55.png (2×3 px, 1 MB)

  1. Confirm purge cache

Screenshot 2023-11-18 at 23.14.06.png (2×3 px, 1 MB)

  1. Get the unknown status and no transcodes

Screenshot 2023-11-18 at 23.14.16.png (2×3 px, 1 MB)

Event Timeline

An assessment if the issue can be fixed or a workaround like if a re-upload would help, would both be appreciated. Thanks!

Ughh, I managed to break another one by re-uploading / uploading a new version.

Spent an hour digging through the logs but couldn't find anything. It seems the transcode jobs are never queued, which is uncommon.
Reverting fixes it. What software did you use to modify the file ?

New version:

ffprobe 20231118184211\!WikiCon_2023_-_20_Jahre_kleine_Wikipedia-Sprachversionen.webm
Input #0, matroska,webm, from '/Users/hartman/Downloads/20231118184211!WikiCon_2023_-_20_Jahre_kleine_Wikipedia-Sprachversionen.webm':
  Metadata:
    MINOR_VERSION   : 512
    COMPATIBLE_BRANDS: isomiso2avc1mp41
    MAJOR_BRAND     : isom
    ENCODER         : Lavf60.3.100
  Duration: 00:42:38.25, start: -0.003000, bitrate: 259 kb/s
  Stream #0:0: Video: vp9 (Profile 0), yuv420p(tv, progressive), 1280x720, SAR 1:1 DAR 16:9, 24 fps, 24 tbr, 1k tbn (default)
    Metadata:
      HANDLER_NAME    : VideoHandler
      VENDOR_ID       : [0][0][0][0]
      ENCODER         : Lavc58.134.100 libvpx-vp9
      DURATION        : 00:42:38.249000000
  Stream #0:1: Audio: opus, 48000 Hz, stereo, fltp (default)
    Metadata:
      HANDLER_NAME    : SoundHandler
      VENDOR_ID       : [0][0][0][0]
      ENCODER         : Lavc58.134.100 libopus
      DURATION        : 00:42:38.244000000


Old version:
20231118130258\!WikiCon_2023_-_20_Jahre_kleine_Wikipedia-Sprachversionen.webm
Input #0, matroska,webm, from '/Users/hartman/Downloads/20231118130258!WikiCon_2023_-_20_Jahre_kleine_Wikipedia-Sprachversionen.webm':
  Metadata:
    COMPATIBLE_BRANDS: isomiso2avc1mp41
    MAJOR_BRAND     : isom
    MINOR_VERSION   : 512
    ENCODER         : Lavf58.76.100
  Duration: 00:43:53.93, start: -0.007000, bitrate: 257 kb/s
  Stream #0:0: Video: vp9 (Profile 0), yuv420p(tv, progressive), 1280x720, SAR 1:1 DAR 16:9, 24 fps, 24 tbr, 1k tbn (default)
    Metadata:
      HANDLER_NAME    : VideoHandler
      VENDOR_ID       : [0][0][0][0]
      ENCODER         : Lavc58.134.100 libvpx-vp9
      DURATION        : 00:43:53.757000000
  Stream #0:1: Audio: opus, 48000 Hz, stereo, fltp (default)
    Metadata:
      HANDLER_NAME    : SoundHandler
      VENDOR_ID       : [0][0][0][0]
      ENCODER         : Lavc58.134.100 libopus
      DURATION        : 00:43:53.928000000

Spent an hour digging through the logs but couldn't find anything. It seems the transcode jobs are never queued, which is uncommon.
Reverting fixes it. What software did you use to modify the file ?

Basically this:

ffmpeg -ss ... -i in.webm -c copy -t ... out.webm
zsh 9527 [1] % ffmpeg --help
ffmpeg version 6.0 Copyright (c) 2000-2023 the FFmpeg developers
  built with Apple clang version 14.0.3 (clang-1403.0.22.14.1)
  configuration: --prefix=/opt/homebrew/Cellar/ffmpeg/6.0_1 --enable-shared --enable-pthreads --enable-version3 --cc=clang --host-cflags= --host-ldflags= --enable-ffplay --enable-gnutls --enable-gpl --enable-libaom --enable-libaribb24 --enable-libbluray --enable-libdav1d --enable-libjxl --enable-libmp3lame --enable-libopus --enable-librav1e --enable-librist --enable-librubberband --enable-libsnappy --enable-libsrt --enable-libsvtav1 --enable-libtesseract --enable-libtheora --enable-libvidstab --enable-libvmaf --enable-libvorbis --enable-libvpx --enable-libwebp --enable-libx264 --enable-libx265 --enable-libxml2 --enable-libxvid --enable-lzma --enable-libfontconfig --enable-libfreetype --enable-frei0r --enable-libass --enable-libopencore-amrnb --enable-libopencore-amrwb --enable-libopenjpeg --enable-libspeex --enable-libsoxr --enable-libzmq --enable-libzimg --disable-libjack --disable-indev=jack --enable-videotoolbox --enable-audiotoolbox --enable-neon
  libavutil      58.  2.100 / 58.  2.100
  libavcodec     60.  3.100 / 60.  3.100
  libavformat    60.  3.100 / 60.  3.100
  libavdevice    60.  1.100 / 60.  1.100
  libavfilter     9.  3.100 /  9.  3.100
  libswscale      7.  1.100 /  7.  1.100
  libswresample   4. 10.100 /  4. 10.100
  libpostproc    57.  1.100 / 57.  1.100
Hyper fast Audio and Video encoder

The original file you reverted back to was created using video2commons, supposedly ffmpeg on Linux.

The other file mentioned was created transcoding with ffmpeg on linux from mp4 to AV1/Opus. Maybe it always happens when overriding video files? I just don't want to spam Commons without me being able to clean up.

k. leaving this for now, maybe brion knows which logs to check, cause i'm baffled.

  1. Tried cleaning the file with mkclean, same issue.
  2. uploaded to my local install, worked just fine
  3. other uploads all seem to be a ok.
  4. one is an av1 file, the other a vp9 file, so not codec specific.

Suspect it's something specific to the way the file was muxed, but no guess as to what that can be.

https://commons.wikimedia.org/wiki/File:WikiCon_2023_-_20_Jahre_kleine_Wikipedia-Sprachversionen_dupe.webm is an exact copy of https://commons.wikimedia.org/wiki/File:WikiCon_2023_-_20_Jahre_kleine_Wikipedia-Sprachversionen.webm - and it just works fine. Maybe I chose the wrong component when filing this issue? Anyway please stop saying that something is wrong with the file :)

It seems like overwriting timed media is the issue here.

Destroyed transcodes of another file by overwriting it. It seems that overwriting a file with chunked upload and then purge page cache is a secure way to reproduce with sufficiently large video files.

brooke subscribed.

I'll add this to my queue. Currently I'm chasing down bulk encodings; chasing down ongoing errors will be next and I expect several synchronization-related problems with cached data chunks. :)

[In general I know we've got some order of operations problems with the transcode table and other db bits, the job queue, and the file storage -- three distinct storage systems which need to be either in sync or in the proper order to handle weird sync issues. I'm going to collect up a few of these related issues today and try to work them out in the next couple days. If we're lucky I'll have something up for code review before the Thanksgiving holiday Thursday! If not I'll keep poking at it later.]