Bugzilla – Bug 6886
AAC files do not play after logging off and logging back on.
Last modified: 2011-05-30 00:24:28 UTC
SC7 is set to run at system boot. I play my AAC file. plays fine. I then go and log out of my MAC. SC7 is still running and music is playing fine. If I then go and log back into my MAC and change the song to a different AAC file the server will act like it is playing the file until about 7 to 10 seconds into the song. It will then skip tracks to number 5 and play only about 7 to 10 seconds of that song and skip to a different random track. It will keep doing this until the server is stop and then started again. This is on a Leopard machine.
Michael, does this sound familiar to you?
Nope, no idea at all. Do you have some sample files I could use for testing? I'm all MP3...
Created attachment 2787 [details] M4A files for testing Here are some M4A files for testing. They were originally created to test gapless playback.
Steven - thanks for these files. But they're not so good to test this issue: most of them are only 5 or 6 seconds long. The issue is odd behaviour after 7-10 seconds. Can you reproduce this with some _real_ files?
Yea, I guess longer files would help ;) You can always transcode your mp3s to aac in iTunes for example. I would not normally recommend doing so as quality is lost but it should be fine for test files. I have not reproduced this myself yet but will give it a shot momentarily. Any logs I should turn on?
Well I am able to reproduce the behavior easily even with the attached files. It seems the minute one logs out of the user that is running SqueezeCenter, transcoding will fail, at least for mov123. One workaround I found would be to switch SqueezeCenter to automatically start when system boots. I am also investigating if switching to faad would also work. See bug 4662 and bug 4705 for info on faad.
Looks like this might be a duplicate of bug 2275.
Dean, ideas?
It is a dup. The workaround now is to install to run at startup on the Mac. We'll look at this post-7.0.
By run at system start up, do you mean the option to run at system boot? I have tested this with that exact setup and it does not fix the issue.
Anoop, a restart is required for the "automatically start when system boots" change to take full effect. Does the workaround still not work even after a system restart?
Steven, You are right. After restart files seem to play properly. Even after I log off, then log back on I am still able to play the file properly.
I am the one who originally reported this bug to Anoop. Based upon the comments today, and additional experimentation, I will document what I have found. If the server is automatically started "When system boots", it will operate correctly without regard to a user logging in or out. However, if the server is started by a user (e.g. after either a fresh installation or selecting "Stop Server"), then it will no longer work when that user logs out. Thus, if a user must stop the server for any reason, the only way to restart the server to have it work independently of that user logging out is to reboot the computer. The work-around then, it to start the server at only boot time.
I wonder whether the two are started the same way. "system start" launches it using some shell script. "when logging in" seems to refer to the MacOS/SqueezeCenter binary inside the prefpane package. But I have no idea how that binar is starting SC...
I'm a bit surprised SC would continue to work at all when you start it as a user process and log out. This wouldn't work on neither Linux nor Windows. I don't know what to do with this bug. It seems to me as if running as a user is one big problem right now. We'll have to go through the Mac installer and integration in a larger scale. It needs major work. IMHO it's currently pretty much broken when a. updating from slimserver and b. doing the user only install. Installing for all users is a valid workaround.
Perhaps it makes sense to require that a user with administrator privileges start it (perhaps by entering his/her password, like installing software) so that it can be started as root (or whatever it needs). Stopping the server should be similar.
Steven, Dean - I'd vote for a "global install" only. Installing as a user leads to all kind of oddities: music stops playing in some cases after the user has logged out, SC can't reliably be started during system start etc. What do you think about removing the "Install for this user only" option?
The one big caveat that I see to removing "Install for this user only" is that the user would need the administrator password to install. Maybe this is not a huge deal overall but this functionality has come in handy for me in the past. I have also used this functionality to install different versions of SqueezeCenter on one Mac by creating multiple accounts to install into. This was for test purposes since only one SqueezeCenter could be running at a time. Even if this functionality is removed I am sure there is a way to do this just the same. I also wanted to mention that this AAC issue might be solved by switching to FAAD. There was talk of doing this for bug 4705. Dean, what do you think? Do you recall the history of the install options?
> I also wanted to mention that this AAC issue might be solved by switching to > FAAD. There was talk of doing this for bug 4705. Oh, I thought one part of the issue was trying to run SC at startup (not logon) while it's installed for the user only? I considered this the main issue...
(In reply to comment #19) > Oh, I thought one part of the issue was trying to run SC at startup (not logon) > while it's installed for the user only? I considered this the main issue... Michael, I am sure you are correct, but maybe this particular issue should have its own bug? Originally this bug was about mov123 failing under certain circumstances.
(In reply to comment #19) > Oh, I thought one part of the issue was trying to run SC at startup (not logon) > while it's installed for the user only? I considered this the main issue... I am the one who originally reported this problem. It seems that there is still a misunderstanding of the issue, despite my explanations. The problem is NOT related to installing SlimServer for a single user, because the problem is clearly exhibited when installed for all users. The problem occurs when the server is started from the preference pane. If the preference is set to start the server at boot, then there is no problem. If, however, a user stops the server from the preference pane, then starts it again (or starts it the first time, assuming it wasn't started at boot), then the server stops operating correctly when that user logs out. It would seem that starting the server from the preference pane causes the server to run with the ownership of the currently logged-in user. Thus, when the user logs out, the server stops behaving correctly. Curiously, the problem only seemed to occur with AAC-encoded files; thus the reference to mpg123.
> The problem is NOT related to installing SlimServer for a single user, because > the problem is clearly exhibited when installed for all users. The problem > occurs when the server is started from the preference pane. Oops... sorry for the noise. Will take a look at what's going on here instead. Thanks for the clarification.
Dean, Michael expresses his frustration tracking this down. Can you speak with him about it?
This appears to be a limitation in QuickTime. Not sure we can do anything about it apart from recommending that people don't use "start at login".
Has this been fixed by the move to using faad2 instead of mov123 in 7.3?
Steven: can you verify this has been addressed? if so please mark as fixed. if not, please provide more information.
This should no longer be an issue since we moved to using faad2 from mov123. Anoop, would you have a moment to verify as fixed?
Everything seems to work for me under 7.4 Please re open if you experience otherwise.