Bugzilla – Bug 1869
synced music doesn't start
Last modified: 2009-09-08 09:29:38 UTC
I get the same thing with the 6.1.1 release, and I can reproduce it easily. 1. Synchronise players 2. Start listening to the first track 3. Hit fast forward - at this point, the display updates, but the next track doesn't start. 4. Hitting play starts the track, or FF again moves to the next which starts playing 5. Hold pause (stop) 6. Hit play - current track starts 7. Hit FF - again, the display updates but the track doesn't start. steps 4-7 are the ones to repeat it over and over. My system: Compiled slim.exe on Windows 2003 server, synchronised Squeezebox2s.
Hmm...by fast forward, do you mean pressing the FWD button to skip to the next track or do you mean pressing and holding the FWD button to scan through the current track at a faster rate. If you mean the former, I'm having trouble recreating the problem. Could ask I you to provide some more information: 1) Does this problem exist if you use the SKIP button on the web interface? 2) When you see this problem, does it happen when you hit FWD for either player or just one? 3) What format audio are you playing? Does it happen for a specific type or any format?
Whoops, that was a cut and paste from the forum discussion: http://forums.slimdevices.com/ showthread.php?t=15277 by rob holden
I meant skip, not scan. I will look into your questions in detail at the weekend - I'm away from home until Friday. Additional information that may be relevant: - I had three players synced. I didn't try going back to two - I have custom .ir and .map files in use on two of the three Squeezebox2s - but to the best of my memory they don't modify the fastforward button. --Rob
OK, I've done another session of testing. Responding to Vidur's questions in comment #1: 1) The problem is the same with the skip button in the web interface. I've also noticed the skip backwards button exhibits this problem too, in exactly the same way. 2) The problem can be reproduced at either (for 2 synced players) or any (for 3 synced players) of the players - it's not specific to a particular player 3) Tested with mp3 and flac. I hadn't realised before, but it's possible to reproduce the problem slightly more simply. On my system, for any synced playing, every other time I press skip (or skip backward) the playing does not automatically start. Play - synced players start (track 1) Skip - next track starts (track 2) Skip - next track is cued but doesn't start (track 3) Skip - next track starts (track 4) Skip - next track is cued but doesn't start (track 5) ... etc SlimServer Version: 6.1.1 - 3774 - Windows Server 2003 - EN - cp1252
Going to push this to 6.2
Rob, sorry for the delay here. I'm also having trouble reproducing this problem. Two synced players with the latest nightly release skipping forward with both the remote and the web interface seem to be working well for me. I'd like to ask you to try the latest version and copy out the debug output with the d_sync setting turned on. You can turn this on under Server Settings -> Debug, check off d_sync and then click on the link near the top to view the most recent debug output. Try to reproduce the problem, and if you can, grab the text from that link and paste it into this bug. Thanks. -dean
I'm on v6.2 now, but I still have the same problem. Regards, Rob 2005-11-05 10:48:14.1481 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:14.1649 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:14.1658 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:14.1666 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:14.1675 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:14.1683 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:14.1692 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:14.1700 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:14.1710 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:14.1719 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:14.1728 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:14.1736 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:14.1745 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:14.1754 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:14.1762 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:14.1771 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:14.2392 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:14.2412 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:14.3777 00:04:20:05:b5:a9 checking buffer fullness: 131072 2005-11-05 10:48:14.3778 00:04:20:05:b5:a9 is ready to sync 1131187694.37785 2005-11-05 10:48:14.3794 00:04:20:05:b5:b6 checking buffer fullness: 131072 2005-11-05 10:48:14.3796 00:04:20:05:b5:b6 is ready to sync 1131187694.37958 2005-11-05 10:48:14.3796 all clients ready to sync now. unpausing them. 2005-11-05 10:48:16.9800 00:04:20:05:b5:b6 checking buffer fullness: 1735554 2005-11-05 10:48:16.9801 00:04:20:05:b5:b6 is ready to sync 1131187696.98015 2005-11-05 10:48:16.9825 00:04:20:05:b5:a9 checking buffer fullness: 1776223 2005-11-05 10:48:16.9826 00:04:20:05:b5:a9 is ready to sync 1131187696.98267 2005-11-05 10:48:16.9827 all clients ready to sync now. unpausing them. 2005-11-05 10:48:27.9985 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:27.9994 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:27.0003 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:27.0011 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:27.0020 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:27.0028 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:27.0037 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:27.0046 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:27.0055 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:27.0063 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:27.0072 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:27.0081 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:27.0089 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:27.0098 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:27.0106 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:28.0240 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:28.0336 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:28.0356 00:04:20:05:b5:b6 checking buffer fullness: 0 2005-11-05 10:48:28.1563 00:04:20:05:b5:a9 checking buffer fullness: 131072 2005-11-05 10:48:28.1565 00:04:20:05:b5:a9 is ready to sync 1131187708.15648 2005-11-05 10:48:28.1640 00:04:20:05:b5:b6 checking buffer fullness: 131072 2005-11-05 10:48:28.1641 00:04:20:05:b5:b6 is ready to sync 1131187708.16412 2005-11-05 10:48:28.1642 all clients ready to sync now. unpausing them. 2005-11-05 10:48:38.0235 00:04:20:05:b5:b6 checking buffer fullness: 3145592 2005-11-05 10:48:38.0236 00:04:20:05:b5:b6 is ready to sync 1131187718.02362 2005-11-05 10:48:38.0280 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:38.0289 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:38.0297 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:38.0306 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:38.0315 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:38.0324 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:38.0333 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:38.0342 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:38.0589 00:04:20:05:b5:a9 checking buffer fullness: 0 2005-11-05 10:48:38.1838 00:04:20:05:b5:a9 checking buffer fullness: 131072 2005-11-05 10:48:38.1839 00:04:20:05:b5:a9 is ready to sync 1131187718.18391 2005-11-05 10:48:38.1840 all clients ready to sync now. unpausing them. 2005-11-05 10:48:45.9259 00:04:20:05:b5:b6 checking buffer fullness: 3144666 2005-11-05 10:48:45.9261 00:04:20:05:b5:b6 is ready to sync 1131187725.92608 2005-11-05 10:48:45.9319 00:04:20:05:b5:a9 checking buffer fullness: 3145245 2005-11-05 10:48:45.9320 00:04:20:05:b5:a9 is ready to sync 1131187725.93198 2005-11-05 10:48:45.9320 all clients ready to sync now. unpausing them.
I've retired my old slimserver in favour of a readynas. The surprising thing for me is that I can reproduce this problem exactly on it. No plugins, just the standard 6.2.1 download that infrant provide on their web site. I'm really surprised that you have trouble reproducing the problem - so I'll give you some more detail of my setup. - ReadyNAS as slimserver (6.2.1 - no special firmware or nightly builds) - about 23,000 tracks, some flac, some mp3 - three Squeezebox 2, all connected wirelessly using wpa protection To reproduce the problem - Sync two players - start playing an album (i did this from browse music folders, but I don't think that's critical) - skip: music does not start on track 2 - skip: music starts on track 3 - skip: music does not start on track 4 - skip: music starts on track 5 - etc. Weird, huh?
I am seeing this on 6.2.1 and 6.2.2. It happens when a SB3 is synched to softsqueeze 2.3 running on solaris 11. Has there been any progress in diagnosing this failure? Is there any info I can gather to help speed things along?
The failure I see is slightly different than what's described in this report. In my case, the players displays do not advance to the next song. The elapsed time meter is completely full, but the display doesn't advance to the next song.
It looks like Richard did put some library updates on the softlib side to help with lockups when skipping tracks. I didn't see any new softsqueeze binaries, but clearly it would appear that there is work being done.
(In reply to comment #0) > I get the same thing with the 6.1.1 release, and I can reproduce it easily. > > 1. Synchronise players > 2. Start listening to the first track > 3. Hit fast forward > - at this point, the display updates, but the next track doesn't start. > 4. Hitting play starts the track, or FF again moves to the next which > starts playing > 5. Hold pause (stop) > 6. Hit play - current track starts > 7. Hit FF > - again, the display updates but the track doesn't start. > > steps 4-7 are the ones to repeat it over and over. > > My system: Compiled slim.exe on Windows 2003 server, synchronised Squeezebox2s. FYI, I have been encountering this same bug consistently for about a year. Ever since I got four SB2s, and integrated them on a wired (GigaBit Ethernet) network - so bandwidth is not a problem! SlimServer is running on a Mac Mini (one of the early ones) with 1GB of RAM, accessing music in high-bitrate MP3s (most scanned by the Slim Devices scanning service) stored on a separate network-attached-storage device (500 GB Cisco/Linksys). The interesting thing (relative to this bug report) is that in my case, using the Skip key is not necessary to make the problem happen. With the four players synched, every now and then they all just freeze up. More often than not that happens when the transition from one cut to the next is being made. However, sometimes it happens in the middle of a cut. Using the Skip key does seem to "encourage" this problem to happen, although I can't prove that, in a reproducible way. It just seems that the more often I skip, the more likely it is that a little while later, it will freeze up. Note that when the freeze-up happens, the Mac *seems* to be OK, but in reality SlimServer is so hung up that I have to reboot the machine. I have SS running as a control-panel extension in Max OS (the latest version), and so to stop it you click a button in the control panel. Except, when this freeze-up problem has happened, when you click the Stop button, it stays gray and never "comes back". The only way to clear things out so SS will run again is to reboot the machine. The weird thing is that sometimes SS will go for days without freezing up. Other times it goes just 10 or 20 cuts into a playlist (most of my playlists are very large, like 3000 to 5000 cuts, and I usually play them on random by song). Another weird potential correlation is to playing a playlist random by album (which I do for classical music playlists). For some reason this seems to raise the likelihood that the freeze up will happen. This problem has happened for me on several versions of 6.1 including the last one, and now on several daily builds of 6.2. The one I'm on at the moment is 6_2_x_v20 06-02-20. From time to time I become convinced that I've found some pattern of behavior that I can follow to keep it from freezing up. But each time, I eventually determine that I was wrong - the problem is pretty random. So for example, for a while I thought doing a rebuild of the music library somehow made a difference. It didn't make any sense to me (I used to be a programmer and I'm still quite technically knowledgeable, so I know how all this stuff works underneath - except I don't know the Perl language). And sure enough, earlier this week I found that despite repeated rebuilds of the library, each time I would get just a small number of cuts into the playlist, and it would freeze up. I have tried on multiple occasions to engage with Dan or Dean to get this problem fixed, but each time have given up (sorry guys, I'm just really busy). But if there's something I can do to help isolate the problem, I'll give it another try.
So given that others seemed to be encountering this issue due to synched players, I tried running for a while with just one player, no synch set up on any of my 4 players. Sadly, the "freeze up" issue happened again, eventually. Same exact symptoms as in my earlier post on this bug. This time it happened about 215 cuts into a playlist of about 3250 cuts in length (random by song). This is not the furthest I've gotten into a playlist before freezing up, but it's further than usual. Normally it happens in the low 100's, sometimes as early as within the first 10 cuts, and on one occasion it got through over 400 before freezing up. Have yet to hear the whole playlist! Dan and Dean, hoping to hear from you on this. Is there something I can do to generate a diagnostic for you? One problem is that since the SlimServer process is completely hung, there's never anything about the cause of the failure in the log. Not sure how to get that. The log was quite helpful in debugging that earlier problem you helped me with, of "special characters" in the names of the songs. That one has stayed fixed, thankfully.
So I tried not using the Skip function for the last couple of weeks, and the problem went away. So there may be a correlation of these things: using Skip on a playlist generated from iTunes, when the playback is synched to multiple players (in my case 4 SB2 players). But unlike some of the other posts in this thread, the issue for me was not that things would freeze up immediately upon doing the Skip. Rather, things would seem OK (next track would play, in synch on all 4 players), but then later on, on some track further down the list, it would freeze up part way through a track. Now, by avoiding Skip, I have not had the freeze-up problem. I can't prove it's gone completely, but so far, so good...
OK, good news, I think this bug is fixed. At least, it's not happening for me in the 3-29 daily build of 6.5b1. Thanks guys! As you saw from my last post here I thought there might have been some correlation to using the Skip function. So we've been going all week using Skip again, on this build, and have had no freezups. Hooray! This build does have one other issue, a minor/partial regression on the handling of special characters. See bug #3073.
Spoke too soon. Since leaving last comment that I thought this was fixed: -- Upgraded to the 4-14 nightly of 6.5b1 (Mac version) -- Ran OK with no problems for days -- Today it froze up. Same symptoms as before. Requires reboot to recover. Sigh. Dean or Dan, let me know if you need more details, or help from me on debugging this.
*** Bug 3019 has been marked as a duplicate of this bug. ***
This isn't my bug - in my case a sb2 and softsqueeze 2.3 fail to advance to the next song when theyre synched. They both sit there at the end of the current song. d_sync says this: ... 2006-04-28 12:10:13.7519 3f:72:37:03:54:f9 : is synced with its slave 00:04:20:06 :42:a1 2006-04-28 12:10:15.9449 3f:72:37:03:54:f9 : is synced with its slave 00:04:20:06 :42:a1 2006-04-28 12:10:15.9563 3f:72:37:03:54:f9 : is synced with its slave 00:04:20:06 :42:a1 2006-04-28 12:10:15.9656 3f:72:37:03:54:f9 : is synced with its slave 00:04:20:06 :42:a1 2006-04-28 12:10:16.0112 3f:72:37:03:54:f9 : is synced with its slave 00:04:20:06 :42:a1 2006-04-28 12:10:16.0243 00:04:20:06:42:a1 has run out of data, checking to see i f we can push on... 2006-04-28 12:10:16.0251 00:04:20:06:42:a1 has run out of data, checking to see i f we can push on... 2006-04-28 12:10:16.0257 00:04:20:06:42:a1 has run out of data, checking to see i f we can push on... 2006-04-28 12:10:17.0117 3f:72:37:03:54:f9 : is synced with its slave 00:04:20:06 :42:a1 2006-04-28 12:10:18.0218 3f:72:37:03:54:f9 : is synced with its slave 00:04:20:06 :42:a1 2006-04-28 12:10:19.0216 3f:72:37:03:54:f9 : is synced with its slave 00:04:20:06 :42:a1 2006-04-28 12:10:20.0317 3f:72:37:03:54:f9 : is synced with its slave 00:04:20:06 :42:a1 2006-04-28 12:10:21.0413 3f:72:37:03:54:f9 : is synced with its slave 00:04:20:06 :42:a1 ... This is with the 6.5 beta from April 25th. I will open a new bug.
I've checked in a few sync-related fixes, if you get a chance could someone try this with the latest nightly (6/13+). I'd prefer if you could try 6.3, but the same fixes are also in 6.5.
Ping. Andy - I'm going to assign this to you, as you've been up on sync issues.
Anyone been able to reproduce this lately?
It happens quite consistently for me, but on a semi-random basis, meaning there's no simple re-create other than just letting it play for days. The one thing that does seem to make it happen faster (on top of just having very long playlists, for some reason), is switching back and forth between the playlists. This is on 6.3. I have been hoping to get back to a stable build of 6.5b1 (the last one that worked for me was mid-May, and I don't have it any more). Once I'm on that I'll try to re-create on that release, if that would be helpful.
I've checked in a patch that should fix this bug. What appeared to be happening was a race condition between the player's STAT responses and the Sync buffer checks. If we were still getting old STAT responses from the previous track, but try to wait for the buffer to fill, it can cause the server to unpause the client before it actually has any data.
Any chance of this going into the 6.3 branch. I'm reluctant to move to 6.5 just yet as 6.3 is quite stable for me. The only remaining bug that I can find in this release is that players still ocasionally go out of synch. I'd like to test and confirm as fixed without upgrading to 6.5 but I understand 6.3 is in maint mode. However I think this is something that quite a few people would like fixed given the number of people who own >1 SB. Would be worth getting feedback from as many people as possible prior to confirming fixed in 6.5.
This bug was actually not specific to SB1, it affected all players. I'm not sure we are planning on doing another 6.3 release, so if you can test 6.5 that would be helpful.
I should mention that if you want to patch your copy of 6.3, this fix is quite small: http://svn.slimdevices.com/trunk/server/Slim/Player/Sync.pm?rev=8727&view=diff&r1=8727&r2=8726&p1=trunk/server/Slim/Player/Sync.pm&p2=/trunk/server/Slim/Player/Sync.pm
Thanks Andy. I'm running under Windows, so I'd need a change commited to the trunk before I could run this permanently. I've patch my local file and I'll test running from perl for a few hours. Would b nice to know that the synch is more stable in 6.5 while I wait for it to become wmore stable. i'm happy using 6.3 for the time being. Do Mac users run a binary or use perl. I ask becuase I could send my patched Synch.pm to Mike Gilpin if it would be useful to him. https://bugs-archive.lyrion.org/show_bug.cgi?id=3019#c54
Thanks for the offer, Michael. Unfortunately it looks like the executable in OSX is packaged in a 37.4 MB file called "SlimServer.prefPane" because it's accessed as a "pane" in the "Preferences" app (kinda like the Control Panel in Windows). I can't see anything inside the structure of that, from Finder (like Explorer).
You can do "Show Package Contents" on a prefpane, or get to it from Terminal: cd ~/Library/PreferencePanes/SlimServer.prefPane/Contents/server/
OK, that was easy (once you told me how to find the code!) :<). So I patched it in to 6.3.1, and am running again. I added in the fourth player (which was previously the acid test), so I'll let it run all day and see what happens. So far so good, it's made it through one synched song transition - which suggests I didn't mangle the code (I hope). Thanks for the help! PS: I just cut/pasted the change from the browser view in CVS, into the code (edited in TextEdit). I guess I should probably have used some kind of patch program, but I didn't know how to do that, so hand editing worked (as far as I can tell...).
Still have a sync problem with 4 players, so I removed the fourth player from the group and will see if I get the "freeze-up" problem with 3. What happened with 4 was what I've seen before: the song would play all the way through on some players, then would end, and I'd hear the song continuing to play (from an earlier point in the song) in another room. The progress indicators on the players that had finished playing showed a partially filled bar, though - so they appeared to be showing the completion state of the player that was still playing in another room. On an earlier thread this behavior was suspected of being attributable to my wimpy Mac Mini that's running SlimServer, so it might not indicate the fix for #1869 doesn't work. Or perhaps my patch didn't take effect? All I did was edit the contents of the sync.pm file. Is there anything else I needed to have done to cause the change to be recognized, or does the code run straight from that file?
This patch fixes the "freeze" problem when changing tracks, it does nothing for out of sync players.
OK, I'll stay on the lookout for freezeups with 3 players (which is the more serious issue anyway, so thanks for working on it). I guess that other synch problem is the one you said really needed a new approach with time codes on the network, to address properly.
Sadly I had another freeze-up today. Note that this is when the song is part-way through playing, not at the point of transitioning from one song to another (which has also been a problem in the past). I think the fix that's been checked in has eliminated the song-transition scenario, but not tne in-the-middle-of-the-song scenario. Max Mini Latest OSX 3 SB2 players Synched over 1GB Ethernet on Cat5e It does seem to matter that I'm switching back and forth between different playlists. But I'm not sure about that.
Do you have a log from when the music stops mid-song? --d_source and --d_sync would be helpful there. Glad the transition bugfix is working for you. :)
I don't have a log. Can I get what you need just by checking those options from the options panel from the browser? Or should I start from the command-line? If the latter, what's the necessary command line?
It's easiest from the command line. I assume you're running from the DMG? cd ~/Library/PreferencePanes/SlimServer.prefPane/Contents/server ./slimserver.pl --d_source --d_sync
OK, have been unable to get a log in a form I could clip in here, since when the freeze-up occurs, it causes some kind of lockup on the Mac that precludes being able to do a Save As from the Terminal window to a file. The Terminal window is "not responding" when I look at it in the Force Quit dialog. If (in this situation) I do a shutdown before trying to write to the file system from Terminal it will appear to close all the apps, but not actually shut off the hardware - so I have to do that with the power switch. On the other hand, when I tried to save from Terminal, a shutdown after that would not close the apps until after I did a Force Quit on Terminal, after which it appeared to shut down (from the screen), but still required power switch shutoff. Both times I had a log running (which is showing up in the Terminal window) that I had the freeze-up happen, the last set of messages that had appeared exhibited the same pattern. Both times there was a repetition of these three messages: Got a track starting event Song X has now started playing (X was really a number) Song queue is now X The first time I got the freeze-up, it repeated this block of three messages six times, with X=7. Yet on the display of the players, it claimed to be playing song 8 (and I had in fact heard some of that song before the freeze-up occured). The second time, it repeated this block of messages five times, with X=66 - yet the players were showing song 67. This block of messages followed a message "All clients ready to sync now". The other piece of data I captured by hand from the Terminal window was the time-codes of the messages, the second time, when there were five repetitions. They were: 15:40.30.1220, leaving out the first part which was the same) 1233 1259 1278 1288 1306 1340 1350 1366 1393 1403 1419 1441 1451 1467 At this point there were no more messages appearing in the Terminal window - it had frozen up after that. I went to the screen and checked the time as soon as the freeze-up happened, and it was shortly after this time (15:40). Hope this helps. Let me know if there's anything else I should try. By the way, I had seen another person having a similar problem and suspecting it might be something to do with uPnP. So the second time I got this freeze-up, I was running with the --noupnp switch. The first time not. So uPnP seems to be unrelated. But I had seen a series of uPnP messages appearing on a previous occasion, which I had thought might correlate with the freeze-up. Evidently not.
Setting this bug to re-opened.
Subject: Out of Office AutoReply: synced music doesn't start I am out of the office on vacation Monday August 7th. I will reply to your message at the earliest opportunity. <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN"> <HTML> <HEAD> <META HTTP-EQUIV="Content-Type" CONTENT="text/html; charset=iso-8859-1"> <META NAME="Generator" CONTENT="MS Exchange Server version 6.5.7650.5"> <TITLE>Out of Office AutoReply: [Bug 1869] synced music doesn't start</TITLE> </HEAD> <BODY> <!-- Converted from text/plain format --> <P><FONT SIZE=2>I am out of the office on vacation Monday August 7th. I will reply to your message at the earliest opportunity.</FONT> </P> </BODY> </HTML>
I'm now thinking that my weird freeze-up problem (which was originally reported over a year ago, and has stayed broken since then) has nothing to do with synch - so perhaps should be tracked in a separate bug#. Actually I think it had its own bug# originally but later got merged (probably wrongly) into this one. I upgraded to 6.5b1 yesterday, from the Monday night build. Today I've been listening to music on one player because I couldn't get more than one player to run (they are all getting the same IP address, a Firmware 59 issue that I've posted about in the beta forum - that one may need a bug # too, if it doesn't have one already). And just now the freeze-up problem happened, about 35 songs into a roughly 5300 song playlist (shuffled by song). Since there's only one player, I assume it can't be a synch related problem. My expectation is that the log entries for this would be the same as what I was able to get last week from 6.3.1. But let me know if you'd like me to try again with 6.5b1. I may revert to 6.3.1 at some point to get multiple players working again, unless that firmware problem gets fixed in the next day or two.
From your last message, it definitely sounds like you're still having problems, but not really related to this original bug. Can you file the additional bugs as necessary for us to have a better look, Mike?
So what's the status here? Should this bug be closed, and another one opened? Thanks
I think this bug is fixed.
Marking fixed.