Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

MediaInfo: Failure writing output to destination, passed 16256 returned 0 (curl error?) #2032

Open
the-real-tokai opened this issue May 2, 2024 · 3 comments
Labels

Comments

@the-real-tokai
Copy link

Occasionally, for some files (or for some servers?), mediainfo spills out an Error Failure writing output to destination, passed 16256 returned 0 (I believe this may be a curl error). I'm not sure why it wants to "write" anything. It's supposed to be just reading data.

It still prints out the meta data properly afterwards.

E.g. here's a test case with one of my own files from my own webserver:

$ mediainfo 'https://external.binaryriot.org/site-github-com/traffictest.mp4'
E: https://external.binaryriot.org/site-github-com/traffictest.mp4, Failure writing output to destination, passed 16256 returned 0
General
Complete name                            : https://external.binaryriot.org/site-github-com/traffictest.mp4
Format                                   : MPEG-4
Format profile                           : Base Media / Version 2
Codec ID                                 : mp42 (isom/iso2/avc1/mp41)
File size                                : 2.58 MiB
Duration                                 : 32 s 967 ms
Overall bit rate                         : 656 kb/s
Frame rate                               : 30.000 FPS
Encoded date                             : 2016-09-22 09:57:11 UTC
Tagged date                              : 2016-09-22 09:57:11 UTC
Writing application                      : HandBrake 0.10.5 2016021100

Video
ID                                       : 1
Format                                   : AVC
Format/Info                              : Advanced Video Codec
Format profile                           : High@L4.1
…

curl 8.7.1
zlib 1.2.13
mediainfo/mediainfolib 24.04
OS X 10.10.5 (Yosemite)

@JeromeMartinez
Copy link
Member

(I believe this may be a curl error).

Right.

E.g. here's a test case with one of my own files from my own webserver:

We tested with your link and did not succeed to reproduce the issue.
curl 7.64.1 (tested also with 8.7.1)
mediainfo(lib) 24.04
OS X 11.6

And all I find on the big Internet is "curl install issue, reinstall it", so it would be also our initial answer if it is not possible to locate a MediaInfo specific issue here.

@the-real-tokai
Copy link
Author

@JeromeMartinez I don't think it's an issue in curl itself, else curl (the command) should trigger an error too, or any of the many other apps on my system that utilise the very same libcurl. It must be something particular the way MediaInfo requests things from curl that triggers it.

I'm quite sure it's not even the request itself that's broken (after all it does finish the task properly), but simply some secondary error code wrongly interpreted or a wrongly initialised/ cached variable for some reason which may or may not trigger depending on the OS and/or compiler used or something. Some quirk like that, e.g. see here: curl/curl#8568

@JeromeMartinez
Copy link
Member

I don't think it's an issue in curl itself, else curl (the command) should trigger an error too,

But...

It must be something particular the way MediaInfo requests things from curl that triggers it.

MediaInfo uses exactly the same method on our macOS and there is not this error line.
We tested ~10 times on your link.

We tested the homebrew build (I guess you use this one) and our homemade build.
Please try this home made build, this is a build without Homebrew and linking to system libcurl, we have more control on this build than on the Homebrew build. mediainfo --version should display 24.04.20240503.

If you still have the error with this build, we may have to build a debug version logging the CURLOPT_WRITEFUNCTON return value but as it is not reproductible by us and maybe not by a lot of users it will be low priority in free support.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

2 participants