a long landscape episode, posted to linkedin as itself

the short version

post to linkedin sends the file you already rendered. a long landscape episode stays that file. it is not cropped, not shortened, and not turned into a portrait cut for the sake of the button.

if linkedin refuses the video, the message now says why. the old line, that linkedin could not process the video, told you nothing you could act on.

what was actually going up

a landscape episode of about eight minutes is a normal file for this product. the one that failed was roughly forty megabytes, 1280 by 720, h.264 with aac audio, the same encode as shorter landscape episodes that had already posted from the same button. linkedin's own limits sit far above that: a personal post can run a quarter of an hour, and the file can be much larger than forty megabytes. the picture was not the problem.

the same file also went up on a company page through the browser. that door re-packages what you hand it. the button in underway does not. it sends the rendered file, part by part, and then waits until linkedin says the video is ready. when that wait came back failed, the episode never left the app.

why it still failed

linkedin's video upload is three steps. you tell it how big the file is. it hands back a list of byte ranges. you put each range up, you name each part from the tag it returns, and you ask it to assemble them. only then does it process the picture. a short file is one or a few parts. an eight minute landscape file is about ten. the ranges themselves were already right, which is why the shorter episodes of the same shape had posted.

those shorter episodes posted while two extra files were declared and then refused. a cover, and a caption file built from the words in the cut. linkedin will take both, but only in a shape it documents. the cover has to be marked as a still. the captions have to be a form: a note that says this is an english srt, then the file itself. we were sending the srt as a raw upload, so linkedin did not keep it. the cover was missing the still marker, so linkedin did not keep that either. the processor was left with the video, and the video went up.

the next change sent those two files in the shape the documentation describes, and linkedin accepted both. a three minute landscape file, 1280 by 720, the same class as the episodes that had already posted, then came back as processing failed. the status was processing failed. the reason field was empty. the button said linkedin could not process the video, and it did not say why, which was true of the field and useless to you. the same files go up on a company page through the browser, which does not attach our cover or our caption file through that upload.

so the extra files were the change that broke a path that had worked. a feed post is supposed to survive a caption that does not parse. once the cover upload is actually accepted, the still is processed on linkedin's thumbnail path, and a failure there comes back as a failed video with no reason code. the bytes of the episode were never rewritten. landscape stayed landscape. the failure was the two files riding along, not the frame.

what the button does now

post to linkedin sends the rendered file and nothing else. the cover is not attached. a separate caption file is not attached. linkedin makes the still from the video, which is what it did on the episodes that posted. the captions a viewer reads are the ones already burned into the picture. each part is a copy of exactly the bytes linkedin asked for, from the first byte of the file to the last, and the tag that names the part has its quotes taken off, which is the value linkedin wants when it joins the parts. a download that stopped early is refused here, with a plain sentence, instead of being sent up for linkedin to fail later.

the words of the post are untouched: whatever you left in the linkedin box is what the post says. nothing is added after it, and nothing is written that you did not leave there.

then we wait until linkedin says the video is ready, and only then create the post. if the processor refuses it, the message quotes the reason linkedin gave, including a sentence rather than only a code. a file it could not read, a format it will not take, a file that is too large, a video that is longer than it allows. if it names something we have not mapped, you still see the code. if the reason field is empty, the message names the fields linkedin did send, instead of stopping at a shrug. if it is simply still working, the message says to try the post again in a minute, which is a different case from a refusal.

the same button on the phone

the phone does not have its own upload. post to linkedin on the phone calls the same route as the web, so a long landscape episode from either door is the same file, the same words, and the same sentence if linkedin refuses it.

what this is not

it is not a new network, and it is not a second version of the episode. instagram, tiktok, youtube and x are unchanged. a landscape episode is still posted as the landscape file everywhere that already did that. linkedin does not get a portrait crop, a trailer cut, or a shorter edit made to fit a guess about what the feed wants.

it is also not a change to the words. the linkedin post stays the one in the box. read it, change a line, then press the button. the press saves the box first, as it already did.

if it still will not go

press post to linkedin again on the episode. an episode that failed before has nothing stored on linkedin, so the press starts a new upload rather than editing a post that was never created. if the message names a limit, that limit is linkedin's, and the file in the vault is still the one you rendered. render it again only if the message says the file arrived incomplete.