#242 Encoding fails in interesting way

[Michael Shigorin]

3.1.[689] would exhibit the following on my system:

pristine tarball build would rip tracks successfully,
but encoding (~/.grip, ~/mp3 wiped out) would loop
endlessly with this:

per-track indicator is "rip: idle; enc: trk1" with
progress bar at zero and X numbers running down from
some several hundreds, while overall indicators are
"rip: idle, enc: 100.00%".

What's *interesting* to me is that if I ask grip not to
delete wav and _restart_ grip and do "rip+enc" again on
the same disk/track, encoding goes on perfectly.

Tested with lame and oggenc (just in case), all the same.

strace -ff shows that there are looped syscall
sequences with
stat64() on encoded file returning 0, and indeed the
encoded file just isn't there.

Also: aborting rip+enc _without_ restarting grip
doesn't help, loops the same.

It seems to me that I've seen something like this
already in either Changelog or Bugs/Patches but can't
find it now; can only tell that the package that is
currently in our unstable
(ftp://ftp.altlinux.ru/pub/distributions/ALTLinux/Sisyphus/SRPMS.classic/grip-3.1.3-alt1.src.rpm)
with several patches works OK -- but 3.1.6 with the
same patch set broke, and "plain tarball" builds show
no difference regarding this problem.

I'm afraid that unless it's fixed I have to stick with
keeping 3.1.3 in unstable :(

What additional information should I provide?

--- software
Linux 2.4.25-ow, glibc-2.2.6, gcc-3.3.3, gtk+ 2.2.4,
lame-3.93.1, vorbis-tools-1.0update.1

--- system
AXP2500+/nForce2-based (shouldn't be relevant)

[Nobody/Anonymous]

Logged In: NO

I have the same problem. I suspect that it could be a Glib /
GTK bug, the symptoms occured after switching to a newer gtk
version. However, I did not verify this.

Glib: 2.4.5
GTK: 2.4.4

Simon Kalteis
spam@kernelspace.de

[Michael Shigorin]

OK, we're still fine with 3.1.3 (as 3.2 has changed charset handling in a way that's formally adhering to the spec but practically ruining what's out in the wild, that was cp1251 instead of iso8859-1 as the 8-bit tags encoding... oh well, it's basically the same age as S2462 problem in bug 163).
Kudos to Mike Oliphant!

[Solbu]

You should try the new version. There is a new developer, and latest release is 3.5.1 :-)