Recent changes to bugs

#404 Track list rendering error

2022-02-11T14:38:17.068000Z

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

2022-02-11T05:48:10.142000Z

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

2022-02-10T17:03:10.061000Z

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

2022-02-10T15:09:30.013000Z

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

2022-02-10T11:07:20.272000Z

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

2022-02-09T22:30:14.563000Z

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

2021-11-01T09:45:41.609000Z

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

2021-08-31T13:52:03.393000Z

status: open --> closed-fixed

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

2021-08-31T13:41:49.797000Z

For some reason I missed/forgot this bug repport.

Thanks for fixing. :-)

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

2021-07-29T20:15:52.023000Z

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.