Grip Activity
Brought to you by:
solbu
Activity for Grip
-
Sean Bruno posted a comment on discussion grip-users
I spent a bit of time this weekend trying to understand why GRIP was having issues ejecting on my Ubuntu 22.04 install. I had zero issues with the eject(1) command, so I started comparing GRIP's CDEject() function as compared to how eject's EjectCdrom() works. They are similar enough that I was confused as to how eject(1) would work and GRIP would fail. Turns out eject(1) fails just as often as GRIP, its just that eject(1) has a fallback to EjectScsi() that is able to handle the error cases. I wonder...
-
I spent a bit of time this weekend trying to understand why GRIP was having issues ejecting on my Ubuntu 22.04 install. I had zero issues with the eject(1) command, so I started comparing GRIP's CDEject() function as compared to how eject's EjectCdrom() works. They are similar enough that I was confused as to how eject(1) would work and GRIP would fail. Turns out eject(1) fails just as often as GRIP, its just that eject(1) has a fallback to EjectScsi() that is able to handle the error cases. I wonder...
-
Daniel Savi created merge request #3 on Code
adding user e-mail address to gnudb requests
-
MB McFarland posted a comment on discussion Open Discussion
No problems on OpenSuSE, using either Leap current version or Tumbleweed, both using KDE as the windowmanager.
-
Johnny A. Solbu committed [e90c75] on Code
Update Furlan translation from TP
-
Grip released /4.2.4/grip-4.2.4.tar.gz
-
Johnny A. Solbu committed [aca09a]
Update ChangeLog
-
Johnny A. Solbu committed [14a60b]
Version 4.2.4
-
Johnny A. Solbu committed [1d7bd0]
Update hungarian translation from TP
-
Scott A. Conway posted a comment on discussion Open Discussion
I wanted to say first that I can still use the excellent Grip program, but the strange issue that I'm having is that I can only start it within a terminal, totally unable to launch it with the program launch function built into my window manager, Windowmaker. Is anyone else experiencing this?
-
Johnny A. Solbu committed [875327]
Add new romanian translation from TP
-
Phil Stracchino posted a comment on ticket #404
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.
-
Solbu posted a comment on ticket #404
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.
-
Jonas Stein created ticket #417
GUI: Wrong position and size of elements
-
On 2/10/22 10:09, Solbu wrote: Well, here is a link to screenshots of how it looks on my 1920x1080 screen resolution. https://www.solbu.net/bilder/screenshoots/grip/ https://www.solbu.net/bilder/screenshoots/grip/ These are corresponding screenshots on my 4K display: https://www.caerllewys.net/public/grip-unpatched.png https://www.caerllewys.net/public/grip-patched.png I notice you're running GTK+ 2.24.32 and Wayland. I have 2.24.33 and vanilla xorg-server-21.1.3 without Wayland. This doesn't strike...
-
On 2/10/22 10:09, Solbu wrote: Well, here is a link to screenshots of how it looks on my 1920x1080 screen resolution. https://www.solbu.net/bilder/screenshoots/grip/ https://www.solbu.net/bilder/screenshoots/grip/ These are corresponding screenshots on my 4K display: https://www.caerllewys.net/public/grip-unpatched.png https://www.caerllewys.net/public/grip-patched.png I notice you're running GTK+ 2.24.32 and Wayland. I have 2.24.33 and vanilla xorg-server-21.1.3 without Wayland. This doesn't strike...
-
On 2/10/22 10:09, Solbu wrote: Well, here is a link to screenshots of how it looks on my 1920x1080 screen resolution. https://www.solbu.net/bilder/screenshoots/grip/ https://www.solbu.net/bilder/screenshoots/grip/ These are corresponding screenshots on my 4K display: https://www.caerllewys.net/public/grip-unpatched.png https://www.caerllewys.net/public/grip-patched.png I notice you're running GTK+ 2.24.32 and Wayland. I have 2.24.33 and vanilla xorg-server-21.1.3 without Wayland. This doesn't strike...
-
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.
-
On 2/10/22 06:07, Solbu wrote: Good catch! But does the increased width need to be that much? Would 30 or 35 be enouch? I tried 50 first and it wasn't quite there. 75 seems just about right ... on a 4K display. 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. Could it be dependent upon the versions of some...
-
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.
-
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; }
-
Dirk Meyer created ticket #416
tracks missing when reading and encoding an audio disc
-
-
Johnny A. Solbu committed [493990]
Fix fgetc() return value bug
-
Johnny A. Solbu committed [4b2e69]
Update Changelog
-
Johnny A. Solbu committed [f088ac]
Update meson version, too (I keep forgetting this one)
-
Johnny A. Solbu committed [f277c3]
Version 4.2.3
-
Ticket moved from /p/grip/bugs/397/
-
Store fgetc() return value in int for comparison with EOF
-
Wil be fixed in next release
-
For some reason I missed/forgot this bug repport. Thanks for fixing. :-)
-
Johnny A. Solbu committed [d210c7]
Sync updated italian translation from TP
-
Christian Weisgerber created ticket #415
Store fgetc() return value in int for comparison with EOF
-
-
fix crash on startup due to invalid pointer
-
Johnny A. Solbu committed [b36f88]
Update Changelog
-
Johnny A. Solbu committed [6e83eb]
Version 4.2.2
-
djslattery created merge request #2
fix crash on startup due to invalid pointer
-
-
Johnny A. Solbu committed [20203d]
Moving from Freenode to Libera
-
Johnny A. Solbu committed [ffc7a1]
Update copyright year
-
Johnny A. Solbu committed [fc31f9]
Version 4.2.1
-
Johnny A. Solbu committed [8fbabd]
Sync updated italian translation from TP
-
Ahh, yes. I changed that as it is a simple change. Personally I am satisfied with using GnuDB as replacement. Users config files still need to change that manually for it to work thou, as it will not override existing user configs.
-
Andrew Clayton posted a comment on ticket #119
I was simply referring to the fact that the switch to gnudb.org had been made...
-
I am actually not a programmer, so I can't do anything about it. I can do small changes, like changing URLs, fixing typos and tweaking the autotools code. If someone want Musicbrainz support, someone else have to do the job and send me a patch or merge request. Then I will test and merge it if it works.
-
OK, so I see this change has already been made in the code...<< So does this mean that Grip will use the old style discdb to get the traditional lookup done with gnudb, and if that fails it will try to lookup in Musicbrainz using the (new style) Musicbrainz DiscID ? I see a post by Stephan Wurm on May 20, 2020 about Musicbrainz, but nothing else saying that any Musicbrainz compatible code was actually installed. There may be old code in Grip from when Musicbrainz offered a FreeDB style lookup, but...
-
OK, so I see this change has already been made in the code...
-
Yes, using gnudb.gnudb.org as the DB server seems to work.
-
-
Johnny A. Solbu committed [91b8bc]
Freedb is dead: Replace freedb.org with gnudb.org
-
Johnny A. Solbu committed [577d0e]
Version 4.2.0
-
Johnny A. Solbu committed [aa82bd]
Update Changelog
-
There is also gnudb.org, which also use the discdb. So there could also be beneficial to keep the existing support, and add the Musicbrainz support as an addition, maybe even as the default. But then again, I'm not the one who are doing the job. :-)
-
Sorry for the long delay. This sounds interesting. :-) Feel free to send a patch, and I will test it. Quriously, the freedb is not shutdown yet. It was supposed to shutdown almost 2 months ago.
-
Stephan Wurm posted a comment on ticket #119
Hello, I am currently playing around with replacement of FREEDB by MB5. I followed the development examples from musicbrainz.org and Grip is yet able to get artist, album title, album year, tracks and track artists from the MusicBrainz server. In case of multiple hits for the same DiscID, the alternatives can be selected by the known buttons. But this also breaks some known behavior: 1. The well known discdb is not compatible any longer 2. The data has always to be fetched from the MusicBrainz server...
-
Johnny A. Solbu committed [75a78f]
Sync updated french translation from TP
-
Johnny A. Solbu committed [02af20]
Sync updated serbian translation from TP
-
mikkl posted a comment on ticket #414
Thanks! Fixed for me, too.
-
Closing as fixed, then. :-)
-
Warning "no write access to write wav file" when ripping
-
Aaron Luptak posted a comment on ticket #414
FYI- I was seeing this same issue, was figureing it was just my machine that I hosed the permissions on... I'm happy to report that 4.1.1 fixed the issue for me! BTW, THANK YOU and everybody else involved for reviving this, particularly taking on the modernization side of it! It's much appreciated!
-
We received a patch not to long ago, where the description sounds familiar to this bug. Today we released a version 4.1.1 that hopefully fixed this issue.
-
-
-
Johnny A. Solbu committed [1ee748]
Doh! Bump meson version to 4.1.1 too, not just autotools
-
Johnny A. Solbu committed [b2d5af]
Sync danish translation from Translation Project
-
Johnny A. Solbu committed [61ed68]
Update Changelog
-
Johnny A. Solbu committed [ba322e]
Version 4.1.1
-
This setting points to a writable directory '/tmp/grip/%A/%d/%n.wav' with correct access permissions. I have also tried different locations (e.g. in my home directory) but it's always the same.
-
Gerhard Schiller posted a comment on ticket #414
I had the same issue. I solved it by removing the "~/Music" directory. Grip recreates it the next time! Dont forget to save anything in that directory you want to keep :-) Might be different directory on your machine. Look in the Config/Rip tab at "Rip file format". It will tell you where grip tries to save the wav-files. Gerhard
-
Warning "no write access to write wav file" when ripping
-
Johnny A. Solbu committed [cd05e8]
Sync german translation from Translation Project
-
Johnny A. Solbu committed [8d4b50]
Sync italian translation from Translation Project
-
Johnny A. Solbu committed [b22535]
Sync korean translation from Translation Project
-
Johnny A. Solbu committed [585d24]
Sync translations from Translation Project
-
Johnny A. Solbu committed [9c91b8]
Patch from Till Bargheer: fix directory creation
-
Johnny A. Solbu committed [909e6d]
Update Changelog
-
Johnny A. Solbu committed [686058]
Sync ukranian translation from Translation Project
-
Johnny A. Solbu committed [932f0e]
Sync norwegian translation from Translation Project
-
And now we have released version 4.1.0, if you want to use/test an official tarball release. :-)
-
-
Johnny A. Solbu committed [5ec077]
CREDITS: fix typo
-
Johnny A. Solbu committed [4b2c7d]
Update CREDITS file
-
Johnny A. Solbu committed [bcdecb]
Update Changelog
-
Mart Raudsepp committed [fe3740]
Update ChangeLog
-
Johnny A. Solbu committed [a4bc2e]
Update pot file
-
We are in the process of modernizing the codebase, where the long term goal is porting to GTK3. If you can you can go to the «Code» tab above and either download a snamshot, or clone the git repo and compile from the git source code. The only step that differs from the regular tarball releases is you need to run «autoreconf -if» as the first step, to generate the configure script. I'm not sure but I think your issue might be one of the things fixed in the not yet released codebase.
-
I am aware of it. Unfortunately I cannot do anything about it myself, as I don't know programming. (Yes, really). Two Gentoo developers have stepted up and have modernized much of the code. I hope they can help with this. MusicBrainz had a freedb compatible gateway running since about 2007, which they shut down last year…
-
I am aware of it. Unfortunately I cannot do anything about it myself, as I don't know programming. (Yes, really). Two Gentoo developers have stepted up and have modernized much of the code. I hope they can help with this. MusicBrainz had a freedb compatible gateway running saicne about 2007, which they shut down last year…
-
Dave_AA_MI_US posted a comment on ticket #410
So I decided to try removing the CD drive (it is an external USB CD/DVD/BD-RW drive). When I unplugged the drive it released all of the grip processes that had been in an uninterruptible state. When I plugged the drive back in, it now works properly and I can no longer replicate the problem. So I am not sure where the problem is. Maybe a driver issue? I will post an update if I have the problem again and can figure out how to replicate it... For the record, the following is from dmesg when the drive...
-
Gerhard Hintermayer modified a comment on ticket #413
unfortunately my gdb knowledge ends @ run & backtrace :-( any ideas ? Starting program: /usr/bin/grip [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". [Detaching after fork from child process 31629] [New Thread 0xb5148b40 (LWP 31630)] [Detaching after fork from child process 31631] [New Thread 0xb47ffb40 (LWP 31632)] [New Thread 0xb3dffb40 (LWP 31633)] [Thread 0xb47ffb40 (LWP 31632) exited] [New Thread 0xb47ffb40 (LWP 31640)] [Thread 0xb47ffb40...
-
unfortunately my gdb knowledge ends @ run & backtrace :-( any ideas ? Starting program: /usr/bin/grip [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/libthread_db.so.1". [Detaching after fork from child process 31629] [New Thread 0xb5148b40 (LWP 31630)] [Detaching after fork from child process 31631] [New Thread 0xb47ffb40 (LWP 31632)] [New Thread 0xb3dffb40 (LWP 31633)] [Thread 0xb47ffb40 (LWP 31632) exited] [New Thread 0xb47ffb40 (LWP 31640)] [Thread 0xb47ffb40...
-
oops, should be stack smashing error, cannot edit subject any more :-( What exactly does NUM_FRAMES in id3.c do - looks like this is the only ID3_v2 related "officially tweakable" parameter ....
-
oops, should be stack smashing error, cannot edit subject any more :-(
-
stack smashng error when enabling id3v2 tags
-
MusicBrainz removed their FreeDB gateway last year, so Grip currently Do Not support MusicBrainz at all. I am no personally able to add this support in any way, as I do not know programming (Yes, really) But a Gentoo developer is doing some modernisation of the code, and I plan to ask hin if he can do it. Short answer is, for MusicBrainz support to be added to grip someone need to send me patches that add the functionality, and I will gladly test and merge them.
-
Ticket moved from /p/grip/bugs/412/
-
Need Musicbrainz Support as FREEDB is going away 3/31/2020
-
24+ songs cause lookup failure
1 >
