GNOME Bugzilla – Bug 327153
Add support for NJB-based devices
Last modified: 2018-05-24 11:07:20 UTC
It would be nice to support NJB-based devices, using libnjb (http://libnjb.sourceforge.net). libnomad (http://neutrino.soureforge.net) also provides a gobject based interface on top of libnjb.
Created attachment 57446 [details] [review]
start of a patch
This is the start of a patch to add support for NJB-based devices. It only performs detection at the moment, and doesn't do track loading. As I don't have a NJB device, I'm not actually sure if works.
It also includes some changes to RBRemovableMediaManager to deal with things that aren't mountable by gnome-vfs. It is a bit messy because some things will be reported by gnome-vfs and hal (most things), hal only (NJB devices), or gnome-vfs only (if it wasn't compiled with HAL support). I haven't though of a better way of doing this yet.
There will probably be funky issues caused by handling detection events from both HAL and gnome-vfs, so sources should only respond to one of gnome-vfs (volume != NULL) or HAL (volume == NULL).
I've started to work on this bug. Currently trying to make libnjb work nice with HAL (it's being quite strangely behaved). Maybe the fdi's should be patched so that HAL knows about the NJB devices.. Following from the iPod's example, maybe something like:
info.capabilities: append portable_audio_player"
portable_audio_player.output_formats: append "audio/mpeg"
portable_audio_player.output_formats: append "audio/x-ms-wma"
portable_audio_player.type = "njb"
portable_audio_player.access_method = "user"
Currently the removable-media-manager isn't really set up to handle things that don't get mounted by gnome-vfs. What would be best is having a gnome-vfs module for NJB access, which was started by the author of Neutrino (at http://neutrino.sourceforge.net), however I think he was having some issues which is why it wasn't finished.
If a gnome-vfs module isn't available, several things become harder:
* someone will have to write a gstreamer source element, if you want to be able to play tracks on the player.
* RBRemovableMediaManager will need to be modified to handle non-GnomeVFS stuff
The GStreamer source element wouldn't be greatly difficult, but I don't know about the RBRemovableMediaManager modification...
A Gnome-VFS module would seem like a nicer solution since other applications would be able to use it quite easily, but I'm not sure how you could implement things like adjusting the player settings through Rhythmbox (changing owner, automatic time sync, etc.), since gnome-vfs-daemon would have the usb device open... maybe an njb-daemon and other things using DBUS?
There are still a couple of issues with this I can think of.. particularly Gnome-VFS's handling of metadata (is it still non-existant?).
Having it Gnome-VFS mountable would have nice properties too, since if you weren't writing music to it, the module would be able to write to the file storage. Kind of sucks how Creative decided to use their own filesystem and way of accessing it for the NJB series -- and it also skips music like on a CD sometimes... quite strange.
Not sure if you've seen this, though: http://www.figuiere.net/hub/blog/?2006/03/03/385-digital-audio-player-access-take-2
In theory it could be part of Gnome-VFS, but Gnome-VFS would need to have some modifications to support that type of task.
according to http://live.gnome.org/GnomeVfsPlans
a FUSE module would be more future-proof that a gnomevfs-module...
Whether it is implemented as a Gnome-VFS module or a FUSE module doesn't really matter. As long as it is accessable via Gnome-VFS (which it will be if done as a FUSE module), playback will work.
Regarding metadata et al, we would still need to use the library to access that (we use libgpod to access the db on ipods). The plan for the stuff on the Neutrino site (in my comment above) was to have a daemon which accessed the device, and the gnome-vfs module would talk to it over dbus. That would deal with the fact that only one process can use the device at once.
It would be possible to do without a GnomeVFS/FUSE module, however:
a) it will probably be more difficult to get RB to support it well, and
b) a module will make it easier to add NJB support to other programs (Banshee et al)
Did you apply that patch, James? When I plug in my Creative NJB Zen Touch, RB gets un-minimized, in a rather psychic kind of way. I can't get it to do anything more than that, and the HAL device manager doesn't seem to recognise the thing as an MP3 player.
I'd really like to get my player working with RB, but I feel a bit lost as to anything I could do. I don't have the time or skills to actually do any coding, but I wonder if there's anything else I could do that would be at all useful...
The patch hasn't been applied. Perhaps you have gnome-volume-manager (or something similar) configured to run rhythmbox when a music player is connected?
Well, I'm running Ubuntu 6.06 LTS with CVS HEAD of RB. No idea whether Ubuntu does anything like that, but perhaps it ought to be filed against the Ubuntu bugzilla, as it could confuse a user into thinking that Rhythmbox can handle their NJB.
Created attachment 77883 [details] [review]
Finally updated and some more work done on it. As I don't have a NJB device, I can't actually test this.
Created attachment 77885 [details] [review]
Oops, patch that will actually apply.
With the latest svn and patch from this thread, I get this when I start RB with my Zen Micro plugged in:
$ rhythmbox -D njb
(18:31:25) [0x80ed030] [register_rb_plugin] rb-njb-plugin.c:78: Registering plugin RBNjbPlugin
(18:31:25) [0x80ed030] [rb_njb_plugin_init] rb-njb-plugin.c:105: RBNjbPlugin initialising
(18:31:28) [0x80ed030] [rb_njb_source_set_property] rb-njb-source.c:186: NJB device captured
Backtrace was generated from '/usr/local/bin/rhythmbox'
Using host libthread_db library "/lib/tls/i686/cmov/libthread_db.so.1".
[Thread debugging using libthread_db enabled]
[New Thread -1496791360 (LWP 31816)]
[New Thread -1497011280 (LWP 31818)]
0xa7f80410 in ?? ()
Sorry, I forgot to mention that RB segfaults after that debug output. The same things happens if I plug the device in after RB is running.
After applying this patch, and running ./autogen.sh, I get the following error :
/usr/share/aclocal/libxosd.m4:9: warning: underquoted definition of AM_PATH_LIBXOSD
run info '(automake)Extending aclocal'
or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
aclocal:configure.ac:938: warning: macro `AM_PATH_CHECK' not found in library
configure.ac:938: error: possibly undefined macro: AM_PATH_CHECK
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
What can I do to fix this?
(In reply to comment #14)
> After applying this patch, and running ./autogen.sh, I get the following error
> Running aclocal-1.9...
> /usr/share/aclocal/libxosd.m4:9: warning: underquoted definition of
> run info '(automake)Extending aclocal'
> or see http://sources.redhat.com/automake/automake.html#Extending-aclocal
> aclocal:configure.ac:938: warning: macro `AM_PATH_CHECK' not found in library
Install the "check" package.
Installing the check package worked fine, but when I go to enable the plugin, rhythmbox crashes with a segfault:
Segmentation fault (core dumped)
(In reply to comment #16)
> Installing the check package worked fine, but when I go to enable the plugin,
> rhythmbox crashes with a segfault:
> Segmentation fault (core dumped)
Also, with running rhythmbox like this :
rhythmbox -D njb I get the following output:
rhythmbox -D njb
(16:08:04) [0x80f3028] [register_rb_plugin] rb-njb-plugin.c:78: Registering plugin RBNjbPlugin
(16:08:04) [0x80f3028] [rb_njb_plugin_init] rb-njb-plugin.c:105: RBNjbPlugin initialising
Segmentation fault (core dumped)
The stack trace from comment #12 seems to be damaged. Chris: is there any chance you could get a bactrace from that crash?
Sure, how would I do that?
http://live.gnome.org/GettingTraces has information on how to get a backtrace.
will the patch from comment #11 apply to current SVN? i have a creative zen touch that i'm not too keen to update to an MTP device yet, and would love to get it working with rhythmbox ... been waiting for a patch like this for ages, so i will help testing.
It applies fine to SVN for me.
In it's current form it should detect the device and hopefully list the tracks. Not sure if it can actually do that without crashing, as the code has never been run by someone with an NJB device.
I can apply the patch fine, but RB won't build once I've applied it. I get this output:
gcc -DHAVE_CONFIG_H -I. -I. -I../.. -DGNOMELOCALEDIR=\"/usr/local/share/locale\" -DG_LOG_DOMAIN=\"Rhythmbox\" -I../.. -I../../lib -I../../metadata -I../../player -I../../rhythmdb -I../../widgets -I../../sources -I../../iradio -I../../podcast -I../../plugins -I../../shell -DPIXMAP_DIR=\"/usr/local/share/pixmaps\" -DSHARE_DIR=\"/usr/local/share/rhythmbox\" -DDATADIR=\"/usr/local/share\" -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/cairo -I/usr/include/pango-1.0 -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/gnome-vfs-2.0 -I/usr/lib/gnome-vfs-2.0/include -I/usr/include/gnome-keyring-1 -I/usr/include/orbit-2.0 -I/usr/include/libbonobo-2.0 -I/usr/include/bonobo-activation-2.0 -I/usr/include/freetype2 -I/usr/include/libxml2 -I/usr/include/libglade-2.0 -I/usr/include/gnome-vfs-module-2.0 -pthread -I/usr/include/gstreamer-0.10 -I/usr/include/glib-2.0 -I/usr/lib/glib-2.0/include -I/usr/include/libxml2 -Wcomment -Wformat -Wnonnull -Wimplicit-int -Wimplicit -Wmain -Wmissing-braces -Wparentheses -Wsequence-point -Wreturn-type -Wswitch -Wtrigraphs -Wunused-function -Wunused-label -Wunused-value -Wchar-subscripts -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wcast-align -Wall -Werror -std=gnu89 -DDBUS_API_SUBJECT_TO_CHANGE -I/usr/include/hal -I/usr/include/dbus-1.0 -I/usr/lib/dbus-1.0/include -D_XOPEN_SOURCE -D_BSD_SOURCE -ggdb -MT rb-njb-source.lo -MD -MP -MF .deps/rb-njb-source.Tpo -c rb-njb-source.c -fPIC -DPIC -o .libs/rb-njb-source.o
rb-njb-source.c: In function 'rb_njb_source_new':
rb-njb-source.c:227: error: 'RB_SOURCELIST_GROUP_REMOVABLE' undeclared (first use in this function)
rb-njb-source.c:227: error: (Each undeclared identifier is reported only once
rb-njb-source.c:227: error: for each function it appears in.)
make: *** [rb-njb-source.lo] Error 1
make: Leaving directory `/home/tom/projects/gnomesvn/rhythmbox-njb/plugins/njb'
make: *** [all-recursive] Error 1
make: Leaving directory `/home/tom/projects/gnomesvn/rhythmbox-njb/plugins'
make: *** [all-recursive] Error 1
make: Leaving directory `/home/tom/projects/gnomesvn/rhythmbox-njb'
make: *** [all] Error 2
(In reply to comment #20)
> http://live.gnome.org/GettingTraces has information on how to get a backtrace.
Hey. I have managed to install the gtk debug stuff, but I am unable to find the rhythmbox dbg packages for ubuntu, and I am not getting any more output of crashing rhythmbox.
Created attachment 85257 [details] [review]
updated for svn
RB builds OK with the new patch, but when I try to enable the plugin (even when my Zen Touch is disconnected), RB crashes and Bug Buddy takes over. I'll attach the output that Bug Buddy gives me.
Created attachment 85260 [details]
That means it can't find the "njb-ui.xml" file.
In plugins/njb/Makefile.am, the following is wrong:
plugin_DATA = $(plugin_in_files:.rb-plugin.desktop.in=.rb-plugin) \
EXTRA_DIST = $(plugin_in_files)
it should be
plugin_DATA = $(plugin_in_files:.rb-plugin.desktop.in=.rb-plugin)
uixmldir = $(plugindir)
uixml_DATA = njb-ui.xml
EXTRA_DIST = $(uixml_DATA) $(plugin_in_files)
Created attachment 85299 [details]
I still seem to be getting a similar problem...
BTW, this was after I made the change suggested by James above.
Created attachment 85316 [details] [review]
We were installing the file in the wrong directory, so it wouldn't be found if you were running installed. This should fix it.
Thanks. Unfortunately, I won't be able to test this until Thursday at the earliest.
OK. I have now successfully applied the plugin patch, tweaked a line in plugins/njb/rb-njb-plugin.c to make the device appear in the sourcelist, re-compiled, re-installed, run RB and turned on the plugin.
Now when I start RB with the NJB plugged in, I get this output:
sys:1: Warning: IA__g_object_new_valist: object class `RBNjbSource' has no property named `sourcelist-group'
(rhythmbox:27681): libgnomevfs-CRITICAL **: gnome_vfs_volume_get_drive: assertion `volume != NULL' failed
(rhythmbox:27681): libgnomevfs-CRITICAL **: gnome_vfs_volume_get_display_name: assertion `volume != NULL' failed
(rhythmbox:27681): libgnomevfs-CRITICAL **: gnome_vfs_volume_get_icon: assertion `volume != NULL' failed
sys:1: GtkWarning: gtk_icon_theme_load_icon: assertion `icon_name != NULL' failed
sys:1: Warning: g_object_unref: assertion `G_IS_OBJECT (object)' failed
I have carried out the following steps with latest SVN:
1) apply rb-njb patch
2) in plugins/njb/rb-njb-plugin.c add "rb_shell_append_source (plugin->shell, RB_SOURCE (source), NULL);" after the line with g_hash_table_insert()
3) in plugins/njb/rb-njb-source.c change "sourcelist-group" on line 230 to "source-group" (suggested by teuf: doesn't seem to work)
When I then build and run Rhythmbox, no icon appears, and I get the same output as above. i.e. this still isn't fixed, and I'm still waiting patiently for a response so I can get on with testing this, on behalf of all those people out there with Creative NJB-based devices.
You still get the
sys:1: Warning: IA__g_object_new_valist: object class `RBNjbSource' has no
property named `sourcelist-group'
warning with the change I suggested?
Yup. I get all the stuff I put down above; I just checked it again.
Created attachment 86426 [details] [review]
modified patch to add njb support
This patch incorporates the changes above, but causes the segfault for which I have posted a GDB session below.
Created attachment 86427 [details]
debug session pertainent to patch above
If I run RB and then plug my NJB in, I get a segfault. Here is a GDB session with a backtrace.
+ g_object_get (source,
+ "shell", &shell,
+ "db", &db,
+ "entry-type", &entry_type,
+ g_object_get (source,
+ "shell", &shell,
+ "entry-type", &entry_type,
+ g_object_get (shell, "db", &db, NULL);
should get rid of the warning about
sys:1: Warning: IA__g_object_get_valist: object class `RBNjbSource' has no property named `db'
The warnings about "volume" being NULL are worrying though, they probably indicate that rb couldn't even locate your njb device.
Created attachment 87258 [details]
Backtrace from rhythmbox
Here is a backtrace from running rhythmbox, then plugging in my Zen
Has anyone made any progress on this patch?
The "(rhythmbox:27681): libgnomevfs-CRITICAL **: gnome_vfs_volume_get_drive:
assertion `volume != NULL' failed" warning (and crash) should be gone now, see bug #443367.
It might be earier to build njb support by modifying the mtp plugin since libmtp and libnjb are quite similar.
It's been almost a year since the last update to this bug. Is this patch still being worked on? It would be great to see this in a rhythmbox release.
I'm not sure that this will move any further. Creative no longer releases njb players, and hasn't for years. Players from 2005 onward are either UMS or MTP based. All previous players (as far back as the Zen Xtra in 2003) have MTP firmware upgrades available.
gnomad2 still supports these players quite well, but have moved on to MTP support. Banshee recently ditched their njb efforts. It seems focus should be on making MTP/UMS/iPod work better.
I don't see anything wrong leaving this opened if there are still people with hardware that doesn't support anything but NJB devices. Peter, Chris, Tom?
My device just supports NJB, but I can appreciate that the majority of devices now are MTP or Apple devices and developers want to concentrate on them
On a personal note, I will be replacing my NJB player in a couple of weeks anyway.
-- GitLab Migration Automatic Message --
This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.
You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/121.