Description of problem: Playing a playlist largely of .flac files, periodically a song ends and the next one's album cover appears iconified, the title switches over to the artist and song, the progress bar resets but then nothing happens. If, for example, the song is 3 minutes long, sometimes waiting 3 minutes with no indication of progress, and no sound there's a 1 second burst of noise, the progress bar advances from 0 to 3:00 in a flash and the next song comes up. Hitting the play button during this dead period causes that button to go to its paused look, and the title says paused. Hitting play again causes it to go to its playing look, but there is no progress on the progress bar and no sound. Hitting the ball on the progress bar causes it to start playing. At other times, waiting for more than the length of time of the song that is supposed to be playing causes a one second burst, the progress bar again goes from 0 to 3 min (in my example) and the next song starts playing from somewhere other than the beginning. If the first dead song was 3 min long and I waited 4 min, then the second song starts at its 1 min mark. I watched this for quite some time and although it sounds ridiculous, that is what's happening. Important clues are that the PLAY button works via the GUI and the title bar flips with it to say paused, but otherwise the button is useless. Hitting the progress ball makes it start to play the song. Progress bar goes form 0 to end of song in about 1 second regardless of song length when the issue crops up which is very often. I can't get 5 songs to play in a row. Version-Release number of selected component (if applicable): rhythmbox2.97 How reproducible: Play a library of .flac titles and just wait. I really don't know if its the .flac or if it will do this for all files. The music library I have is mostly flac and the only files I've ever see it stumble on are .flac. Sometimes it will play several .flac titles just fine and then hang as described above. Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info: Music library is on a permanently mounted second disk drive. Switched from F16 to F17 2 days ago. Formatted the primary drive, but did not format the second drive as all it has are static files. Machine is a 1 year old top of the line ASUS gaming machine that I use for development. It had no issues with F16 and now with F17, everything but Rhythmbox is fine. Machine gets a yum -y update every morning and I watch what comes down. Box is firewalled on an ISP's 10. network using a GSM modem.
I tested another music playlist on the same machine and same drive assembly that contains no .flac files. I've listened to music for hours now without a single instance of the strange bahavior reported. I suspect it has something to do with the .flac file format.
Same problem here. My collection consists of a lot ogg and flac files too. But the bug seems not to be limited to rhythmbox, Bangarang and Amarok have the same strange behaviour. I'm using Fedora 17, 64 Bit, KDE 4.8.5 and the gstreamer backend
Problem confirmed on Fedora 17 with a mp3-only playlist. No relevant updates are available. Trying to trigger the problem with Banshee to see if it could be related to GStreamer. Seeing as Bangarang and Amarok use Phonon (which could use GStreamer as backend) this could very well be a GStreamer issue
http://forums.fedoraforum.org/showthread.php?s=3935be138735aed475c03e00ff592953&p=1598105#post1598105 Someone proposes to switch to the vlc backend, this should solve the problem. So propaply it's related to gstreamer.
Problem triggered with banshee as well. Everything seems to point toward GStreamer for now. Could someone update the component accordingly? Switching to a VLC backend obviously isn't a solution.
Just checked with buddy who runs Debian Sid and compared versions sid has GStreamer 0.10.36-1 Fedora has gstreamer-0.10.36-1.fc17 No problems were noted on Debian Sid Hope this helps a little
I started this thread and changed the component to gstreamer as requested, but now things are getting a bit confusing. If gstreamer on Debian is fine and its the same version, how is it the source of the problem on f17? My problem was specific to rhythmbox as that's all I use. I provided a detailed description of the issue and that applies only to rhythmbox. The rest of you that have attached to this thread - are you sure you are seeing the same bug or could it be a different bug in the different products. Specifically, I can force it to play by hitting the ball on the progress bar in rhythmbox. Can you do something similar in the other products? Can you force it to play somehow after the stoppage begins? If it stops for 4 minutes on a 3 minute song, does it start at the 1 minute mark on the next song? Do buttons show being activated but their activation does nothing? I have a ton of mp3's and it has never stopped on an mp3. How can my mp3's be immune when Finke Lamein's mp3's are a problem. Something isn't adding up. I converted my flac & ogg to all mp3 and my problem went away. Can you all go back and take a long look at your situations to see how similar your case is with the one I reported? Maybe there should be separate incidents.
I will test it again with banshee, but the behaviour looked awfully similar to what you are describing for rhythmbox. As for the difference between debian and fedora. it's rarely plain upstream source that gets packaged and shipped. (patches, compile flags. dependencies) To be clear, I experienced freezes on both rhythmbox and banshee. And both gave a one second burst of sound around where the song would end. (not sure about the starting halfway the next song, I will watch better next time) Was the problem with your flac files intermittent or rather constant. I have these freezes once or twice a day at work with a mp3 playlist mostly.
A very small precentage of songs were flac. It took me a while to realize that it was only flac files that were displaying the problem. I had a bunch of Jimmy Buffett CD's that I copied over in flac format. If I listened only to the Jimmy playlist (all flac), the problem appeared sporadically. Therefore some flac files played fine and then every once in a while a period of silence and a burst of noise followed by the next song but not starting at the beginning. I started to watch what was going on and clocked songs. The period of silence was always the length of one song and a piece of the next one. That piece is where that next song would start. i.e. a 3 minute song (completely silent) followed by a 5 minute song, where the silence period was 4 minutes and 20 seconds, always meant that the second song would start at the 1 minute and 20 second mark in my example. The total period of silence was always the length of the completely silent first song, plus whatever part of the second song that didn't play. I've had rhythmbox disappear on me but never freeze. It would fail for no apparent reason on one of my x86_64 boxes. I'd restart it and it would be fine. On a netbook (32 bit cpu) rhythmbox almost never starts the first time. I got to the point where I'd open up a terminal session and execute "rhythmbox" from the command line knowing it would fail 5 or 10 times in a row before it would stick and function normally thereafter. Arrow up and enter was easier than using that lousy track pad. It never does this on my 64bit development box.
Just had the exact same issue with Banshee: silence, then 1 second burst of sound, and next song starts at 1:20 i didn't try the playbutton, but earlier I did try to click the progress ball, and that made the song play. I say that qualifies as at least the same behaviour, if not the same bug. I have an opportunity now, because I'm going to do a fresh install of this laptop soon, so will try to confirm again afterwards.
Well it took a while, but i had a freeze in rhythmbox after the reinstall. I haven't been able to properly reproduce it with banshee, but i have the idea i will be able to soon. Maybe we should give this bug at list a low priority, if we agree this is a gstreamer issue
I have no idea what component is actually at fault. I started this thread stating it was a problem with rhythmbox. Consensus pushed it to gstreamer as the same problem was observed with other players and gstreamer seemed to be a common element capable of displaying this problem. I tried changing the priority, but there appears no way to do it. There is no (edit) tag and hitting the "priority" link just displays the definitions. This bug will be ignored as most of the bugs I've uploaded have been ignored when they're not catastrophic. I understand why, so changing the priority isn't all that important.
Maybe we should move this bugreport upstream, to GStreamer bugtracker https://bugzilla.gnome.org/
I created Bug 683037 @ https://bugzilla.gnome.org
As a suggestion try running the player from a command line with a GST_DEBUG=X line. So for example GST_DEBUG=3 banshee or GST_DEBUG=3 rhythymbox and post the output here... its likely to be quite large but may provide clues as to what issue/element is causing the issue.
I converted all my flac files to mp3 and the problem went away for me, so I can't test with your suggestion.
Everyone that added comments here should also add their experiences to https://bugzilla.gnome.org/show_bug.cgi?id=683037
Or just mention this link on there, so they can see for themselves.
This message is a reminder that Fedora 17 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 17. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '17'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 17's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 17 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior to Fedora 17's end of life. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 17 changed to end-of-life (EOL) status on 2013-07-30. Fedora 17 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.