Problem adding mp3s to rhythmbox from a remote host.

Bug #84449 reported by Reiner Jung
8
Affects Status Importance Assigned to Milestone
GStreamer
Expired
Medium
gstreamer0.10 (Ubuntu)
Invalid
Low
Unassigned

Bug Description

The problem is somewhat strange. It has something to do with gnome-vfs. Therefore I cannot name one single package. To understand the problem, I explain the setup first, then I want to tell you what I have already tried and if possible, I will add a mp3 file which can be used to reproduce the error.

The Setup

We use a server in our home, where we store all our data including our music files. The server allows access through samba and ftp (but the problem can be reproduced also with webdav). For the current problem, I used ftp access. On the remote side, I use vsftpd on a ubuntu (dapper). The local machine is running ubuntu 6.10 (edgy).

The Problem

I can login and browse the remote directory with nautilus, and I can open the property dialog for other files on the server, this includes mp3 files. But for no reason, I cannot do the same thing for all mp3 files. For some files, nautilus tells me to wait and doesn't bring up the property dialog at all.

When I try to add the same file to the rhythmbox music database, I get the gstreamer error "failed to change state". Also I cannot open the music files with totem.

I've tested gnome-vfs with gnomevfs-ls, gnomevfs-cat and gnomvfs-info. All three work fine on the files, nautilus, totem and rhythmbox have problem with.

First I thought that might have something to do with gstreamer, but as the problem can be reproduced not only with some mp3s, but also with ogg files, I guess it has to do something with gnome-vfs. The problem cannot be based on the tool, which created the mp3s(oggs) because files from the same CD, ripped with the same tool, behave differently. Some work, others don't. And the strange thing is, you can repeat it, and always the same files are rejected.

It has nothing to do with permissions, user names or groups, because all files are owned by the same user and same group, and all files have the same permissions. The same thing applies to the directories. They are all "rwx" for the music user.

I also can copy the files from remote to my local machine (with nautilus). Then I can add them to the music database without any trouble.

Hope you have more luck in finding the real error. Don't hessitate to ask me any questions.

cu
  Reiner

Revision history for this message
Reiner Jung (prefec2) wrote :
Revision history for this message
Brian Murray (brian-murray) wrote :

Thanks for your bug report. Could you please try the following 'gst-launch-0.10 playbin uri=ftp://....' with one of the suspect mp3s? Thanks in advance.

Revision history for this message
Reiner Jung (prefec2) wrote :

I've tested your gst-launch line above with one working file and with one that does not work. Also I activated the verbose feature. The detailed results are in the attached files. Here a quick summary:

gst-launch-0.10 --verbose playbin uri=ftp://xxxxxxxx:xxxxxxxx@syrius/music/70er/The\ Alan\ Parsons\ Project/The\ Best\ Of\ The\ Alan\ Parsons\ Project/03\ Games\ People\ Play.mp3
Setting pipeline to PAUSED ...
/playbin0/decoder/typefind.src: caps = application/x-id3
Pipeline is PREROLLING ...

after that, the program stops. I waited several minutes, but nothing happend. In contrast to that, the working file produced the following output:

gst-launch-0.10 --verbose playbin uri=ftp://xxxxxxxx:xxxxxxxx@syrius/music/KLASSIK/Vivaldi/4\ Jahreszeiten/Frühling\ 1.mp3
Setting pipeline to PAUSED ...
/playbin0/decoder/typefind.src: caps = application/x-id3
/playbin0/selector_audio_src0: active-pad = "sink0"
Pipeline is PREROLLING ...
[...] <= lots of output
Pipeline is PREROLLED ...
Setting pipeline to PLAYING ...
New clock: audioclock0

Hope that helps.
   Reiner

p.s. I surfed the net a little bit about a hang uring prerolling, so far I've found nothing valueable. :-/

Revision history for this message
Sebastien Bacher (seb128) wrote :

Could you get a log with "GST_DEBUG_NO_COLOR=1 GST_DEBUG=5 gst-launch-0.10 playbin uri=... &>log"?

Revision history for this message
Reiner Jung (prefec2) wrote :

Jep. Additional I've created a log for a working URI. But it is rather large (247 MB). So I do not add it. Both files look quite similar except for the last 200-300 lines.

Revision history for this message
Sebastien Bacher (seb128) wrote :

Thank you for your work on that, I've forwarded it upstream: http://bugzilla.gnome.org/show_bug.cgi?id=414834

Changed in gstreamer:
status: Unknown → Unconfirmed
Revision history for this message
anonym (launch-mailinator) wrote :

if it helps, i've noticed this problem seems to be related to variable bit rate "v0" -encoded mp3s.

Revision history for this message
Sebastian Dröge (slomo) wrote :

Does anybody still have this problem with the latest versions in feisty? Everything works fine here for me...

Changed in gstreamer0.10:
status: Confirmed → Needs Info
Revision history for this message
Reiner Jung (prefec2) wrote :

It works perfectly on my machine now. At least with the above sequence with gst-launch. In rhythmbox, it still doesn't work, but I will wait to investigate this when the final feisty release is out. Also rebuilding the music DB might be helpful :-)

Revision history for this message
Brian Murray (brian-murray) wrote :

Thanks for taking the time to report this bug and helping to make Ubuntu better. Now that the final version of Feisty Fawn is available we were wondering if this issue still exists. Thanks in advance.

Changed in gstreamer0.10:
assignee: nobody → brian-murray
Revision history for this message
dutch (dutch1918) wrote :

I am running Feisty Fawn 7.04 am having the same issue with Rhythmbox ie gstreamer error "failed to change state" on some (not all) of my .mp3 files

Changed in gstreamer0.10:
assignee: brian-murray → nobody
status: Needs Info → Confirmed
Revision history for this message
Sebastian Dröge (slomo) wrote :

Could someone check if this is still happening with the gstreamer stack from hardy?

Changed in gstreamer:
status: New → Incomplete
Changed in gstreamer0.10:
status: Confirmed → Triaged
Changed in gstreamer:
status: Incomplete → New
Changed in gstreamer:
status: New → Invalid
Revision history for this message
Sebastien Bacher (seb128) wrote :

We are closing this bug report as it lacks the information, described in the previous comments, we need to investigate the problem further. However, please reopen it if you can give us the missing information and don't hesitate to submit bug reports in the future.

Changed in gstreamer0.10 (Ubuntu):
status: Triaged → Invalid
Changed in gstreamer:
importance: Unknown → Medium
status: Invalid → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Related questions

Remote bug watches

Bug watches keep track of this bug in other bug trackers.