Bug 133764

I believe I've noticed this before, though it was a while ago and this is the first time I've seen someone else report it.

What is tangerine? Is it in the Limewire citrus family? :)

Tangerine is a gnome utility for serving daap shares.  http://www.snorp.net/log/tangerine

Playing the 43" Minimum Wage track off my own mt-daapd share cuts off at 32", so I don't think it's the daap server.

Do you have crossfading enabled? If so, try with it off.

Thanks!

I am also seeing early cutoffs.  

Amarok 1.4.3, mt-daapd, no crossfading.

1.4.4. Same Issue whilst playing against  mt-daap 0.3.0_pre1417

mt-daaps logs say nothing is wrong.

The problem may lie in mt-daap,  but its not certain.
The same track "get it together" wont play it at all, but VLC will play it fine.

So I reckon if VLC can not have this problem, so can we :)

If I knew more about how Amaroks DAAP player worked, I'd try analyze it myself, but there seems to be no easy explanations lying around that I can see.

*** Bug 140806 has been marked as a duplicate of this bug. ***

This problem still exists in amarok-1.4.5. Is anyone working on it?

If someone wants to email me docs on how the daap "device" is handled in amarok, I'll hack on it. I took a look at the svn sources briefly but since there are no comments I couldn't really figure out how it all fits together.

This is a real killer for me. I store all of my music on a fileserver and the ability to stream all that stuff to my machine at work is awesome. The tracks cutting off early, however, sucks.

I have the same problem too but it only is for the last 2 or 3 seconds.
I also have a problem when switching from song to song with streams. Very often i get this error:

(own translation from Dutch)

Error while loading media

No proper inputplugin found. This often means that the protocol is unsupported or there may be a problem with the connection.

http://localhost:43137/daap.mp3

This can be because the server is very slow and it has make a new stream. 
Maybe amarok hasn't got a wait function for that, because iTunes 7 is working.

I really hope that someone is going to look at this daap bug (i think the two are related) soon because it has been around for a while.

Same problem -- early cutoff by a couple of seconds playing from a Firefly (mt-daapd) share.

Kubuntu Feisty
Amarok 1.4.7 (KDE 3.5.6), build date 8/16/2007

Firefly/mt-daapd version svn-1586 running on Kubuntu Dapper

Present on Gentoo/Amd64, using Amarok 1.4.7 compiled from source and mt-daapd 0.2.4

Looks like the proxy script simply doesn't get all data. The number of bytes missing is somewhat random, even for the same song. Trying to read the entire song at once (instead of streaming) doesn't help. The problem is probably not on the mt-daapd end, since I'm able to get the entire song using a simple GET request for the song (also from a small, external Ruby script).

I know next to nothing about Ruby, but if anyone has ideas for things to try, I'd love to help, since this bug is highly annoying.

Present on ArchLinux using the prepackaged Amarok 1.4.7 (the build script is publically available - I can get it for you if you want it). Accessing the same songs on iTunes works fine, so the problem isn't the mt-daapd server.

I'm also experiencing this problem. 

Amarok 1.4.8
Kubuntu 7.10

the server is itunes 6

I have the same problem with amarok 1.4.8 from debian sid with mt-daapd 0.9.
 I'm using xine backend with alsa.

Amarok 1.4.8, using KDE 3.5.9 on ArchLinux with mt-daapd 0.2.4.1 (mp3 files) on it and tangerine 0.3 (mp3 and m4a files) on OSX.

Same behavior, it cuts off seconds before the end. whether having or not crossfading set doesn't matter.

Amarok 1.4.9, using KDE 3.5.9 and mt-daapd 0.9~r1696-1.1ubuntu0.1 on Ubuntu 8.04. 
I have the same problem and adding/removing crossfade doesn't solve

Sorry, Amarok 1.x is no longer maintained. Our focus is on 2.0.

So I'm closing the report.