Bugzilla – Bug 4544
6.5.1 lost gap, songs cut off or truncated
Last modified: 2009-09-08 09:23:59 UTC
As most albums have a gap between songs, so has all prior Slimservers. I just went to 6.5.1 and now all songs run into each other. My only option available is to create any sort of fade, which alters the beginning and ending of songs. Is it possible to get the gap back? I use iTunes and rip everything with Apple Lossless. Ideally there would be a default setting for gap or gapless, with the ability to modify gapless albumns to play gapless if everything else was with gaps.
When you rip a CD, why aren't you including the gaps in the songs themselves, either prepended or appended? How do you propose SlimServer would know a gapless album from one with gaps? If SlimServer inserts some pause/gap between tracks, then you can only play gapless albums correctly by turning that pause off. Short of creating a new tag that SlimServer would recognize, that would have to be done manually by the user at the time of playback.
one option, there is an "audio startup time" in player settings that adds some silence to the start of tracks (mainly intended for allowing DACs time to capture the signal timing). it can server as a workaround, at least. otherwise, this is really an enhancement as it would require some new preference for handling silence padding between songs in a flexible way.
Steven could you try reproducing this? Just a reminder, there are likely to be differences between file types. You may need to inquire to figure out what file type Randy is using.
Randy, just to make clear, were these songs ripped form CD to Apple Lossless in iTunes? If the songs were ripped in iTunes they will always have the gap added to the end of the song if ones exists. There is no option to changes this in iTunes. Since this "gap" is part of the audio data something else is at play here.
(In reply to comment #4) > Randy, just to make clear, were these songs ripped form CD to Apple Lossless in > iTunes? > If the songs were ripped in iTunes they will always have the gap added to the > end of the song if ones exists. There is no option to changes this in iTunes. > Since this "gap" is part of the audio data something else is at play here. Songs were ripped in iTunes in lossless. The problem is that the end of each song gets a few seconds chopped off by the beginning of the next song. i have so far worked around that problem by going back to 6.3.1.
Randy, thanks for the additional info, will investigate further.
Randy, what hardware are you using to playback these files and what outputs are you using?
(In reply to comment #7) > Randy, what hardware are you using to playback these files and what outputs are > you using? My CPU is a P4 1.8 GHz with 1G RAM running XPSP2, wireless Linksys draft N router not hardwired to CPU nor hardwired to SB3 (2-hop wireless). Outputs from SB3 to stereo are the RCA jacks.
Thanks Randy. I have not been able to reproduce the behavior but I suspect it is in the transcoding since Squeezebox does not play Apple Lossless natively. If you still experience the behavior with 6.5.1 try forcing Slimsever to stream in MP3 or WAV to see if it makes a difference. To try WAV go Home->Server Settings->File Types and disable Apple Lossles->FLAC. To try MP3 go Home->Player Settings->Audio and set Bitrate Limiting to 320 kbps or less. This may also be a manifestation of the ALAC decoder. Apple Lossless decoding in Slimsever in now handled by the ALAC decoder to fix Bug 2095. This was done in Slimserver 6.5.0. Perhaps you are using a custom slimserver-convert.conf that is not being updated to reflect the changes. We could also try editing your convert.conf and changing some of the transcoding parameters if none of the above make a difference.
(In reply to comment #9) > Thanks Randy. I have not been able to reproduce the behavior but I suspect it > is in the transcoding since Squeezebox does not play Apple Lossless natively. > If you still experience the behavior with 6.5.1 try forcing Slimsever to stream > in MP3 or WAV to see if it makes a difference. To try WAV go Home->Server > Settings->File Types and disable Apple Lossles->FLAC. To try MP3 go > Home->Player Settings->Audio and set Bitrate Limiting to 320 kbps or less. > This may also be a manifestation of the ALAC decoder. Apple Lossless decoding > in Slimsever in now handled by the ALAC decoder to fix Bug 2095. This was done > in Slimserver 6.5.0. Perhaps you are using a custom slimserver-convert.conf > that is not being updated to reflect the changes. We could also try editing > your convert.conf and changing some of the transcoding parameters if none of > the above make a difference. Won't I lose audio quality by going to MP3 or limiting the bitrate? I am certainly willing to try this if it helps diagnose the issue, but am not willing to sacrifice audio quality just to be able to use the latest and .....
Yes, you will lose some audio quality forcing transcoding to MP3 but it may help diagnose the problem. Forcing transcoding to WAV will not but may exceed your networks bandwidth.
(In reply to comment #11) > Yes, you will lose some audio quality forcing transcoding to MP3 but it may > help diagnose the problem. Forcing transcoding to WAV will not but may exceed > your networks bandwidth. I uninstalled 6.3.1 then installed 6.5.1, forced both WAV and MP3 per instructions above; the tail of each song gets chopped off at between 4 and 5 seconds left to play. This is visible in the elapsed time scale for each song when the player moves to the next song when there is still 4 or 5 seconds left on the current song. Went back to 6.3.1 again and problem went away.
(support note: ticket 070214-003873 appears to have same issue)
Created attachment 1818 [details] WAV files to test gaps Randy, I appreciate your patients with this and I am now able to produce the behavior you describe. It appears that beginning with 6.5.1 any file that is transcoded on the sever has the last couple of seconds cut off. This behavior is currently in 6.5.2 as well but not in 7.0. WAV, AIF, FLAC, MP3, OGG & WMA play fine as long as no server side transcoding is involved. If one forces transcoding on these formats or plays a format that is only supported with server side transcoding the last couple of second will be cut off.
*** Bug 4766 has been marked as a duplicate of this bug. ***
*** Bug 4746 has been marked as a duplicate of this bug. ***
Chris, since I do not see this behavior in 7.0 I marked the target as such.
(In reply to comment #17) > Chris, since I do not see this behavior in 7.0 I marked the target as such. I'm not following the logic there. This is a fairly serious bug that should be addressed for 6.5.2, which will be released long before 7.0. If this bug doesn't exist in 7.0, then I would think the developers could use that knowledge to track down the problem in 6.5.
Dan, do you think it would be possible to get this fixed in 6.5.2?
This sounds like it's related to Bug# 4384.
*** Bug 4384 has been marked as a duplicate of this bug. ***
> It appears that beginning with 6.5.1 any file that is transcoded on the sever > has the last couple of seconds cut off. This behavior is currently in 6.5.2 as > well but not in 7.0. > WAV, AIF, FLAC, MP3, OGG & WMA play fine as long as no server side transcoding > is involved. If one forces transcoding on these formats or plays a format that > is only supported with server side transcoding the last couple of second will > be cut off. I had the same problem. I'm using single flac file + external cue sheet. With 6.5.1 end of the songs were cut off. Installing back 6.3.1 problem disappered. I think it's a serious bug, should be P1.
I've asked Steven to try to work out where, exactly, this bug began occurring.
I was not able to reproduce this issue on Mac OS X 10.4.9 or Ubuntu 6.10 so it appears to be specific to Windows at the moment. From what I can tell the problem was introduced between version 6.5.0 and 6.5.1. I am going to try with ActivePerl to see if it makes a difference.
Updated summary for ease of searching
Dean, this is actually a very serious bug. It also ranks highly in the number of support calls it generates.
This may have to do with a part of slimserver called socketwrapper, and we're looking at a new one. We'll try and get it in to 6.5.2.
There is a new socketwrapper in the latest 6.5.2 nightlies. If everyone could have a look and let us know whether it helps or not, it would be very helpful! There is still an issue with Apple AAC files, but it's a separate bug, and we've created bug 5038 to cover it. If you're still having problems and they're limited to Apple AAC, please join us at the new bug. Adrian, if you could put the change number for your new socketwrapper checkin here, I can mark this as fixed.
New socketwrapper added to 6.5 in change 12002
(In reply to comment #28) > There is a new socketwrapper in the latest 6.5.2 nightlies. If everyone could > have a look and let us know whether it helps or not, it would be very helpful! Just tried it. If you pause the client (Winamp, in my case), wait a moment, and "unpause" it, the rest of the track (up to several minutes) is cut off! This isn't a problem I had before.
(In reply to comment #30) > (In reply to comment #28) > > There is a new socketwrapper in the latest 6.5.2 nightlies. If everyone could > > have a look and let us know whether it helps or not, it would be very helpful! > > Just tried it. If you pause the client (Winamp, in my case), wait a moment, and > "unpause" it, the rest of the track (up to several minutes) is cut off! This > isn't a problem I had before. This also happens if your pause/play SlimServer directly. It will skip to the next track.
downloaded nightly 6.5.2. Now seems to work for me; no more cutoffs. All songs are Apple Lossless loaded from CDs into I tunes and play full length with gaps as intended. will let you know if this doesn't solve the problem, but so far so good. Thanks
Downloaded b12003, socketwrapper.exe size 61,440 resulted in the same cutoff at the end of song problem for me doing FLAC to MP3 transcoding. Went back to the socketwrapper.exe posted in the forums (size 471,040), problem solved. So still something wrong with the socketwrapper supplied in b12003.
There were various issues with the build. Would you have a look at today's build 12039? We've tested it here and it appears to work as well as the one in the forums to which you refer.
Just downloaded b12039 (Windows EXE), installed it, and the socketwrapper is exactly the same size as the one in b12003. And still the same problem. I again replaced it with the one from the forum, and presto--problem fixed!
Marking as fixed for the release of 6.5.2 as these issues are believed to be corrected with the updates to socketwrapper included with 6.5.2. Please feel free to re-open if there are any continuing issues, or new symptoms we may need to investigate.
I just downloaded the official 6.5.2 release that supposedly has the socketwrapper fix. Guess what? It ISN'T FIXED! The socketwrapper as I've reported above has been the same size since b12003, and IT DOES NOT WORK properly. Again, replacing it with the one from the forum fixed the problem. IMHO, this issue should NOT have been closed.
Please note socketwrapper included in the main distibution is a release build, whereas the one hosted on bpa's site is a debug build. This is the reason for the difference in file size. The one included in 6.5.2 is a development of the one posted to the form by Bryan (bpa) - it should show version 1.8 if you run the file manually. Please describe in more detail which forum build you have been using and what transcoding settings you have.
Fixed in 6.5.2, which is now released and available for download at http://www.slimdevices.com/su_downloads.html If you're still experiencing this bug, please re-open it!
Well, the one that works was v1.5 beta. The one that has been included with b12003 and all the versions I've tried since (including the 6.5.2 official release) is version 1.6. Chris--are you intimating that there is yet a newer build of the 6.5.2 release (I downloaded at approximately 11:30 a.m. today) with the new socketwrapper v1.8 that you just uploaded?
That is not what I am intimating. What I am saying is that for all the other customers our support team has talked to and for almost all the cases we have been able to reproduce (see bug 5038 for at least one exception) this socktwrapper fixes the problem. What I'd like to get from you Ivan is some information so that we can try to reproduce your symptoms, and continue improving this area for the 6.5.3 release.
I cleared my cache and downloaded the 6.5.2 release version from http://www.slimdevices.com/su_downloads.html again. I shut down SlimServer, manually deleted socketwrapper.exe (to make sure it is absolutely gone) and reinstalled 6.5.2 after that. Guess what? Version 1.8 got installed this time! Tested it, and this works now. Can't explain why v1.6 got installed the first time I installed 6.5.2. My guess is that either the installer or Windows cache may have been confused since version 1.6 and 1.8 are exactly the same file size, and it kept putting 1.6 in there. But that's simply a wild guess since I manually replaced v1.6 with 1.5 beta each of the previous times. Regardless, this bug is now killed i my setup as well--yay! Thanx--I anxiously awaited many long months for this fix. Sorry about all the confusion.
socketwrapper.exe is still crashing in 6.5.3 - 12081 when you pause the client or the server.
Oliver, Can you give a bit more details for example. Is socketwrapper actually crashing (e.g. with a message "Socketwrapper has a problem") or do you mean when you hit pause data is cut off as described in your previous comment. Is Winamp on the same system as SS ? Do you line up a playlist and then play or do you start play and keeping adding to playluist ? What format file are you playing ? What version of lame are you using ?
(In reply to comment #44) > Can you give a bit more details for example. > Is socketwrapper actually crashing (e.g. with a message "Socketwrapper has a > problem") or do you mean when you hit pause data is cut off as described in > your previous comment. In the latest version (6.5.3 - 12081), socketwrapper.exe does crash, with Windows displaying one or several dialog boxes. Just like when any other process causes an access violation, for example. > Is Winamp on the same system as SS ? Yes and no. I listen to my music locally and remotely. But I can't seem to reproduce the problem when streaming locally. I'll try remotely later. > Do you line up a playlist and then play or do you start play and keeping adding > to playluist ? I think the crashes occur even if I don't modify the playlist. I'm not sure about that, though. > What format file are you playing ? FLAC, mainly, and MP3. > What version of lame are you using ? 3.96.1.
Using Olivier's info I've managed to reproduce the crash. They seems to happen with a remote Winamp if a pause occurs during final stages of socketwrapper when LAME or FLAC has completed. The crashes do not happen when I use a debug build of socketwrapper. Analysing the crash dump file produced indicates that the problem occurs during final process shutdown in the stdio library after all socketwrapper code has been executed. If the crash dump analysis is to be believed then the problem is either corruption of stdio library data by socketwrapper code or a possibility some sort of race problem within the stdio library.
Below is a link to a new version of socketwrapper to be tested. I believe it fixes the "Problem encountered" crash but I could only get the crash using Winamp whereas other reported the problem with other players. http://homepage.eircom.net/~altondsl/slim/socketwrapper19b.zip The crash problem related to shutdown of socketwrapper. So when using this version out please any new oddities especially if you notice anything especially in relation to truncation or gaps between tracks. I found using Pause at the critical time provoked the crash, however testing "play/pause" intensively showed up some other Pause related Slimserver bugs. So if you are not using latest 6.5.3, some problem may not be socketwrapper's fault.
We weren't ever able to reproduce this particular problem here in QA, so if anyone could provide some feedback it would be much appreciated.
I can make get a crash with the following setup. Winamp (latest download) SS 6.5.1 - 6.5.3 with Socketwrapper 1.8 WAV files attached to this bug Process Explorer from Microsoft from here http://www.microsoft.com/technet/sysinternals/utilities/ProcessExplorer.mspx Install process Explorer as this helps to see when socketwrapper is starting/stopping as timing is critical. 1. Start slimserver 2. Start Process Explorer 3. Start Winamp running on a separate PC with network connection. Start playing a connection to stream.mp3 4. With "Repeat All" start the playing all 17 WAV files continuously 5. Look at Process Explorer display to get a "feel" to the timing of socketwrapper starting and running Flac. 6. Using the Winamp "pause" key to toggle start / stop - try to stop the stream just when socketwrapper is stopping by looking at the process explorer display. The critical point is when Flac process has stopped but socketwrapper is still running. To get to this stage require clicking Winamp's "Pause" quite fast to play fragment of music Process Explorer shows a process as Green when starting and Red when stopping. There are intermediate states- the problem happens when socketwrapper is mauve or grey. 7. When you get a process with just socketwrapper running and Winamp pause. Wait at least a few secs and then click Winamp pause - crash will happen when socketwrapper tries to shutdown. I can get a crash within the run of 17 files but it is tiring clicking the mouse rapidly to move Winamp music stream in v. small amounts.