This bug is sort of related to 46146. The new version of the gnump3d ebuild (either v2.6-r1 or v2.7) doesn't contain a critical step to establishing a properly working gnump3d server. Basically, all versions of gnump3d after 2.2 require the index to be built before the server will work properly. The problem is that the index can't be created until after the conf file is edited by the user since the user must specify the root path to the sound files. The ebuild therefore can't do this automagically, but a statement to the effect of the following should be added to the end of the ebuild comments. After editing /etc/gnump3d.conf run gnump3d-index to set up the database for your sound files. You can view the stats of your database by executing gnump3d-index --stats Reproducible: Always Steps to Reproduce: 1. Install gnump3d ebuild either v2.6-r1 or v2.7 2. Edit /etc/gnump3d.conf appropriately 3. Start gnump3d without executing gnump3d-index. 4. Execute a search through the web interface or try to view the stats. Searches will never match any results and stats will appear to be zero, even if you can browse your collection. Actual Results: The search function will be broken along with various other components. Expected Results: The search function shouldn't be broken. Search and stats rely on this database as well as other features of the program. I was upgrading from a previous version of gnump3d, v2.2. Not sure if this matters but I don't think it does since I could wipe gnump3d from the system and achieve the same end state. uname -a: Linux my.hostname 2.6.3 #1 Mon Feb 23 16:34:45 CST 2004 i686 Intel(R) Pentium (R) 4 CPU 2.00GHz GenuineIntel GNU/Linux gcc -v: Reading specs from /usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/specs Configured with: /hfd/tmp/portage/gcc-3.3.2-r5/work/gcc-3.3.2/configure -- prefix=/usr --bindir=/usr/i686-pc-linux-gnu/gcc-bin/3.3 -- includedir=/usr/lib/gcc-lib/i686-pc-linux-gnu/3.3.2/include -- datadir=/usr/share/gcc-data/i686-pc-linux-gnu/3.3 --mandir=/usr/share/gcc- data/i686-pc-linux-gnu/3.3/man --infodir=/usr/share/gcc-data/i686-pc-linux- gnu/3.3/info --enable-shared --host=i686-pc-linux-gnu --target=i686-pc-linux- gnu --with-system-zlib --enable-languages=c,c++,f77,objc,java --enable- threads=posix --enable-long-long --disable-checking --enable-cstdio=stdio -- enable-clocale=generic --enable-__cxa_atexit --enable-version-specific-runtime- libs --with-gxx-include-dir=/usr/lib/gcc-lib/i686-pc-linux- gnu/3.3.2/include/g++-v3 --with-local-prefix=/usr/local --enable-shared -- enable-nls --without-included-gettext --x-includes=/usr/X11R6/include --x- libraries=/usr/X11R6/lib --enable-interpreter --enable-java-awt=xlib --with-x -- disable-multilib Thread model: posix gcc version 3.3.2 20031218 (Gentoo Linux 3.3.2-r5, propolice-3.3-7) emerge info: Portage 2.0.50-r6 (default-x86-1.4, gcc-3.3.2, glibc-2.3.2-r9, 2.6.3) ================================================================= System uname: 2.6.3 i686 Intel(R) Pentium(R) 4 CPU 2.00GHz Gentoo Base System version 1.4.9 distcc 2.13 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled] Autoconf: sys-devel/autoconf-2.58-r1 Automake: sys-devel/automake-1.8.3 ACCEPT_KEYWORDS="x86" AUTOCLEAN="yes" CFLAGS="-march=pentium3 -O3 -pipe -fstack-protector -fomit-frame-pointer" CHOST="i686-pc-linux-gnu" COMPILER="gcc3" CONFIG_PROTECT="/etc /usr/X11R6/lib/X11/xkb /usr/kde/2/share/config /usr/kde/3/s hare/config /usr/lib/mozilla/defaults/pref /usr/share/config /usr/share/texmf/dv ipdfm/config/ /usr/share/texmf/dvips/config/ /usr/share/texmf/tex/generic/config / /usr/share/texmf/tex/platex/config/ /usr/share/texmf/xdvi/ /var/qmail/control" CONFIG_PROTECT_MASK="/etc/gconf /etc/terminfo /etc/env.d" CXXFLAGS="-march=pentium3 -O3 -pipe -fstack-protector -fomit-frame-pointer" DISTDIR="/usr/portage/distfiles" FEATURES="autoaddcvs ccache distcc sandbox" GENTOO_MIRRORS="ftp://ftp.ussg.iu.edu/pub/linux/gentoo ftp://ftp.gtlib.cc.gatech.edu/pub/gentoo http://csociety- ftp.ecn.purdue.edu/pub/gentoo/ http://adelie.polymtl.ca/ http://gentoo.noved.org/" MAKEOPTS="-j4" PKGDIR="/usr/portage/packages" PORTAGE_TMPDIR="/hfd/tmp" PORTDIR="/usr/portage" PORTDIR_OVERLAY="" SYNC="rsync://rsync6.us.gentoo.org/gentoo-portage" USE="X acpi alsa apache2 apm arts avi berkdb bonobo cdr crypt cups dvd emacs encode esd foomaticdb gdbm gif gnome gpm gtk gtk2 guile imlib java jpeg kde libg++ libwww mad mbox mikmod mmx motif mozilla mpeg mysql ncurses nls oggvorbis opengl oss pam pdflib perl png python qt quicktime readline sdl slang spell sse ssl svga tcltk tcpd tetex tiff truetype usb x86 xml2 xmms xv zlib zsh"
How about adding gnump3d-index to the init.d script? Or does this actually rebuild the entire index rather than just looking for updates?
I've played with it and gnump3d-index will update the index if present, or create it if not present. This is precisely the desired behavior so this should just be added to the ebuild. A comment to the effect of "to add new items to your mp3 collection please restart gnump3d" or creation of an init script option such as "rebuild" that simply runs gnump3d-index would be nice. Of course, users can simply run gnump3d-index but it's nice to have it in the script. The server need not be restarted for index changes to be seen. I've discovered another issue while playing with the init scripts... the new version of gnump3d doesn't create a pidfile so the stop argument always fails and the service must be manually restarted. I tried using the --make-pidfile argument to start-stop-daemon but this doesn't work as the gnump3d process immediately forks so the pid logged is wrong. I don't know enough about the init scripts to fix this one entirely but if need be I can look into it further.
ok, I think you missed my question... what I'm asking is this: If I run gnump3d-index with TONS of mp3s, how long does it take for the first time? How about the second time?
the first time takes ages (i have about 90gb on this machine of legally copied, backed up personal mp3s and it took about 3 minutes to build the index). adding say a directory to this takes about 5 seconds. so the first is substantial, latter are brief.
though, in retrospect i guess 3 minutes is only ages because i'm horribly impatient :)
ok, then I'll just add that to the init file... now to see the pid stuff...
Hmm... the pid file seems right for me... is it working with 2.7 for you (2.6 did it differently and might be broken). (15:05:13 Sat Apr 24 2004 root@eradicator) ~ $ cat /var/run/gnump3d.pid 23827 (15:05:22 Sat Apr 24 2004 root@eradicator) ~ $ ps x | grep gnum 23833 root pts/2 26 0 S 0.0 0.0 15:05:25 00:00:00 grep gnum (15:05:25 Sat Apr 24 2004 root@eradicator) ~ $ ps ax | grep gnum 23827 gnump3d ? 28 0 S 3.0 1.1 15:05:14 00:00:00 /usr/bin/perl -I/usr/lib/gnump3d -w # -*- cperl -*- # /usr/bin/gnump3d2 --quiet 23835 root pts/2 23 0 R 0.0 0.0 15:05:29 00:00:00 grep gnum (15:05:35 Sat Apr 24 2004 root@eradicator) ~ $ qpkg -I -v gnump3d media-sound/gnump3d-2.7 *
ah hah. i'm not that experienced with start-stop-daemon and it seems that i stuck the --make-pidfile argument in the wrong place. i made the pidfile before the --exec, which explains the behavior i saw (pidfile having one lower pid than the running process). the default init script that comes with 2.7 works fine. thanks for the help and such.
ok... an updated ebuild/index/conf file has been added to portage for 2.7. Can you please test it and report back. I was going to be marking 2.7 stable soon, but want to make sure this doesn't break first (it works for me, but just to be safe...)
totally works. gnump3d-index updates the index if new files have been added since the server was last started. install scripts work fine, all systems go.
