I keep getting this error message when downloading the artifacts. Do I need to create an account and login? Or download and builld from source?
Get the artifacts for latest commit in master
branch.
Awesome! Seems to work very well. I installed millipixels_0.20.0-1
and millipixels-dbgsym_0.20.0-1
, which were both in the downloaded artifact.
All of a sudden, the new millipixels doesn’t save pictures to the buffer and just keeps trying until the app is closed or killed. No image is saved. I get the following error message in journalctl:
dec 22 11:33:42 pureos sm.puri.Phosh.desktop[9015]: MPCamera: VIDIOC_DQBUF error 22, Invalid argument
EDIT: A reboot fixed the problem with saving images to buffer, but still getting the above error message.
Is this after an update?
Well yes, but I am running the not yet released version of millipixels_0.20.0-1
. I also did the last system upgrade today (minus gnome-calls).
The unreleased millipixels triggers some bugs. It will be a while before we clear it for release.
Ok, no problem. It mostly works.
I want to bring this topic up again for a discussion about Adam Dawson most recent post here: https://social.sdf.org/@adamd/109611034092328091
It looks like autofocus and video are coming to the Librem 5 soon. I am very excited.
Any guess from the crowd when this will be ready in the PureOS repos? I don’t really want to wait . . .
Your guess is as good as mine.
@dcz could make it obvious what is blocking the release (e.g. by creating a milestone in gitlab and assigning issues that block the release). I assume the issue are in millipixels itself as otherwise the releas could be tagged already, just not uploaded to PureOS until those other components are fixed?
I’d love to, but the blocker is not in Millipixels https://source.puri.sm/Librem5/linux/-/issues/446 and gitlab doesn’t let me add it to a Millipixels milestone.
I don’t want to tag prematurely it in case there are other issues - and if I tag it, then some distro will inevitably pick it up and get hangs since they use the same kernel, so I didn’t feel the need to. If you think a tag is a good idea despite that, I can go along with it too, just let me know.
I’m having the same issue, same error message. Didn’t install anything manually, it just upgraded itself. Dpkg says it is version 0.20.0-1pureos1.
Don’t need to reboot, just kill the app and retry over and over until it works, and hopefully the object you wanted to capture (or the smile of the person) is still there when it finally works
What I do in such situations (everything is in place but waiting for another component): prepare the release MR and linking to the blocking bug in the MRs description. That
- allows people to see what will be in the release and provide feedback
- makes it obvious in a place where people are hopefully looking at what is blocking
- should prevent distros from picking it up too early as the reason why the MR isn’t merged is right at the top
The release MR is quickly updated should more changes get merged in the meantime.
The MR is waiting for some other MRs, so I settled on just an issue: https://source.puri.sm/Librem5/millipixels/-/issues/60
@dcz does the MR fix the VIDIOC_DQBUF error 22
issue? Or we don’t know what is causing that? I got it this morning, I could not take a picture at all after many tries…
Thanks!
There is no release MR yet.
This error you’re seeing is the generic error when the kernel is in an odd state. If you want it looked at, please report it here, but first install this Millipixels: https://source.puri.sm/Librem5/millipixels/-/jobs/403892/artifacts/download?file_type=archive
The frontfacing camera has a lot of delay (about a second), I don’t remember it being that slow in previous versions (maybe I misremember though).
Otherwise the latest main with automatic seems to work decently.
But for recording to work I had to manually install dcraw, imagemagick and ffmpeg. After that it worked, but felt a bit unreliable. Before I installed the dependencies, it just silently failed (looked like it succeeded, but there was no file, so I retried when running with the console open and found the errors). After installing the dependencies, once the conversion was done it just crashed right after it finished with a glib assert. But the video is playable in vlc!
Would be nicer if it used mkv instead of mp4 though, mp4 is so hard to work with since the standard is heavily patented so its very expensive to buy the documents for it. Matroska on the other hand has completely open documentation. Its just a shame that mp4 has won the “container” race
(sm.puri.Millipixels:204981): GLib-GObject-CRITICAL **: 21:36:29.178: g_object_ref: assertion 'G_IS_OBJECT (object)' failed
That’s been the case since the very beginning and haven’t been fixed yet. It can be reduced by switching the preview resolution to 640x480 in config file, but it has a downside of being cropped differently than fullres mode.
No, there’s good reason the delay has been further increased. There’s extra processing on each frame now.