This is a trouble some "bug" that I've had with Goggles since I first
installed it many releases ago. Never reported because it was nearly
impossible to reproduce a reliable test case.
Some background info -
Slackware64 current
taglib-1.6.3
taglib-extras-1.0.1
fox-toolkit-1.6.37
gogglesmm-0.11.5
My music is arranged in this order -
Music/$ARTIST/$ALBUM/$TRACKS
In gmm if I choose to play a complete album (double clicking the album
title) usually 99.9% of the time things go as planned. Tracks
1,2,3,4 .... are played. Sometimes, tracks 1,2 then 3 are played, then
track 3 is repeated forever. Or it could be track 1, or it could be
track 2 --- it's completely random. Shuffle mode in said album works
fine. Using other players (xmms, audacious, mpg123) work as expected.
Even Juk (also taglib based) works as expected.
This only happens on a very few select .mp3 files. Ogg, and flac, are
fine.
I believe I have finally found at least one complete album that this
happens with. This very well could be an encoder issue, the encoder
and options used have long escaped my memory. With this album, track 1
plays, then track 2. The info does NOT change to the next song - it
states track one is still playing. Then track 2 repeats forever.
Found a program called encspot, and gave this info -
http://pastebin.com/raw.php?i=EHyS5gyH
On Fri, Jan 14, 2011 at 4:50 AM, disturbed1 <disturbed1...@gmail.com> wrote: > This is a trouble some "bug" that I've had with Goggles since I first > installed it many releases ago. Never reported because it was nearly > impossible to reproduce a reliable test case.
> Some background info - > Slackware64 current > taglib-1.6.3 > taglib-extras-1.0.1 > fox-toolkit-1.6.37 > gogglesmm-0.11.5
What's the xine version?
FYI, taglib-extras is no longer used.
> My music is arranged in this order - > Music/$ARTIST/$ALBUM/$TRACKS
> In gmm if I choose to play a complete album (double clicking the album > title) usually 99.9% of the time things go as planned. Tracks > 1,2,3,4 .... are played. Sometimes, tracks 1,2 then 3 are played, then > track 3 is repeated forever. Or it could be track 1, or it could be > track 2 --- it's completely random. Shuffle mode in said album works > fine. Using other players (xmms, audacious, mpg123) work as expected. > Even Juk (also taglib based) works as expected.
That's weird. It could potentially happen if the 'active' track hasn't been marked properly (and still refers to the previous track). I haven't seen this happen yet.
> This only happens on a very few select .mp3 files. Ogg, and flac, are > fine.
So perhaps this is a xine bug related to some notification it sends out (or not).
> I believe I have finally found at least one complete album that this > happens with. This very well could be an encoder issue, the encoder > and options used have long escaped my memory. With this album, track 1 > plays, then track 2. The info does NOT change to the next song - it > states track one is still playing. Then track 2 repeats forever. > Found a program called encspot, and gave this info - > http://pastebin.com/raw.php?i=EHyS5gyH
So does it also happen when you just play track 2? Or does it also randomly happen to any track when you play this album? Can you run with xine debug info on and send me the output?
> So does it also happen when you just play track 2? Or does it also
> randomly happen to any track when you play this album?
> Can you run with xine debug info on and send me the output?
> 'gogglesmm --xine-debug'
Pastebin Link -
http://pastebin.com/9cGCbWuS In this session Goggles played track 1, advanced to track 2 (title not
updated), played track 2 again.
cd to the folder, and executed xine --verbose=2 *.mp3
Xine does advance tracks, and update the title bar.
Here's that log -
http://pastebin.com/Nc48JWAr
> > I can make the files available if you'd like.
> That would be usefull.
> Cheers,
> Sander
You've got mail
I should note for completeness -
I did re-rip this same album using lame, helix-mp3 encoder (Real
Networks Xing implementation), fastencc (through wine), ogg, and flac.
CBR, and VBR. The new rips did not have this problem.
On Fri, Jan 14, 2011 at 10:20 PM, disturbed1 <disturbed1...@gmail.com> wrote: >> What's the xine version?
>> FYI, taglib-extras is no longer used.
> xine-lib-1.1.17 > xine-ui-0.99.5
> I should note for completeness - > I did re-rip this same album using lame, helix-mp3 encoder (Real > Networks Xing implementation), fastencc (through wine), ogg, and flac. > CBR, and VBR. The new rips did not have this problem.
> And I see you have the tracks -- good luck :)
This issue is caused by an incorrect VBR header (xing) in the mp3 file. The duration of the mp3 as seen by xine is incorrect which causes the bug in gogglesmm*. There are tools available that will fix your mp3 without having to re-rip them. For example:https://gna.org/projects/vbrfix
I'll see if I can make gogglesmm behave better with regards to broken vbr's.
Cheers,
Sander
* The actual problem is that we get the "playback finished" event before the actual track has finished playing. This is on purpose, so we have time to load the next track. When we load the next track, we cannot update the GUI yet, since the old track is still playing. So we set a timer which fires whenever the new track actually starts playing. Once the timer fires, we update the GUI. The timer is set based on the length of the track and its current position. So if the length information is incorrect the timer may fire too late or too early, causing things like repeating tracks (the GUI thinks some other track is playing).
> On Fri, Jan 14, 2011 at 10:20 PM, disturbed1 <disturbed1...@gmail.com> wrote:
> >> What's the xine version?
> >> FYI, taglib-extras is no longer used.
> > xine-lib-1.1.17
> > xine-ui-0.99.5
> > I should note for completeness -
> > I did re-rip this same album using lame, helix-mp3 encoder (Real
> > Networks Xing implementation), fastencc (through wine), ogg, and flac.
> > CBR, and VBR. The new rips did not have this problem.
> > And I see you have the tracks -- good luck :)
> This issue is caused by an incorrect VBR header (xing) in the mp3
> file. The duration of the mp3 as seen by xine is incorrect which
> causes the bug in gogglesmm*. There are tools available that will fix
> your mp3 without having to re-rip them. For
> example:https://gna.org/projects/vbrfix
I figured it was an incorrect vbr header considering the time display
was not correct. Kind of funny to me. This was a problem with some
encoders years ago. Can't believe I still have these original rips I
made way back then.
A better fix is to just use a proper encoder that writes correct
headers :)
On Sat, Jan 15, 2011 at 6:21 PM, disturbed1 <disturbed1...@gmail.com> wrote:
> On Jan 14, 11:48 pm, Sander Jansen <s.jan...@gmail.com> wrote: >> On Fri, Jan 14, 2011 at 10:20 PM, disturbed1 <disturbed1...@gmail.com> wrote: >> >> What's the xine version?
>> >> FYI, taglib-extras is no longer used.
>> > xine-lib-1.1.17 >> > xine-ui-0.99.5
>> > I should note for completeness - >> > I did re-rip this same album using lame, helix-mp3 encoder (Real >> > Networks Xing implementation), fastencc (through wine), ogg, and flac. >> > CBR, and VBR. The new rips did not have this problem.
>> > And I see you have the tracks -- good luck :)
>> This issue is caused by an incorrect VBR header (xing) in the mp3 >> file. The duration of the mp3 as seen by xine is incorrect which >> causes the bug in gogglesmm*. There are tools available that will fix >> your mp3 without having to re-rip them. For >> example:https://gna.org/projects/vbrfix
> I figured it was an incorrect vbr header considering the time display > was not correct. Kind of funny to me. This was a problem with some > encoders years ago. Can't believe I still have these original rips I > made way back then.
> A better fix is to just use a proper encoder that writes correct > headers :)
