The Handbrake Version 1.6. has a bug. Subtitles sometimes appear on the double. An upgrade to 1.7. would lift the problem ( Handbrake staff )
Thank you for the heads up Holger Upstream is at 1.7.3 BTW I see it is available as flatpak, if any user need it urgently. Assigning to you Chris as i see you packaged it last Feel free to reassign to nobody if you do not take it :) I see they for every release - even point releases say: "Please also make note of any custom presets you have created, as they may not be compatible with newer versions." https://handbrake.fr/news.php Anyway it is better to upgrade within a supported Mageia release, than between Mageia releasees, so user can downgrade easily IF they see this problem. @Holger, please test when there is a new version in testing
Assignee: bugsquad => eatdirtSource RPM: (none) => handbrake-1.6.0-1.mga9.taintedURL: (none) => https://github.com/HandBrake/HandBrakeCC: (none) => fri
Sure, i will test it, when it is up !
Updated to latest handbrake-1.7.3 for Cauldron!
CC: (none) => geiger.david68210
Assigning to QA, Packages in 9/Tainted/Updates_testing: ======================= handbrake-1.7.3-1.mga9.tainted From SRPMS: handbrake-1.7.3-1.mga9.tainted.src.rpm
Assignee: eatdirt => qa-bugs
mga9, x64 Installed the update and used it to convert an mkv file to mp4. Cut a section out of an mp4 file based on frames and played it back. Repeated the operation for another file based on seconds. Audio and video OK. Good as far as I have taken it.
CC: (none) => tarazed25
MGA9-64 Plasma Updated over the old version, with no installation issues. Ran it my usual way, by using the "open with" option on a file (happened to be .mkv) in Dolphin. Checking, I found that the presets I created a year ago were still there, and apparently usable. I customized the settings for quality and resolution somewhat, as well as dropping the subtitle track, in an effort to reduce file size. Both source and result were encoded using the H.264 codec. The resulting .mp4 had reduced the file size from 159.6 MiB to 109.0. Watching each in vlc, the reduction in quality was visible, but only because I was looking for it. (That may be just me. I'm fine with SD quality, as long as it isn't obviously blocky. Others aren't satisfied with anything less than HD, if that. It's a matter of opinion, so YMMV.) Looks good here.
CC: (none) => andrewsfarm
(In reply to Holger Mainz from comment #2) > Sure, i will test it, when it is up ! Should be in the tainted updates testing repo of your favorite mirror very soon, if not already.
MGA9-64 Plasma Wayland on HP-Pavillion No installation issues. Used handbrake to convert a 1.7Gb mpg file to mp4. No problems encountered and resulting mp4 file plays OK.
CC: (none) => herman.viaeneWhiteboard: (none) => MGA9-64-OK
Keywords: (none) => advisory
mga9-64 OK here Plasma X11, intel i7-870, nvidia-newfeature Opened program with file by in Dolphin right clicking an .mp4 Tested compressing of a couple mp4 videos. Started in terminal ("ghb"), no output when starting nor running, which i think is good. $ ghb --help shows help.
OK, thank you. I have it. But i want to test the program with the file, where the subtitles did not fit. Unfortunately, i have to download it again , first ;-( ;-)
installed the testing version (handbrake-1.7.3-1.mga9.tainted) converted a 2 minute .mkv to mp4. video and audio via VLC ok CPU: AMD E1-6010 APU with AMD Radeon R2 Graphics $ uname -a Linux localhost 6.6.17-desktop-4.mga9
CC: (none) => westel
(In reply to Holger Mainz from comment #10) > OK, thank you. I have it. But i want to test the program with the file, > where the subtitles did not fit. Unfortunately, i have to download it again > , first ;-( ;-) What happened with this?, we are just waiting your confirmation
I had deleted the file. From my point of view, i can give it a pass. The duplicated subtitle problem is solved with the update.
Validating.
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2024-0094.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED
And now, we cannot encode x265 anymore... https://bugs.mageia.org/show_bug.cgi?id=33148 I have doubt about the needs of this update, I don't see any bug report open describing the issue needed by the reporter. We don't update packages because there is a bug, there is always a bug!! We update packages when there is a SERIOUS BUG preventing OUR users to use the package. This was not the case, and now it is. Congrats!
CC: (none) => eatdirt
This also brightly shows why it is better to update in a supported release: users can downgrade just the application. Compare that if the jump had been for Mageia 10 instead, where there is nothing to downgrade to. But maybe it would have been better to put it as backport so only users affected by old bugs, could try the new bugs instead. No scheme is perfect.
I agree, it would have been eligible for a backport. For mga10, that is ok to break thing, this is cauldron!!!
There are in a fresh release of Mageia (i.e coming 10) many packages that are at a new major release, and QA have for many no chance to try evaluating them much more than that they launch and open some file. Introducing new major release in a supported release with means that users will test them in real usage. - With elder version to back down to if problem. - Like you did :) Then these new versions are reliable in a new Mageia release. (Then you happen to also be a packager and I see you are working with upstream on this, thanks! :) ) I do not mean we should always do this, but sometime sit is good. There was also a discussion and preparations going on making more releases to backport, with some mail list for it, it is probably only some steam missing... Life. :)
(In reply to Chris Denice from comment #16) > And now, we cannot encode x265 anymore... > > https://bugs.mageia.org/show_bug.cgi?id=33148 > > > I have doubt about the needs of this update, I don't see any bug report open > describing the issue needed by the reporter. > > We don't update packages because there is a bug, there is always a bug!! > > We update packages when there is a SERIOUS BUG preventing OUR users to use > the package. This was not the case, and now it is. Congrats! Welcome to the FLOSS world, a place when things like this could happen, perhaps less often than when Adam Williamson try to write a joke about it https://www.happyassassin.net/posts/2008/08/20/lightbulbs/ In dev lists you cite our update policy like if just fix vulnerabilities or critical use case issues was a shield against this kind of stuff, sorry but not, and we have some examples like bug#33101 comment#1, bug#32636, and surly I not have to remember you the drama with kernel and dkms-anbox Also in dev list you question the ability of the user to find that new version fix the issue , even when I just not search deep enough to see if exist a report that fits the described in this bug, we can see in https://github.com/HandBrake/HandBrake/releases some fixed bugs related to subtitles after the 1.6.0 version My self when testing Plasma updates find a bug in smplayer bug#32893 that I could verify a new version not have If some of us use a specific feature of a software the minimum we could do when see a new testing package is test that feature, we can't assume that QA team will do a test of each feature in each package Updates can break compatibility with outdated/no more developed things, like in bug#32465 Things like yt-dlp need to be up to date to keep working (yes this fits our policy)