[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-bugs-dist
Subject:    [Bug 115321] WISH: amarok does not stream OGG over http using artsd
From:       Gunter Ohrner <kdebugs () CustomCDROM ! de>
Date:       2005-10-31 20:21:16
Message-ID: 20051031202116.28459.qmail () ktown ! kde ! org
[Download RAW message or body]

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.
         
http://bugs.kde.org/show_bug.cgi?id=115321         




------- Additional Comments From kdebugs CustomCDROM de  2005-10-31 21:21 -------
BTW, gstreamer-engine also works pretty unreliably for me, not crashing amaroK but \
making it freeze while consuming 100% now and then. This seems to be related to some \
media files renders the gstreamer-engine pretty useless for me as well.

If the freeze happens, the current song will play until it's finished, then the music \
stops. (I'm not sure if the freeze happens the moment the song has finished or if it \
already happens before.)

I just noticed that this gstreamer-engine problem may be caused by some of my media \
files. The mp3 files in question also behave wierdly when jumping within the track \
hwile using gstreamer-engine; playback seems to continue about 30% further in the \
song tahn selected (and the progress indicator also jumps 30% farther than clicked). \
This does not happen with my Vorbis files and some other mp3 files I just tested. It \
also does not happen if using arts-engine to play these files.


mp3info -x of one of the files in question:

Media Type:  MPEG 1.0 Layer III
Audio:       192 kbps, 44 kHz (stereo)
Emphasis:    none
CRC:         No
Copyright:   No
Original:    No
Padding:     Yes
Length:      3:39


checkmp3 -v says:

Possible ID3v2 frame found, skipping

FILE_NAME           (...)
GOOD_FRAMES         0
BAD_FRAMES          0
LAST_BYTE_CHECKED   1559

USER_TIME           0.00s
SYS_TIME            0.00s


mp3check -l gives the following output:

mpeg 1.0 layer 3 44.1kHz 192kbps stereo       no emph --- ---- ----     3:39.22


Finally, mp3check -e says:

3677 bytes of junk before first frame header
valid id3 tag trailer v1.0 found


Looks pretty sane for me so far.

Does this sound like a gstreamer mp3 decoding bug, is it an amaroK related bug and \
where should I report it? (gstreamer of KDE bugzilla?)


[prev in list] [next in list] [prev in thread] [next in thread]