GNOME Bugzilla – Bug 325046
Hide/don't play data tracks on CDs
Last modified: 2018-05-24 11:01:22 UTC
Steps to reproduce:
1. Insert CD
Backtrace was generated from '/usr/local/bin/rhythmbox'
Using host libthread_db library "/lib/libthread_db.so.1".
`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 -1208272448 (LWP 15941))
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.
A working CD is Absolute Christmast (2005) bought in Sweden. A
non-working CD is Gregorian, The Masterpieces ~ Decade 1 (2005) bought in
Running RB from the shell:
Rhythmbox-ERROR **: file rb-audiocd-source.c: line 368 (metadata_cb): assertion failed: (cd_track == NULL)
According to simple-dup-finder this is a unique stack trace.
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.
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)
Additional info: The CD that's crashing RB contains extra tracks (non-music tracks). Could that cause musicbrainz lookup to be confused?
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....
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.
(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).
(In reply to comment #7)
> Created an attachment (id=56468) 
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).
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).
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.
OK as long as no music-tracks is hidden because musicbrainz is doing anuthig funny.
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.
SJ can determine this in the offline case. How? Is there any functionallity in musicrainz client library or does SJ exemine the tracks?
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.
Created attachment 56745 [details] [review]
hide extra tracks, rather than calling them 'unknown'
If musicbrainz handles the offline case, then we should definitely use that.
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 :-)
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.
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.
Retitling to reflect what needs to be done, and downgrading slightly since it isn't a crasher any more.
*** Bug 538684 has been marked as a duplicate of this bug. ***
-- 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/110.