Bug 134416 - DAAP client handles non-"fast start" m4a poorly
Summary: DAAP client handles non-"fast start" m4a poorly
Status: RESOLVED INTENTIONAL
Alias: None
Product: amarok
Classification: Applications
Component: Collections/DAAP (show other bugs)
Version: unspecified
Platform: Ubuntu Linux
: NOR normal
Target Milestone: ---
Assignee: Amarok Developers
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2006-09-20 21:28 UTC by Isaac Wilcox
Modified: 2008-08-06 00:00 UTC (History)
0 users

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Isaac Wilcox 2006-09-20 21:28:45 UTC
Version:            (using KDE KDE 3.5.4)
Installed from:    Ubuntu Packages

Hi,

I have a large number of M4A files on my mt-daapd music server that aren't "fast start" compatible.  Dunno precisely what that means, but basically it's about having a copy of the metadata at the beginning of the file as well as the end.  This is important only when streaming; Amarok handles these files just fine if they're local, and thus seekable, but when streaming them Amarok produces about 20s of mostly silence, punctuated by ear-grinding squelches, pops and white noise, before finally giving up.  It took me a while to work out what the problem was.  A clear error message mentioning "fast start" would have helped immensely.  (The solution, by the way, is to run "mp4creator -optimize" over all your M4As.)

I've temporarily stuck a couple of *tiny* example tracks up, so there's something to test with:
  http://www.iwilcox.me.uk/amarokm4a/
First try them locally, then put them on your server and try to stream them (I recommend using "4s of noise", because "20s of silence" has a tendency to crash Amarok).  They're tagged with artist/album "Short" so should be easy to find via DAAP.  As soon as you hit "play" you should hopefully see what I mean.

My SoundBridge handles them slightly more gracefully - it buffers the whole M4A (causing an annoying 60s+ delay for average-sized tracks, because it's not fast at buffering), eventually gets the metadata it needs, and plays the track.  iTunes sits there as if it's going to play the track but never does, and marks the track with a "!" symbol only when you give up and switch to another track.

Solutions, then, most effort and most user-friendly first:

1) Buffer the whole track (won't take long); while doing so, maybe pop up one of those messageboxes without a timer saying something like "No 'fast start' info found; buffering entire track.  To avoid this message in future..." so that folk have some terms to Google for before they complain that Amarok is slower to play DAAP tunes than iTunes was.  Record the fact that we've popped the dialog up, because the user might not care enough to fix it.  Once we've got the info from the end of the stream, play on as if the track were local ('cause we can do those, remember).

2) Somehow just detect the lack of "fast start", and pop up a timer messagebox explaining that it's needed to even play anything.  If there's some way of marking a track as dodgy in the playlist like iTunes does, then do that too.

3) Silently fail, but I mean silently - don't play squelches at me! :)

Cheers,

Zak
Comment 1 Isaac Wilcox 2006-09-20 21:40:07 UTC
Should mention: this may well not be DAAP-specific, but it's the only easy way I have to stream things right now.
Comment 2 Lydia Pintscher 2008-08-06 00:00:33 UTC
I am sorry but this will not get fixed in Amarok 1.4 as we are focused on Amarok 2 now.

Thank you for your report.