Bug 15840 - Squeezeplay-based players may sometimes fail with MP4 files (AAC-LC, HD-AAC or ALAC)
: Squeezeplay-based players may sometimes fail with MP4 files (AAC-LC, HD-AAC o...
Status: CLOSED FIXED
Product: SqueezePlay
Classification: Unclassified
Component: Audio
: 7.4.x
: PC Windows XP
: P2 normal (vote)
: 7.5.0
Assigned To: Alan Young
:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2010-03-05 11:11 UTC by Cory Nielsen
Modified: 2010-04-06 00:30 UTC (History)
6 users (show)

See Also:
Category: Bug


Attachments
server log with player.source = info (15.99 KB, text/plain)
2010-03-25 10:35 UTC, Cory Nielsen
Details
Proposed patch (1.72 KB, patch)
2010-03-29 05:57 UTC, Alan Young
Details | Diff
server log from 3-30-10 (35.90 KB, text/plain)
2010-03-30 13:01 UTC, Cory Nielsen
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cory Nielsen 2010-03-05 11:11:17 UTC
Using SB Touch connected via wireless to SB Server running on a PC, I attempted to play an album which had the first song in mp4 format. The SB Touch skipped the first track, displaying an error message before playing the second song. 

This has been intermittent during my testing. When it does happen, I have noticed that if I manually select a single mp4 file and play it, it plays fine and after that the SB Touch has no problem playing mp4 files in playlists or albums.
Comment 1 Alan Young 2010-03-07 00:26:13 UTC
Are you saying that only the first track is MP4 or that the whole album is MP4 and only the first track does not play?

When you manually select a single MP4 file which plays ok, is this the same MP4 file which was the first file in the album and which failed to play as part of a full album?

What does the MP4 file contain: AAC-LC or ALAC (or AAC_HD)?

Exactly what version of the server is this with?
Comment 2 Cory Nielsen 2010-03-08 10:06:58 UTC
The album contains a collection of file formats (created specifically for testing). Only the first track is mp4.

I can manually select the same mp4 and play it.

This testing was done using SBS version 7.5.0 - r30311, and also seen with 7.5.0 - r30326.
Comment 3 Cory Nielsen 2010-03-08 10:44:59 UTC
Further testing makes me think this may be more complex of an issue than I initially reported, and may not be tied to playlist/album functionality at all.

I have been testing with a few .mp4 files provided by Chris Owens (part of the "Scanner Test" folder of files I'm using for QA), and have been playing these .mp4 files over and over this morning. Sometimes the files play fine, and other times I get this error message:

Problem: Can't open file for:
file:///C:/Users/Public/Music/Scanner%20Test/01.mp4

Strangely, there have been times when I have been able to play an mp4 file, yet partway through if I press the "Previous" button to restart the song I will get the "Can't open file" error. Pressing the Play button after the error message is cleared will sometimes (but not always) play the file as as normal.
Comment 4 Alan Young 2010-03-08 22:53:55 UTC
Cory, once again, what does the MP4 file contain: AAC-LC or ALAC (or AAC_HD)?
Comment 5 Alan Young 2010-03-08 23:26:57 UTC
From http://forums.slimdevices.com/showthread.php?t=71623:

I've got the same problem with yesterday's build of SqueezeServer 7.5-embedded: My Apple Lossless tracks mistakenly get detected as MPEG-4. If I change the transcoding parameters for "mp4" to those meant for "alc", everything works normally (well, I don't have any actual MPEG-4 audio tracks - although I thought that that was just the container format).
Comment 6 Cory Nielsen 2010-03-09 12:35:33 UTC
It's an AAC-LC file.
Comment 7 Chris Owens 2010-03-25 09:18:07 UTC
player.source = info log would be great to help find this issue.
Comment 8 Alan Young 2010-03-25 09:26:26 UTC
Bug 15941 may be a duplicate of this.
Comment 9 Cory Nielsen 2010-03-25 10:35:38 UTC
Created attachment 6700 [details]
server log with player.source = info

Server log captured when the mp4 initially played OK, then displayed the error when I attempted to restart the same file.
Comment 10 Chris Owens 2010-03-25 11:30:00 UTC
thanks for the quick turnaround, Cory!
Comment 11 Alan Young 2010-03-29 05:33:55 UTC
*** Bug 15941 has been marked as a duplicate of this bug. ***
Comment 12 Alan Young 2010-03-29 05:57:59 UTC
Created attachment 6718 [details]
Proposed patch
Comment 13 Chris Owens 2010-03-29 09:16:29 UTC
Please commit your patch to 7.5.0, Alan.  Thanks!
Comment 14 SVN Bot 2010-03-29 09:21:00 UTC
 == Auto-comment from SVN commit #6688 to the player repo by ayoung ==
 == https://svn.slimdevices.com/player?view=revision&revision=6688 ==

Fixed bug 15840: Squeezeplay-based players may sometimes fail with MP4 files (AAC-HE, AAC-HD or ALAC) 
Allow mp4_open() to return 2 meaning not yet done parseing header.
Comment 15 SVN Bot 2010-03-29 09:21:06 UTC
 == Auto-comment from SVN commit #8672 to the jive repo by ayoung ==
 == https://svn.slimdevices.com/jive?view=revision&revision=8672 ==

Fixed bug 15840: Squeezeplay-based players may sometimes fail with MP4 files (AAC-HE, AAC-HD or ALAC) 
Allow mp4_open() to return 2 meaning not yet done parseing header.
Comment 16 Cory Nielsen 2010-03-30 12:59:38 UTC
During testing of this morning's SBS build, I had problems consistently playing an mp4 on an SB Radio. This occurred while using two instances of SBS, one on Windows 7 (SBS 7.5.0 - r30427) and the other running on Mac OS X 10.6.3 (SBS 7.5.0 - r30426). I will attach the log file with player.source set to 'info.'

As I've seen in the past, the file (01.mp4) played fine a few times, then failed (timestamp 12:53:53.9897).
Comment 17 Cory Nielsen 2010-03-30 13:01:02 UTC
Created attachment 6726 [details]
server log from 3-30-10
Comment 18 Andy Grundman 2010-03-30 13:11:40 UTC
The fix for this bug hasn't been rolled out to Radio yet.  Please make sure you have firmware r8672 or higher.
Comment 19 Cory Nielsen 2010-04-01 15:44:20 UTC
mp4 file is now playing correctly on SB Touch and SB Radio.