Recent changes to bugs

#404 Track list rendering error

Phil Stracchino — Fri, 11 Feb 2022 14:38:17 -0000

Neither do I. :) I run fvwm2.
I wasn't implying anything about desktop environment. I wouldn't THINK that the environment is going to have any impact on rendering inside the application window, but I've been wrong before.

#404 Track list rendering error

Solbu — Fri, 11 Feb 2022 05:48:10 -0000

I don't have Gnome installed, if that's what you're implying. I run the KDE/Plasma desktop in Mageia 7.
I only have the GTK development packages, and the packages needed for Grip to run. Grip was originally made specifically for Gnome, back in the day.

What would be interesting to know is if your 4K display would render it properly if you ran it in KDE/Plasma.

GUI: Wrong position and size of elements

Jonas Stein — Thu, 10 Feb 2022 17:03:10 -0000

Elements of the GUI have the wrong position and size right after starting grip.
Tested with the Gentoo package:
media-sound/grip-4.2.3 (https://packages.gentoo.org/packages/media-sound/grip)

#404 Track list rendering error

Solbu — Thu, 10 Feb 2022 15:09:30 -0000

Well, here is a link to screenshots of how it looks on my 1920x1080 screen resolution.
https://www.solbu.net/bilder/screenshoots/grip/

As t dependencies, I run Mageia 7 which came out in 2019.
I have attached a list of the dependencies and versions my build VM wanted to install (as a result of «sudo urpmi --buildrequires SPECS/grip.spec») when I was recompiling grip earlier today.

#404 Track list rendering error

Solbu — Thu, 10 Feb 2022 11:07:20 -0000

Good catch!
But does the increased width need to be that much?
Would 30 or 35 be enouch?

Also, on my physical system I don't see this behaviour.
It dynamically adjusts the sizes inside the program window dependent on the translation, and I dont know why it does.
I do remember on older systems I ran it did do just what you describe.

#404 Track list rendering error

Phil Stracchino — Wed, 09 Feb 2022 22:30:14 -0000

I just revisited this again and THIS TIME I found where the interface is set up. And the patch is stupidly simple, it is literally a one-line change to a numeric constant.

--- grip-4.2.3/src/cdplay.c 2020-01-25 05:38:53.000000000 -0500
+++ grip-4.2.3/src/cdplay.c 2022-02-09 16:30:02.711140809 -0500
@@ -268,11 +268,11 @@

     tot_width+=width;

     tot_width/=PANGO_SCALE;

-    tot_width+=25;
+    tot_width+=75;
   }

   return tot_width;
 }

tracks missing when reading and encoding an audio disc

Dirk Meyer — Mon, 01 Nov 2021 09:45:41 -0000

all versions, tested on version 4.2.2
no error or warning is printed when running with grip -v

Settings in .grip:
ripexename /usr/local/bin/cdda2wav
ripcmdline -D %C -x -H -t %t -O wav %w
mp3exename /usr/local/bin/flac
mp3cmdline -V -o %m %w
ripfileformat /media/flac/%A/%y,%d/%t_%n.wav
ripfileformat_multi /media/flac/%A/%y,%d/%t_%a_%n.wav
mp3fileformat /media/flac/%A/%y,%d/%t_%n.%x
mp3fileformat_multi /media/flac/%A/%y,%d/%t_%a_%n.%x
mp3extension flac

Reproduced: reading and encoding an audio disc
track 14 and track 16 missing after the disk is processed.

using public CDDB from gnudb.org
DISCID=f8121b12

Diagnostics:
Watching the directory while the disk is processed,
the following wav-files are created and deleted:

16_Mass_in_B_minor_for_soloists_chorus__orchestra_BWV_232_BC_E1_Osanna_Benedictus_Agnus_Dei_et_Dona_nobis_pacem_Osanna_in_ex
14_Mass_in_B_minor_for_soloists_chorus__orchestra_BWV_232_BC_E1_Osanna_Benedictus_Agnus_Dei_et_Dona_nobis_pacem_Osanna_in_ex

Note the missing exensions.

Suggested fix:
grip should truncate the name with room for the needed extension.

#415 Store fgetc() return value in int for comparison with EOF

Solbu — Tue, 31 Aug 2021 13:52:03 -0000

status: open --> closed-fixed

#415 Store fgetc() return value in int for comparison with EOF

Solbu — Tue, 31 Aug 2021 13:41:49 -0000

For some reason I missed/forgot this bug repport.

Thanks for fixing. :-)

Store fgetc() return value in int for comparison with EOF

Christian Weisgerber — Thu, 29 Jul 2021 20:15:52 -0000

The return value of fgetc() must be stored in an int if it is compared against EOF.

As is, the check for EOF (-1) in RemoveM3U() is buggy:
On architectures that default to signed chars, reading 0xff will be mistaken for EOF.
On architectures that default to unsigned chars (arm, ppc), EOF will never be recognized.

Trivial patch attached.