Net-rhythmbox ("-" in unix name, "netRhythmbox" when read by users as per the developer, "NetRB" is an abbreviation some of us use) is an unofficial rhythmbox fork that looks to provide additional functionality and stability while the main rhythmbox codebase undergoes a large rewrite. NetRB supports streaming radio (unlike the base RB tree), and has a few other enhancements. NetRhythmbox may become the standard RB implementation in Debian (at least according to NetRB's primary developer, whom just happens to also work on Debian). The main Rhythmbox people are aware of the NetRB fork, although I do not know what their exact relationship is. Given that I attend the same school as the primary NetRB developer (Colin Walters (irc.freenode.net / walters)), I have talked to him while building this ebuild. According to him, it should build on any platform supported by gnome; he develops it on a PPC. I have tested this ebuild, and verified it works on my x86 system. I have verified the dependancies with the author; he requested the higher GTK version, and says gnome 2.0 or 2.2 should work. NetRB lacks the gentoo warning message, and hence does not need to be patched to soften it. This ebuild is a modification of the media-sound/rhythmbox-0.4.1-r1 ebuild. IMPORTANT NOTE: NetRB utilizes an "id3tag" library. I did not see any gentoo ebuild that provided it outright. However, media-sound/mad seems to utilize this as well, and provides the /usr/include/id3tag.h and similar utilized. NetRhythmbox has no issues when compiled against what media-sound/mad provides, so I have included it as a dependancy. Side note: gstreamer's alsa support is not fully done yet. To prevent a crash once you try and play something, use gconf-editor or similar to set the /system/gstreamer/defaults/audiosink parameter to "osssink" instead of "alsasink" and use the OSS compatibility libraries. This tidbit also comes from Colin, and given the fact I use alsa, it solves a crashing issue I was having with rhythmbox for a while.
Created attachment 8353 [details] media-sound/net-rhythmbox-0.4.5.ebuild The ebuild.
slight correction: there is a media-libs/id3lib. However, I do not have it installed. This means that if "qpkg -f /usr/include/id3tag.h" is correct, media-sound/mad is duplicately providing the library.
Unable to contact web.verbum.org. Will revisit when available again.
Reachable now; fetching and building as we speak.
I'm still unable to reach this host. It just doesn't resolve in my dns. Has the site been down for a while or moved? Any changes may not have propagated this far (Japan.) I'll keep trying and take a look from a U.S. host later.
Seems i can see it from a U.S. based host. Will try again tonight to get this commited.
I am not sure why you are having DNS issues abroad; I will try and check with the author if and when he comes online. If you are on the freenode IRC system, watch for a "walters" to come on - likely at least voiced or opped in several Debian (and possibly Gnome) channels. In any case, please also figure out the id3-lib need. I know Gentoo has a seperate build for media-libs/id3lib; but media-sound/mad also seems to provide it (as described previously).
Just a quick request from the program maintainer (Walters) - when this ebuild goes stable, please copy the source tarball to Gentoo's mirrors. Usually this happens, but I don't want to break another graduate student's budget by mistake. His co-located machine's bandwidth usage already is going up due to the program's popularity. Also according to the maintainer/author: There may be another release sometime late this week (Friday). I will update here if that happens and someone does not beat me to it.
Having install more gnome packages than i ever wanted to see, this is what i get when i try and run: $ net-rhythmbox INFO (16141: 0) Initializing GStreamer Core Library version 0.6.0 INFO (16141: 0) CPU features: (00000000) MMX SSE registry: loaded global_registry in 0.231548 seconds (/var/lib/cache/gstreamer-0.6/registry.xml) (net-rhythmbox:16141): GLib-GObject-WARNING **: invalid (NULL) pointer instance (net-rhythmbox:16141): GLib-GObject-CRITICAL **: file gsignal.c: line 1998 (g_signal_handler_disconnect): assertion `G_TYPE_CHECK_INSTANCE (instance)' failed (net-rhythmbox:16141): GStreamer-CRITICAL **: file gstelement.c: line 2096 (gst_element_set_state): assertion `GST_IS_ELEMENT (element)' failed (net-rhythmbox:16141): GStreamer-CRITICAL **: file gstobject.c: line 202 (gst_object_unref): assertion `GST_IS_OBJECT (object)' failed Failed to create the player: Failed to create gnomevfssrc input element; check your installation Any clues as to where i should start to look?
No personal idea; I am going to contact the program's author (brancher?). I have not seen him on IRC so far this weekend. People on IRC in Freenode/#gstreamer suggested that you should run gst-feedback[-0.6 on my system], and paste or attach the output here. This program seems to spit out some errors on my system though (It looks like all the -0.6 items should have symlinks to their names without -0.6 appended - perhaps the gstreamer packager can comment?). Personally, I would suggest running gst-register[-0.6] as yourself to make sure all the gstreamer plugins are in your (XML-based) gstreamer registry. Ideally though, this should just duplicate the system's gstreamer registry in ~/.gstreamer, and really should not be needed. Then I would run gstreamer-properties, which should pop up a little Gnome application. Set both your audio source and sink to OSS if it is not so already (since the ALSA gstreamer compenents are not finished yet - but that would have caused issues later on). Try the test output sound button (solid tone produced), stop the sound, and then hit close on the main dialog box. If you are really into debugging, gst-inspect[-0.6] should dump every possible source, sink, encoder, and decoder known to gstreamer. While the number of items likely varies, on my system it spits out 315 lines. If that doesn't fix it, I do not personally know what is missing. I could have sworn there was a known issue if a file did not exist, but I have renamed both the ~/.gstreamer and ~/.gnome2/net-rhythmbox directories and allowed them to be remade without causing a crash. My startup output (first registry line likely will not show unless gst-register run): ~> net-rhythmbox ~> INFO ( 341: 0) Initializing GStreamer Core Library version 0.6.0 INFO ( 341: 0) CPU features: (c1cbfbff) MMX SSE 3DNOW MMXEXT registry: loaded user_registry in 0.000169 seconds (/home/my_username/.gstreamer/registry.xml) registry: loaded global_registry in 0.137911 seconds (/var/lib/cache/gstreamer-0.6/registry.xml)
Fixed up gst-inspect and gst-register sym links and generated the attached gst-feedback file. Thanks for your help with this.
Created attachment 9742 [details] gst-feedback output from gst-feedback >& gst-feedback
Well, why gst-feedback is spitting out all those pkg-config errors on both our systems is a bug for another day... From an email with Colin Walters (our local Debian god here in Columbus): <snip> > One of the Gentoo packagers is having issues with net-rhythmbox crashing. > The error shown is: > Failed to create the player: Failed to create gnomevfssrc input element; check > your installation. Looks to me like the gnomevfssrc element isn't installed. For the Debian package I just added a dependency on the gstreamer-gnomevfs package. </snip> Try seeing if gnome-vfs is installed. If not emerge it (possibly also gnome-vfs-extras?) and see if that fixes the problem.
I got the following error because monkey-media was not installed. The ebuild should be modified to require that it be installed. ~snip~ gcc -DHAVE_CONFIG_H -I. -I. -I.. -DGNOMELOCALEDIR=\"/usr/share/locale\" -DG_LOG_DOMAIN=\"MonkeyMedia\" -I.. -I../monkey-media/stream-info-impl -DORBIT2=1 -pthread -I/usr/include/gtk-2.0 -I/usr/lib/gtk-2.0/include -I/usr/include/atk-1.0 -I/usr/include/pango-1.0 -I/usr/include/freetype2 -I/usr/X11R6/include -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libgnomeui-2.0 -I/usr/include/libgnome-2.0 -I/usr/include/libgnomecanvas-2.0 -I/usr/include/libart-2.0 -I/usr/include/gconf/2 -I/usr/include/libbonoboui-2.0 -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/linc-1.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/libxml2 -I/usr/include/libglade-2.0 -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -pthread -I/usr/include/gstreamer-0.6 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -DHAVE_GSTREAMER -march=athlon -O2 -pipe -mmmx -m3dnow -c monkey-media-player-gst.c -o monkey-media-player-gst.o >/dev/null 2>&1 mv -f .libs/monkey-media-player-gst.lo monkey-media-player-gst.lo make[3]: Leaving directory `/var/tmp/portage/net-rhythmbox-0.4.5/work/net-rhythmbox-0.4.5/monkey-media' make[2]: *** [all-recursive] Error 1 make[2]: Leaving directory `/var/tmp/portage/net-rhythmbox-0.4.5/work/net-rhythmbox-0.4.5/monkey-media' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/var/tmp/portage/net-rhythmbox-0.4.5/work/net-rhythmbox-0.4.5' make: *** [all-recursive-am] Error 2 !!! ERROR: media-sound/net-rhythmbox-0.4.5 failed. !!! Function src_compile, Line 67, Exitcode 2 !!! compile failed ~snip~
Monkey media should *not* be added as a dependancy. Net-rb links statically (?) against its own copy, which should be included in the net-rb download (note the fact it is moving a file called .libs/monkey-media-player-gst.lo ). Since the author (forker?) of the package told me that, it should be the case. Otherwise, it is a bug to pass upstream. Why the author did this is immediately not clear to me, but I'll bug him again the next time I see him, if not sooner via email. I will try knocking out my own monkey-media install tonight (if it is there) and see if net-rb still works. It is not clear from your error msg what is at fault. Of course, the /dev/null thing doesn't help me either, except that I would hope that the move would not execute if the compile failed. My best guess then is that his dependancies are not 100% correct, and you are running a parallel build. Does the issue persist if you do not give portage a -j parameter to use? (Sorry about the confusion; looking at my initial post, it does not look like I mentioned the independant MM inclusion there, although it is in the ebuild's comments.)
Based on the hint from the debian dev, i rebuilt gst-plugins with USE="gnome" and now have a working net-rhythmbox. Phew. I'll work on codifying what i've learnt into the ebuild and commit something this week. Samuel, thanks for all your help!
Alex: *snip from Colin Walters* Probably what happened is the reporter ran out of disk space or something similar. The reason errors are redirected to /dev/null is because it's the second time that file is being compiled by libtool. */snip from Colin Walters* I was thinking this, but since he's suggesting it, can you just check to see if you are low on disk space?
Sorry for the delay Samuel, but for some reason Bugzilla doesnt email me with a bug gets commented on so I have to manually go and check.. maybe im just not using bugzilla correctly. But to answer your question, No, im not out or nearly out of diskspace. # df -h Filesystem Size Used Avail Use% Mounted on /dev/root 16G 5.7G 10G 36% / /dev/hda4 13G 2.2G 11G 18% /home none 253M 0 253M 0% /dev/shm
That's not Bugzilla acting strangely; you just are not the reporter, assignee, or in the CC: list. To watch if you are not one of these, you have to add yourself to the CC: list for a bug (note that it says "this bug is not in your list" if you are logged in). Anyways, the questions after talking this over with Walters are: 1. Is this reproducable every time you attempt to make this build? Otherwise, you might have funny memory, CPU issues, etc. 2. Does this persist if you set your CFLAGS to something simple like "-march=i686" or just "-O2" or set CFLAGS blank? If so, it may be a gcc segfault issue. 3. Have you ever had any hard disc issues, known filesystem corruption, etc. on your system? Otherwise, this is going to get quite messy to debug, as we cannot simply just take out the /dev/null request on this one part. Libtool is apparently generating it.
1. Is this reproducable every time you attempt to make this build? Otherwise, you might have funny memory, CPU issues, etc. >Reproducable? Yes very much so. But just to make sure its not my memory I ran Memtest86 and everything came out just fine. 2. Does this persist if you set your CFLAGS to something simple like "-march=i686" or just "-O2" or set CFLAGS blank? If so, it may be a gcc segfault issue. >I tried to recompile it three times with different CFLAGS each time. I will attach all three output files. The first one is just with my regular flags CFLAGS="-march=athlon -02 -mmmx -m3dnow -pipe", the second one is with "-march=i686 -02 -pipe" and the third was with CFLAGS="". 3. Have you ever had any hard disc issues, known filesystem corruption, etc. on your system? >No, never. Currently I am running XFS and it is very smooth.
Created attachment 10825 [details] Emerge output This is the outout from the emerge with three different CFLAG settings.
Has everyone seen this link? http://www.gnomedesktop.org/article.php?sid=1064&mode=thread&order=0&thold=1 Is someone working on an ebuild for the latest greatest net-RB?
Ok with a little cruelty I found a simple solution to my problem. These are the steps I took: # emerge media-libs/gstreamer/gstreamer-0.6.1.ebuild (upgrade) # emerge media-libs/musicbrainz/musicbrainz-1.1.0.ebuild (downgrade) # cp net-rhythmbox-0.4.5.ebuild net-rhythmbox-0.4.6.ebuild (evil and suspicious) # emerge net-rhythmbox (should pull version 0.4.6 automagically) # gst-register (I had to do this for root and for my regular user account) # net-rhythmbox ..enjoy :)
Well, I don't want to know what that compiling difficulty was all about. Anyways... <Cerlyn> Do you want the gstreamer dependancy bumped to 6.1? <walters> you'll need gst 0.6.1 for netrb 0.4.7. <walters> (coming soon) So gstreamer 0.6.1 will be a requirement for netrb 0.4.7.
Ok, last post, i promise.. Net-RB will not compile for me against musicbrainz-2.0.1 however after I downgrade to musicbrainz-1.1.0 I can then go ahead and emerge net-rhthmbox without any problem, and at that point I can then upgrade to musicbrainz-2.0.1 as long as I put a symlink to the old musicbrainz library to fool net-rb: ln -s /usr/lib/libmusicbrainz.so.2 /usr/lib/libmusicbrainz.so.1 This is kind of important because some apps like sound-juicer depend on musicbrainz-2.0.1 ..hope this helps
OK... now that we know the right questions to ask, I got the right answers from Colin Walters. Net-rb <= 0.4.6 use Musicbrainz 1.x and gstreamer 6.0. Net-rb 0.4.7 will use Musicbrainz 2.x and gstreamer 6.1. The libraries can be installed in parallel; the development headers cannot. (At least for Musicbrainz, which does not version its /usr/include section (?)) How the Gentoo team wants to handle this is another question. Unless this problem has been encountered before, more research is needed.
Created attachment 10934 [details] media-sound/net-rhythmbox-0.4.7.1 ebuild Test rhythmbox 0.4.7.1 ebuild (0.4.7 tarball lacked a file). Various bugfixes, additions; see NEWS file. Mad dependancy replaced with id3lib (as it should be), musicbrainz, gstreamer versions required bumped, media-libs/gstreamer itself added for clarity (although gst-plugins needs it anyway). Note both musicbrainz does not type its /usr/include/musicbrainz directory at all (causing 1.x/2.x breakage) and gstreamer does not type it beyond the first minor (0.6). This may or may not cause problems for users trying to compile other packages!!!!! (If binary libraries are provided, pre-compiled apps should work; it's a messy situation.) I locally am having trouble seeking in time with ogg vorbis files and this ebuild, but not with MP3 files. Can someone else confirm/deny this? My usual contact has been notified, and suggested some stale 0.6[.0] stuff might be around, but this is the first he's heard of this issue. Just watching some IRC channel banter, some of the pre-provided Internet Radio stations might be missing/moved, although I'll have to wait to see if these are temporary issues or permanent.
The 0.4.7.1 ebuild seems to work with 0.4.8 ; no changes required other than name. My personal ogg vorbis seeking problem has disappeared. This version also features an 3,000+ SLOC cleanup and rewrite if I recall correctly, but I forgot the CVS changelog URL I was shown about a week ago :) Gstreamer 0.6.1 still works with this ebuild, but be advised you will need gstreamer 0.7 if you want ogg vorbis streaming support in addition to ogg vorbis local support (this was same with net-rb 0.4.7.1). Also be advised still that Musicbrainz 1.0 and 2.0 share the /usr/include/musicbrainz directory, and as seen in this bug itself they are mutally incompatible. This fact has nothing to do with this ebuild, and may eventually need to be escalated to its own bug.
Yes, I can confirm that. This ebuild works fine with 0.4.8 after being renamed to reflect the new version number.
The musicbrainz situation is going to have to be addressed completely before this can get commited. I'm working on it but it's not a quick job.
*** Bug 20602 has been marked as a duplicate of this bug. ***
Ok, please work out one finalized and correct ebuild and we will look into it. net-rhythmbox is imo beta software and i'm not sure we would want it in the tree in it's current state, especially with all the problems we had around rhythmbox before in mind. Thats why i've been very reluctant to add it before (i knew about it since the fork) and still am.
Created attachment 11742 [details] media-sound/net-rhythmbox-0.4.8 ebuild Even though the older one works except for documentation installation, here is a slightly newer one. DOC changed to DOCS so documentation would install (documentation file list checked; HACKING removed). Dependancy on the eutils class removed since we are not doing any patching. This does not cause any problems for me, but if it bugs someone else, by all means let us to know to put it back in. Some clarifications/fixes made to the ebuild's comments. If you are using the previous ebuild with net-rb 0.4.8, there is no pressing reason to upgrade unless you want the documentation. I'm told the conditional compilation options should work for net-rb 0.4.8 but are largely untested. I will make a second ebuild this weekend that takes into account USE flags (FLAC, OGG, etc.) as an "early test" of this functionality, but caveat emperor.
1. It seems I must correct myself. After looking at the available configuration options, there is very little overlap between Gentoo's current set of USE flags what net-rb presently can turn on and off (flac, lirc (the only USE flag match), xosd, and audiocd reading). Hence, I will not create an ebuild yet (or likely ever -- see below) for net-rhythmbox that takes USE flags into account. 2. Net-rhythmbox's configuration scripts and source code inherited some lirc (infrared control) support. This is not mentioned in any of the current ebuilds, and its working status is unknown. On my system without any infrared devices, running lircd and then starting net-rb with lirc support hangs net-rhythmbox and causes lircd to kill itself. So if you have lirc installed and want to compile net-rb, you may want to explicity --disable-lirc because no one knows if it is working. If it works, by all means let us know. (Someone else in our local opensource club piped up while I was talking to Colin and may try to fix lirc support, but I would not expect an immediate return. Colin himself may go into configure.in and temporarily disabled lirc by default for everyone until this issue is resolved.) 3. There is an --enable-audiocd configuration flag that some of you may have noticed. But this is not "ready for use in a distribution," so I would discourage using it for the moment unless you are very curious. (Highly experimental, disabled by default) 4. On a somewhat sad thought, please note that I have been informed by Colin Walters that his work on the net-rhythmbox fork will be coming to an end. Net-rhythmbox is being merged back into the main rhythmbox source code. Work on this is about 60% complete, and should provide the best of both worlds when finished. The net-rhythmbox 0.4.8 ebuild thus should become a starting point for an ebuild for whatever the next release of the main rhythmbox is. You can watch the merger happen in near-realtime at http://cvs.gnome.org/lxr/source/rhythmbox/ChangeLog .
A few comments on the ebuild. KEYWORDS -> it doesn't matter what the author thinks, this is about testing on the Gentoo platform. Only ~ the platform you tested it on. RDEPEND -> flac , id3tag ? thought those were used trough gst-plugins, i know there isn't a nice way currently to force certain plugins to exist. We just have to assume they are there for now. src_unpack is unneeded src_configure is unneeded , use G2CONF to pass the option src_install .. they still haven't fixed the scrollkeeper stuff ? it's been broken for ages SCHEMA -> has been obsolete for ages. the eclass takes care of this and about (4) .. i already knew he stopped maintaining, so i don't think we should put net-rb in. See where the main rb takes us this time.
My biggest issue with this ebuild is that i don't have a way of making sure that things like gst-plugins-extras are built with USE="gnome". My default USE flags include -gnome, which results in an unusable net-rb. If this fork is going to be merged back into the mainline codebase, then i agree with foser, we should let it whither. The last thing i want to me maintaining is a dead fork... Feel free to update this bug if you want to get changes out to people but it's not going to get commited (at least by me).
-gnome should build the correct plugins just fine, at least most of them. Or does it use gnomevfssrc ?
Exactly, and what's more, it dies with non-obvious error messages without. See some of my stumbling around trying to get it working earlier in this bug, for details.
Moving this to the sound@g.o list and updating summary to reflect current version.
i suggest we close this, with the current state of net-rb development.
Created attachment 12185 [details] net-rhythmbox 0.4.8 ebuild (slight cleanup) Slight cleanup. Things that relied on the defaults removed. Optional items (xosd, etc.) without USE flags removed; if they're on a system they get used, if not, tough luck. This seems to be the current prefered style.(?) Lirc USE flag still not offered since it may not work correctly. I cannot figure out how to remove the scrollkeeper install hack without causing a sandbox violation. The mad dependancy (providing libid3tag (NOT id3lib)) is back. ID3lib dependancy removed. I mistakenly thought mad was not needed before realizing that id3lib was in /usr/include/id3, and not duplicating /usr/include/id3tag.h . Everything obviously searched for the autoconf script (configure.in) and required to prevent an AC_MSG_ERROR/AC_MSG_FAILURE is included in the dependancy list. The autoconf script was also used to help hunt down optional items. Note the INSTALL documentation that says certains things (ogg, mad,...) are optional is incorrect; the mandatory optional components are now added as dependancies, unless there is a better way to say this(?). Just kind of tidying this up in case someone needs a reference for later main-tree rhythmbox ebuilds with radio support. I'm told there likely will not be a final net-rhythmbox release beyond the current revision.
Won't fix - dead fork.
doesnt net-rhythmbox let you edit the id3tag or the song information of the mp3 files? I can not edit the text boxes in the property dialog for some reason.
