Subtitles: [filter avfilter.subtitles] Unexpected return format

Help
21

I’m sorry that you appear to be very upset that in the first hit for your web search about a problem of your own making, that the people volunteering their time to answer the question that was asked by the people who were here, didn’t immediately give you something you could cut and paste to solve it.

But redirecting people who just wanted a working kdenlive (and who had follow up questions like “how do I use the AppImage?”) to a technical bug report, in the hope that they might cherry pick the one line in it that might be salient to them:

This error does not occur in the appimage version

Would not in any way help them more than we did, more than a week ago, before you then hijacked this thread - not asking for help with your own problem, but complaining that we hadn’t preempted your arrival here with technical answers that the original posters would have no interest in or use for.

None of those people were going to patch this themselves and rebuild it from source with untested dependencies. They wanted an answer that worked for them today, out of the box, already well tested, and so we gave them one.

And the last time I included actual technical details as part of triaging a problem for a non-technical user, I instead got the opposite abuse about “flooding me with technical stuff, and all that mumbo jumbo man.”. Evidently, some people you just can’t please.

that’s why the job of an integrator, like a distro maintainer, is important

I’ve never said that job wasn’t important. Quite the opposite in fact. What makes me very very sad is the number of people doing it various degrees of very badly. Whether that’s because they think they are up to the job when they really are not, or just because like all of us they have far too many things on their plate and don’t give it the attention and testing and understanding it needs to do that job well, doesn’t really matter. The end result is the same, lots of broken distro packages, for lots of avoidable reasons, with none of the people responsible for that here to listen to and answer their users, or even engaging with us for advice about building packages that might be less broken less often.

There are a tiny number of exceptions to that, and those people know that I know who they are. But sadly, they really are the exceptions.

don’t judge a book by its cover

We can only see the illustrations on the pages you’re opening. I’m not here to do book reviews, but I do think you might be projecting a bit if you’re worried about judgemental opinions obscuring simple facts … If you don’t think we’re seeing the right picture it’s up to you to turn the page.

Because really, if you don’t see all the alarm bells that this ought to be ringing:

a bug in MLT with ffmpeg 8, with a patch that unfortunately hasn’t made yet to a stable MLT release (and yes, I did try to backport the patch, unsuccessfully so far)

Then you should probably be telling your users to use the AppImage too.

And if you don’t understand why - all I can say is that doubling down your attacks on the people who do probably isn’t the best way to fix that either. That’s all.

22

I disagree. Using ffmpeg 8 is a problem of my own making? Did the KDEnlive team say “don’t use our software with ffmpeg 8”? This wouldn’t reach the end users (they’re not supposed to know that) , but integrators, yes, and they can do something about it (like keeping an older version around).

I wonder if anyone would have ever noticed the bug if no one had used it.

“Badly” is subjective. Just like software has bugs, the manpower is limited to fix them, the same can be said by integrators (which, as far as I am concerned, try to make the software work with an existing base, which may not be developed by the same people doing the integration). KDE creates so much software it’s basically impossible to make sure everything works perfectly 100% of the time. And packaging can have bugs (oh, if I know…) but in this case at least the more apt users can be directed at the distributions to let them know (I didn’t even know this existed).

Such as?

I noticed in many projects (luckily not the bigger ones like Frameworks) a downstream-hostile attitude which is not always justified (but if something is broken, knowing it is may be useful, and this does not mean necessarily you, but any of the upstreams… the distribution ML exists for this reason.).

Note, this is not new and upstream-downstream relationships have always had ups and downs (I talked in a lightning talk about this at an Akademy many years ago), but I think in the end the “downs” are not beneficial. Not to the makers, not to the integrators, not to the users.

Nope, I’ll try to fix the interaction for my users.

23

If we need to tell you “untested things are untested and therefore almost certainly broken”, and you use them anyway, without proper testing, or communication with us, or the skills to fix the broken things that testing finds, or even knowing they are untested … then yes, you’ve objectively and empirically earned your Badly badge.

I noticed in many projects … a downstream-hostile attitude

You should probably meditate on that - because you came out of this gate swinging at me, with an air of superiority and affront and clearly no idea of context or of who you were talking to or care that you were hijacking a user thread - while I can hand on heart say that in all my time doing this, since before there even was a KDE, I have never had or been an upstream that didn’t warmly welcome contributions to improve their project. I’m not saying that no such people exist, or that no disagreements on direction occur - but if you think they are not a minuscule exception, or that this is what’s happening here, you might need to look a bit harder at the common element in all your problem interactions.

Don’t mistake frustration, and sympathy with frustrated users who we end up having to support for problems that we didn’t create, for some sort of blanket ‘hostility’. We can’t force you to be a good downstream, or to talk to us, nicely or at all, or to have even the most basic familiarity with the code we are shipping before you repackage it. All we can do is support the good downstreams who do contribute (in both directions) to the best possible end-user experience - and tell the other more unfortunate users that “Yeah, we’re really sorry about that too, but we can’t fix it except by providing you an AppImage”.

When your unhappy users are still coming to us first, with problems that only exist in your package and not the AppImage, despite the numerous times we’ve repeated that you need to talk to your distro maintainer to fix distro package bugs (and should be getting them to triage them in the first place) - that’s probably your first empirical and objective oak-leaf on your Badly badge.

It’s also not your last - but I’m only still responding to this with the fading hope that you might try harder to learn to do better, not to excoriate you for everything you got wrong on the first attempt. Mistakes are how we learn things, and ignorance is the base we all start from. It’s where you go from there that really matters.