Bugzilla – Bug 10475
Last 15 seconds of song gets chopped off (skipped)
Last modified: 2012-02-27 17:19:07 UTC
Created attachment 4515 [details] custom-convert file I recently upgraded from 7.2.1 to 7.3 and encountered this problem. I upgraded from 7.3 to 7.3.1 hoping that it would be solved but wasn't. It seems that the last 15 seconds of songs I play from my library (iTunes) gets chopped off. I did not notice this problem under 7.2.1. When the song gets 15 seconds from the end it jumps to the next song. Is this a bug, a setting, or something I have to change in my custom-convert.conf? My config is as follows: QNAP TS-509 f/w 2.1.0 build 1202T (latest version) SSOTS 3.15 SC 7.3.1 - 24372 Squeezebox Duet iTunes music library - songs encoded as aac (m4p) not loseless custom-convert.conf is attached. I think I read that a new custome-convert.conf file is needed with 7.3. Is this true? If so could this be the problem?
It would be worth trying the latest 7.3.2 nightly as there was a change between 7.2 and 7.3 which has been changed back in the latest nightlies and *could* impact this.
I just upgraded to Version: 7.3.2 - 24422 @ Sun Dec 28 03:00:06 PST 2008. I'll test over the next few days and let you know what happens.
I did some testing and it is still happening. It doesn't happen on all songs, which is the same as it was before I installed 7.3.2.xxx. So no improvement. I did verify that the songs that skipped in SC played fine in iTunes and they did. Is my custom-convert.conf file ok? Don
(In reply to comment #3) > Is my custom-convert.conf file ok? It is ok for FLAC and WAV as far as I can tell, but MP3 is wrong. Look at the main convert.conf for details of the syntax needed when BITRATE is specified.
This is almost certainly a Transcoding issues with SC and not specifically related to the SBR.
(In reply to comment #3) > Is my custom-convert.conf file ok? Can you try adding ' # F' to the custom-convert.conf entry for FLAC, like this (note the whitespace): mov flc * * # F [mplayer-stdout] -really-quiet ...
I will add the # F in a few days and report back. I am currently doing some testing on another bug report.
Moving target to monitor pending a response from Don.
I tested it and it seems to be working now. What does the '# F' do?
Sometimes the player sends a DSCO with a non-zero reason code when it would seem that a normal disconnect at the end of the track is what has really happened. Quite why in not clear. It would seem, from reports that this problem happens with both ip3k players and SqueezePlay, so it is probably something triggered by SC. It does not seem to be confined to a single operating-system platform. http://forums.slimdevices.com/attachment.php?attachmentid=6878&d=1233506199 Bug 9758 is probably relevant. Bug 10919 may be the same - not sure.
Created attachment 4754 [details] Possible patch for consequences
Tried applying the suggested patch on the two files to fix Bug 10919, see my post there regarding my preliminary good results :-) Regards Bebop
Please can QA try to reproduce this. So far, I have been unable to, after 24hrs continuous play. Although the original reporter of this bug was using Qnap, I think that Windows would be the best test platform. It might be best to use tracks that require SC transcoding (AAC or ALAC for example). Run with logging player.source=info and network.protocol.slimproto=info. The symptom will be an instance of playerStreamingFailed in the log and, if anyone is actually listening to the player, a track will end prematurely before starting the next. An excellent addition to this test would be a network sniffer, filtering on the player's mac address and set stop a few packets after getting a TCP RST. This test must be carried out with SC 7.3.* _prior_ to r24875.
*** Bug 10919 has been marked as a duplicate of this bug. ***
Steven could you have a look at this?
Alan, is this still something you would like QA to reproduce? I tried for a while to reproduce on Windows XP without success.
I'd still like to get to the bottom of this problem, so yes, it would be good if you could continue to try to reproduce it. Perhaps you set up a continuous test rig that just lets this play for a few days: Windows, AAC files, SC 7.3.* _prior_ to r24875. Then just check the logfile for the playerStreamingFailed messages - noone actually has to listen to the output. And it really would be good if a packet sniffer (wireshark or similar) was part of the test rig.
We are now planning to make a 7.3.3 release. Please review your bugs (all marked open against 7.3.3) to see if they can be fixed in the next few weeks, or if they should be retargeted for 7.4 or future. Thanks!
Since there's now a planned 7.3.3 release, bugs which won't make the cut-off are being moved to the next target out. If you feel that this bug needs to be addressed more (or less) urgently than the 7.4 release, please cc chris@slimdevices.com and leave a comment in the bug to that effect so we can review it. Thanks.
For some reason Bugzilla did not change the target when I did this yesterday. Or maybe it was me. In either case, I'm trying it again.
The change log for 7.3.3 shows this as being fixed. So why are you changing the target milestone to 7.4?
(In reply to comment #21) > The change log for 7.3.3 shows this as being fixed. So why are you changing the > target milestone to 7.4? Don: Have you tested with the latest 7.3.3 nightly? Can you confirm that the bug has been fixed?
I have not actually tested it but if you read back thru the bug history (#12) you will see that Bebop has tested and says it works.
Thanks Don. I've left his open because I'm still hoping that the QA team will be able to reproduce the original problem so that we can confirm that the fix is indeed the correct one. We may have an apparent fix but there may also be an underlying problem that needs attention.
Adding time worked info
QA will not have time to validate this fix.
Closing resolved bugs - if you feel this bug still exists please first re-test with the latest SW/FW version. If you are able to reproduce then feel free to reopen and attach new logs / steps to reproduce.