Hi
Yes, crossfading works on my system.
I'm sorry I was talking about gapless playback. No crossfading. No
"fading" of any kind. In other words if two oggs overlap (ie the first one
leads into the next like in live albums or classical music) then when they
are played back-to-back then there is no audible gap (nor any fading). So
"Crossfading" is disabled and the "Insert Gap" is set to 0. On my old
system, gapless media (oggs, flacs, mpcs and some mp3s) used to play
gaplessly but on the new system they don't.
Attached as amarok_gdb_backtrace.log. It includes the whole session, not
just the backtrace.
So we have yet another place of crash. This makes 3 of them.
You've lost me here. What are these "places"? I was only aware of one
source of crash - track changes.
valgrind prevents crashes due to memory corruption but it emits
informative
errors about the cause of it. Unfortunately, I could not find any in your
valgrind session.
OK, thanks for the explanation. I saw some errors in the bottom of the
log. The bottom had a summary:
==10668== ERROR SUMMARY: 349 errors from 25 contexts (suppressed: 919 from
5)
==10668== malloc/free: in use at exit: 5,976,940 bytes in 33,024 blocks.
==10668== malloc/free: 5,408,098 allocs, 5,375,074 frees, 523,125,412
bytes allocated.
==10668== For counts of detected errors, rerun with: -v
==10668== searching for pointers to 33,024 not-freed blocks.
==10668== checked 13,473,796 bytes.
Are these not errors? Or are they just harmless ones?
However, I have a few other ideas. You have amarok-engine-yauap
installed.
Please switch engine via Settings -> configure amarok -> Engine to Yauap.
Please read [1] about getting support for various media codec in Yauap.
Restart amarok and try reproducing the bug. If you fail to reproduce, try
other Xine players to see it is Xine problem. Also try downgrading Xine
to
earlier version [2] (1.1.12 you had before July 17) and see if it helps.
I tried yauap and it works fine. Also, I tried playing a few tracks with
gxine and I had the exact same problem so it appears the culprit is xine
after all. I should have checked this but I suppose I assumed that since
the music kept playing that the backend was not to blame. Also, I tried
version 1.1.12 of xine with no problems. So, it appears that the problem
is xine version 1.1.14. I've reinstalled 1.1.14 and will now be using
yauap for the time being until a new version of xine arrives. I may give
1.2 from experimental a go later.
What should we do now? Do you reassign this bug against libxine1? I'm
hoping I wont have to resubmit from the start.
Adam
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
