After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 325046 - Hide/don't play data tracks on CDs
Hide/don't play data tracks on CDs
Product: rhythmbox
Classification: Other
Component: Removable Media
Other All
: High major
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
: 538684 (view as bug list)
Depends on:
Reported: 2005-12-27 10:29 UTC by Johan Lund
Modified: 2018-05-24 11:01 UTC
See Also:
GNOME target: ---
GNOME version: ---

patch (1.51 KB, patch)
2005-12-28 14:50 UTC, Jonathan Matthew
accepted-commit_now Details | Review
hide extra tracks, rather than calling them 'unknown' (1.57 KB, patch)
2006-01-03 23:54 UTC, Jonathan Matthew
committed Details | Review

Description Johan Lund 2005-12-27 10:29:38 UTC
Steps to reproduce:
1. Insert CD

Stack trace:
Backtrace was generated from '/usr/local/bin/rhythmbox'

Using host libthread_db library "/lib/".
`shared object read from target memory' has disappeared; keeping its
[Thread debugging using libthread_db enabled]
[New Thread -1208272448 (LWP 15941)]
[New Thread -1247806544 (LWP 15980)]
[New Thread -1224586320 (LWP 15947)]
[New Thread -1214096464 (LWP 15946)]
0x00bf8402 in __kernel_vsyscall ()

Thread 1 (Thread -1208272448 (LWP 15941))

  • #0 __kernel_vsyscall
  • #1 __waitpid_nocancel
    from /lib/
  • #2 libgnomeui_module_info_get
    from /usr/lib/
  • #3 <signal handler called>
  • #4 __kernel_vsyscall
  • #5 raise
    from /lib/
  • #6 abort
    from /lib/
  • #7 g_logv
    from /usr/lib/
  • #8 g_log
    from /usr/lib/
  • #9 g_assert_warning
    from /usr/lib/
  • #10 metadata_cb
    at rb-audiocd-source.c line 404
  • #11 metadata_marshal_VOID__POINTER_POINTER
    at sj-metadata-marshal.c line 82

Other information:
Expected Results:
CD icon in source list and be able to play the cd.

How often does this happen?
Every time with some CD:s. Never with others.

Additional Information:
A working CD is Absolute Christmast (2005) bought in Sweden. A
non-working CD is Gregorian, The Masterpieces ~ Decade 1 (2005) bought in
Comment 1 Johan Lund 2005-12-27 10:48:12 UTC
Running RB from the shell:
Rhythmbox-ERROR **: file rb-audiocd-source.c: line 368 (metadata_cb): assertion failed: (cd_track == NULL)
Comment 2 Teppo Turtiainen 2005-12-27 14:57:13 UTC
According to simple-dup-finder this is a unique stack trace.
Comment 3 Jonathan Matthew 2005-12-27 22:55:34 UTC
This looks more or less like what I was seeing in bug 324222, and the line number in the assertion message suggests your cvs checkout does not have the fix for that bug.  Please do a cvs update and try it again.
Comment 4 Johan Lund 2005-12-28 10:13:24 UTC
Sorry about the linenumber-being-wrong thing. I ran a precompiled, older version of RB. The is the linennumber causing the prolem when running RB compilend from HEAD.

Rhythmbox-ERROR **: file rb-audiocd-source.c: line 407 (metadata_cb): assertion failed: (cd_track == NULL)
Comment 5 Johan Lund 2005-12-28 10:23:03 UTC
Additional info: The CD that's crashing RB contains extra tracks (non-music tracks). Could that cause musicbrainz lookup to be confused?
Comment 6 Johan Lund 2005-12-28 14:38:32 UTC
The last assertion in metadata_cb in rb-audiocd-source.c (on line 407) is a false assuption if the CD contaions additional tracks such as a data track. Removing this assertion makes RB happy with all types of CD:s I have tried with.

This is a small change so I don't supply a patch for it here. Better is that someone with CVS commit privs apply this change and commit.

Holy! This is my first real "improvment" to RB. Perhaps there will be more someday....

Comment 7 Jonathan Matthew 2005-12-28 14:50:03 UTC
Created attachment 56468 [details] [review]

Thanks for confirming that this was the problem.  This patch also sets metadata for tracks not present in the musicbrainz data, but maybe we should assume they're data tracks and make them hidden instead.
Comment 8 Johan Lund 2005-12-29 13:10:33 UTC
(In reply to comment #7)
Is there any way to determine if a track is a music track or a data track? Can it be determined if there is a filesystem on a track and if so hide the track?

If it's not possible (or easy to implement) then my opinion is on showing the track without any metadata set (Just the default name "Track XX" and unknown for the rest of the metadata).

Comment 9 Johan Lund 2006-01-02 22:47:52 UTC
(In reply to comment #7)
> Created an attachment (id=56468) [edit]
> patch

The patch is working as expected. But there is a problem concerning tracks not part of the CD accordning to MusicBrainz. The extra track could be a music track and if so be "playable" in RB, but extra non-music tracks can be really annoying if one is playing a complete CD and finnaly, at the end getting noice that's bringing ones ears directly to the Emergency Room :-).

This is in contradiction to my last comment, I know. Perhaps the real solution is to examin the track to find out what type of contet it's on it (Is there any magic number at the beginning of a track containing a filesystem? My knowledge is a bit limited in thies areas).
Comment 10 Johan Lund 2006-01-02 22:56:57 UTC
Perhaps Sound Juicer could be a source on how to determine if a track is non-music. It's able to do that and apparently without and musicbrainz data (tried it off-line and it showed all music tracks as "Track XX" without any extra tracks).
Comment 11 Jonathan Matthew 2006-01-02 23:40:08 UTC
SJ does this by asking the musicbrainz client library how many audio tracks there are.  I think we can rely on musicbrainz giving us the correct number of tracks, so we should just hide any extra tracks.
Comment 12 Johan Lund 2006-01-03 09:42:09 UTC
OK as long as no music-tracks is hidden because musicbrainz is doing anuthig funny.
Comment 13 James "Doc" Livingston 2006-01-03 13:18:18 UTC
The patch looks good to me.

Using musicbrainz to hide data tracks is probably fine, but doing real detection would probably be better because it will also help in th offline case. I'm not sure how to do the audio track detection though.
Comment 14 Johan Lund 2006-01-03 13:39:20 UTC
SJ can determine this in the offline case. How? Is there any functionallity in musicrainz client library or does SJ exemine the tracks?
Comment 15 Jonathan Matthew 2006-01-03 23:53:31 UTC
In the offline case, sj-metadata-musicbrainz still returns data for the number of tracks reported by the musicbrainz client library.  The musicbrainz client library reads the CD TOC to get the number of tracks and hides the last one for multisession discs, which covers every mixed audio/data CD I've ever seen.

We really don't want to do this ourselves - musicbrainz has 12 different implementations of this code for different operating systems.
Comment 16 Jonathan Matthew 2006-01-03 23:54:37 UTC
Created attachment 56745 [details] [review]
hide extra tracks, rather than calling them 'unknown'
Comment 17 James "Doc" Livingston 2006-01-04 00:17:22 UTC
If musicbrainz handles the offline case, then we should definitely use that.
Comment 18 Johan Lund 2006-01-04 10:10:23 UTC
Another way to go would be to get information from hal about the disc (volume.disc.has_data) and assume that the last track is non-music if the value is true. I'm not a hal expert so please feel free to tear my toughts appart :-)
Comment 19 Bastien Nocera 2006-01-04 10:17:36 UTC
Not good enough, the data or the music can be first, depending on the main use. An interactive CD will have data first, then music. A music CD with bonuses will have the music first, then the data.
Comment 20 James "Doc" Livingston 2006-01-17 12:44:26 UTC
I've committed the patch to cvs, so it shouldn't assert any more. We still need to figure out how to detect data tracks, since trying to play them isn't good.
Comment 21 James "Doc" Livingston 2006-01-25 02:11:17 UTC
Retitling to reflect what needs to be done, and downgrading slightly since it isn't a crasher any more.
Comment 22 Jonathan Matthew 2008-07-04 12:32:49 UTC
*** Bug 538684 has been marked as a duplicate of this bug. ***
Comment 23 GNOME Infrastructure Team 2018-05-24 11:01:22 UTC
-- 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: